.ai - это формат Adobe Illustrator, он явно не является шрифтом. Просто используйте реальные веб-шрифты (расширение должно быть .woff2 или .woff). .ttf или .otf) - то веб-версию можно получить используя FontSquirrel generator. TokenInterface) и большинство частей Security компонента достаточно абстрактны для того чтобы из них можно было собрать весьма разнообразные схемы разделения прав доступа.Security::isAllowed()? Symfony по-умолчанию реализует первый подход, но ничто не мешает вам организовать собственную реализацию основных компонентов. Если вам нужен ACL (а именно так называется "привязка привилегии к функционалу") - то эта функциональность вынесена в отдельный ACL bundle в Symfony 4, скорее всего именно она вам и нужна.$enclosure который вы, очевидно, оставили по-умолчанию. Всё это есть в документации. <meta name="viewport" content="width=device-width, initial-scale=1.0"/>body {
direction: rtl;
}html[dir=rtl] + body, но это уже детали.margin-left на margin-right и наоборот, то же самое для padding'аleft и right, их, как можно догадаться, тоже необходимо поменять местамиfont-size, line-height) и, возможно, подстроить стилизацию (font-weight)text-align - в ряде ситуаций может потребоваться изменить его на противоположный:first-child и :last-child, стоит быть внимательным и перепроверить корректность получаемого результата, к примеру если к этим псевдо-элементам добавляется дополнительный отступ - вам, возможно, придётся менять местами и селекторыdirection: rtl&.with-icon {
$icon-size: 1.85em;
@include offset(h $icon-size 0);
&:before {
// Позиция иконки меняется на противоположную
@include hpos($left: -1em, $auto: true);
font-size: $icon-size;
// Подстраивается высота иконки относительно текста
@include ltr() {
top: 45%;
}
@include rtl() {
top: 65%;
// Стоит обратить внимание что для RTL языков иконка дополнительно переворачивается,
// там стрелка, так что работает нормально, но в других местах это может быть по-другому
transform: translateY(-50%) rotate(180deg);
}
}
}Content, в этом случае можно было бы запрашивать репозиторий именно для базовой entity и дальше у вас не будет разделения логики работы с теми же тегами.TagSearchService), сделать для каждого типа "category, faq, article" отдельные actions в их контроллерах которые будут обращаться к сервисному классу с разными (и в этом случае заранее известными) параметрами. Т.е., проще говоря, в каком-нибудь CategoryController::search() вы могли бы вызвать TagSearchService и передавать ему Category::class вместо того чтобы полагаться на приходящие извне данные. Если переходить на такую схему - то разные классы для элементов форм (CategoryType и FaqType в вашем примере) тоже естественным образом заменяются на один класс (какой-нибудь TagSearchType) т.к. между ними не остаётся различий. Кроме того не нужно будет передавать извне имя класса - по-моему это плохая идея в любом случае.TaggableInterface для entities которые могут иметь теги. Это естественным образом приводит к возможности в compiler pass собрать список таких entities и передать их в TagSearchService. Возможно потребуется для каких-то целей :)notIn(). Если же это и не так - код можно переписать с использованием array_map(), возможно это сделает его понятнее. Также findOneBy(['id' => $entityId]) очевидным образом меняется на EntityManager::find() что несколько проще выглядит.DiscriminatorMap который является правильным решением в данной задаче. Вам ничто не мешает теперь иметь в наследуемых классах отдельные свойства содержащие связи с конкретными entities, специфичными для каждого конкретного типа пункта меню. Вы также вполне можете объявить getEntity() / setEntity() в классе MenuItem абстрактными, а в дочерних классах реализовывать их. Конечно типы на уровне языка вам будет не задать, но никто не будет вам мешать использовать PHPDoc для создания type hints. <form>, если вместо кнопки submit'а используется что-то другое (например ссылка с JavaScript обработчиком) и т.п. Кроме того сохранение формы не предлагается если сайт напрямую это запрещает, добавляя атрибут autocomplete="false" в элементы форм.ActivitableInterface для entities для которых есть флаг isActive) и дальше либо реализовать промежуточный абстрактный класс репозитория и наследовать custom repositories от него либо вынести эти операции в traits и подключать по мере необходимости.Command из symfony/command? Если да - то там есть раздельная инициализация через initialize(), туда передаётся OutputInterface и если сильно нужно - можно там вызвать некий отдельный сервис. Если не хочется прокидывать сервис вручную в каждую команду - можно автоматизировать это через setter + compiler pass либо через аннотицию @required /src кучу разных bundles, а иметь один общий код приложения, зависимый только от внешних packages (пусть даже написанных вами) которые устанавливаются через Composer.