Symfony не работает route

Symfony4 Аннотация маршрутизации не работает

Я только начал изучать Symfony. Я в точности следую этому официальному учебнику. Маршрутизация работает хорошо, когда выполняется с config/routes.yaml , но при использовании аннотаций :

Я получаю эту ошибку:

8 ответов

Я узнал свою ошибку. Я использовал неправильное пространство имен для маршрутизации.

Это должно было быть:

EDIT : Я хотел удалить этот вопрос, но система не позволила мне.

Убедитесь, что вы установили annotations библиотеку с composer require annotations Это была моя проблема, а не другие, описанные здесь.

Убедитесь, что вы импортировали необходимые классы в свой контроллер.

Я хочу дать дополнительный совет об ошибках аннотации в symfony4:

Я решил свою проблему с этим:

Мой проект не имеет config / routs / annotation.yaml, поэтому создайте этот файл и напишите следующие строки:

У меня была такая же проблема с моим первым проектом Symfony 4 на стандартном веб-сервере apache.

Создание файла .htaccess в моей общей папке устранило проблему.

В моем случае добавление «apache bundle» решило проблему:

Это необходимо, если вы запускаете symfony в браузере через / public /.

У меня была та же проблема (в моем проекте Symfony5), но моей ошибкой было использование одинарных кавычек вместо двойных кавычек для маршрута и имени маршрута. Иногда маленькие глупые ошибки будут тратить много вашего времени. Кстати, в SF4 / SF5 мы должны избегать использования Routing of FrameworkExtraBundle.

Мы должны использовать компонент Symfony (Routing / Annotation).

Symfony 4 с файлом .htaccess в общей папке решает проблему с помощью аннотации маршрутизации.

Источник

Маршрутизация не работает в Symfony 3.4

Я создал новый проект Symfony 3.4, используя:

После этого я добавил следующие компоненты:

И создал контроллер:

Я добавил действие с маршрутом «легальный». Вот DefaultController:

Файл config / rout.yaml:

И конфиг / маршруты / аннотации.yaml:

Когда я захожу на домашнюю страницу, нет проблем, страница отображается. Но когда я пробую страницу / legal, у меня появляется 404:

Not Found — Запрошенный URL / Legal не найден на этом сервере.

php bin/console debug:router показывает ожидаемое:

Я очистил кеш с помощью команды console и удалив содержимое каталога var / cache. Но все равно 404.

Я новичок в 3.4. Любые идеи ? Спасибо.

4 ответа

Ну, как указал @Basel Issmail, Symfony / Flex не создает .htaccess , как это делал предыдущий установщик Symfony, и я забыл об этом.

У меня только что был минимальный файл конфигурации Apache:

Поэтому я создал файл .htaccess в /public/ (где находится файл index.php ), и минимально необходимая конфигурация выглядит примерно так:

Недостающая часть заключалась в том, чтобы переписать все запросы (кроме существующих файлов, таких как ресурсы) в index.php , чтобы Symfony обрабатывал маршрут.

— Изменить —

Вместо того, чтобы вручную создавать .htaccess, вы также можете просто использовать рецепт Symfony Flex:

Вы загрузили свое «Приложение» в Bundle в AppKernel.php? Существует массив, в котором вы должны открыть. Добавьте AppBundle.php вашего Bundle.

Это должно выглядеть вот так

Та же проблема с установкой Symfony на Synology DSM 6.2. Я подтверждаю, просто запустите «composer Требуется apache-pack», как указано в Scandel, и маршрутизация аннотаций будет работать отлично. Файл .htaccess с перезаписью cond будет автоматически создан в общей папке.

Вот файл .htaccess, созданный установкой symfony flex:

Похоже, вам нужно настроить RewriteBase с помощью apache , поскольку проблема не в /

Возможно, файл .htaccess даже отсутствует, поскольку вы используете Symfony / flex, и он по умолчанию не добавляет его, как в предыдущих выпусках Symfony.

Посетите эту страницу, чтобы настроить веб-сервер

.htaccess должен находиться в общей папке, и минимальная конфигурация для запуска приложения под Apache:

Источник

Symfony Перестал работать @Route

VitaliyVL

Новичок

Здравствуйте.
Я в программировании новичек.

Framework: Symfony 3
Сервер: использую встроенный (php bin/console server:run)
GitHub этого проекта: https://github.com/VitaliyGoncharov/d-chat
IDE: PhpStorm

SaveController.php : здесь
SecurityController.php : здесь
routing.yml : здесь
security.yml здесь

Помогите, пожалуйста, разобраться почему не работает маршрут «/save» и некорректно работает маршрут «/».

Делал проект, всё работало. Создал новый контроллер(не через консоль) SaveController.php, также как создавал и два других. Перешел по маршруту http://127.0.0.1:8000/save. Выдало: No route found for «GET /save». Понятно, что маршрут не найден. Но почему?!

Решил изменить уже существующий маршрут «/» в файле SecurityController.php на «/test».
К удивлению, при переходе по маршруту «/» ошибки отсутствия маршрута не выдало и отобразилось то же, что отображалось и ранее. А при переходе по «/test» выдается ошибка, что маршрут отсутствует.

При изменении названия функции [которая под аннотацией, т.е. function loginAction() ] на logAction() выдает ошибку: «Ожидается найти метод loginAction()».

Кеш чистил: php bin/console cache:clear —no-warmup -e prod

Проверял на наличие TAB-ов в аннотации, все в порядке.

Источник

Компонент Routing¶

Установка¶

Также вы можете клонировать репозиторий https://github.com/symfony/routing.

If you install this component outside of a Symfony application, you must require the vendor/autoload.php file in your code to enable the class autoloading mechanism provided by Composer. Read this article for more details.

Использование¶

Эта статья объясняет как использовать функции Routing как независимого компонента в любом приложении PHP. Прочитайте статью Routing для понимания как использовать его в приложениях Symfony.

Для тог, чтобы установить базову систему маршрутизации, вам нужно три составляющие:

• RouteCollection , который содержит определения маршрутов (экземпляры класса Route )
• RequestContext , который содержит информацию о запросе
• UrlMatcher , который выполняет соединение запроса с единственным маршрутом

Вот быстрый пример. Заметьте, что предполагается, что вы уже сконфигурировали ваш автозагрузчик, чтобы он загружал компонент Routing:

Параметры RequestContext могут быть наполнены значениями, хранящимися в $_SERVER , но легче использовать компонент HttpFoundation, как объясняется ниже .

Вы можете добавлять к RouteCollection столько маршрутов, сколько хотите.

Метод RouteCollection::add() берёт два аргумента. Первый — это имя маршрута. Второй — объект Route , который ожидает URL путь и некоторый массив пользовательских переменных в своём конструкторе. Этот массив пользовательских переменных может быть чем угодно важным для вашего приложения и возвращаться при сопоставлении маршрута.

UrlMatcher::match() возвращает переменные, которые вы установили в маршруте, а также рандомные заполнители (см. ниже). Теперь ваше приложение может использовать эту информацию, чтобы продолжать обработку запроса. В дополенение к сконфигурированным переменным, добавляется ключ _route , который содержит имя соответствующего маршрута.

Если соответствующий маршрут не может быть найден, будет вызвано ResourceNotFoundException .

Определение маршрутов¶

Полное определение маршрута может содержать до семи частей:

1. Маршрут пути URL. Он сопоставляется с URL, переданным RequestContext , и может содержать названные рандомные заполнители (например, ), чтобы соответствовать динамическим частям URL.
2. Массив значений по умолчанию. Содержит массив арбитражных значений, которые будут возвращены, когда запрос соответствует маршруту.
3. Массив требований. Он определяет ограничения значений заполнителей в виде регулярных выражений.
4. Массив опций. Они содержит внутренние настройки для маршрута и является наименее необходимыми.
5. Хост. Сопоставляется с хостом запроса. Смотрите /routing/hostname_pattern , чтобы узнать больше.
6. Массив схем. Форсирует определённую HTTP схему ( http , https ).
7. Массив методов. Форсирует определённый метод HTTP запроса ( HEAD , GET , POST , …).

Рассмотрите следующий маршрут, который объединяет несколько из этих идей:

В этом случае, маршрут сопоставляется с /archive/2012-01 , так как метасимвол соответствует регулярному выражению заданного метасимвола. Однако, /archive/foo не соответствует, так как “foo” не подходит метасимволу месяца.

При использовании метасимволов, они возвращаются в виде массива, при вызове match . Часть пути, с которой сопоставляется метасимвол (например, 2012-01 ), используется в качестве значения.

Если вы хотите сопоставить все URL, которые начинаются с определённого пути и заканчиваются произвольным суффиксом, вы можете использовать следующее определение маршрута:

Использование префиксов¶

Вы можете добавлять маршруты или другие экземпляры RouteCollection к другой коллекции. Таким образом, вы можете построить древо маршрутов. Кроме того, вы можете определить префикс и значение по умолчанию для параметров, требований, опций, схем и хоста для всех маршрутов поддрева, используя методы, предоставленные классом RouteCollection :

Установка параметров запроса¶

RequestContext предоставляет информацию о текущем запросе. Вы можете определить все параметры HTTP запроса с этим классом через его конструктор:

Обычно вы можете передать значения из переменной $_SERVER , чтобы наполнить RequestContext . Но если вы используете компонент HttpFoundation , вы можете использовать его класс Request , чтобы наполнить RequestContext с помощью сокращения:

Генерирование URL¶

В то время как UrlMatcher , пытается найти маршрут, который соответствует заданному запросу, вы можете также построить URL из определённого маршрута:

Если вы определили схему, генерируются абсолютный URL, если схема текущего RequestContext не соответствует требованию.

Проверка существования пути¶

В динамично развивающихся приложениях может быть необходимо проверить существование пути перед генерации URL. В данных случаях не используйте метод getRouteCollection() потому что он пересоздаёт кеш таблицы маршрутизации и замедляет приложение.

Вместо этого попробуйте создать URL и ловите исключение RouteNotFoundException , которое выбросится если маршрут не существует:

Загрузка маршрутов из файла¶

Вы уже видели, как вы с лёгкостью можете добавлять маршруты в коллекцию прямо внутри PHP. Но вы также можете загружать маршруты из множества различных файлов.

Компонент Routing поставляется с определённым количеством классов загрузчиков, и каждый предоставляет вам возможность загружать коллекцию определения маршрутов из внешнего файла какого-либо формата. Каждый загрузчик ожидает экземпляр FileLocator , в качестве аргумента конструктора. Вы можете использовать FileLocator , чтобы определить массив путей, в которых загрузчик будет искать запрошенные файлы. Если файл найден, загрузчик возвращает RouteCollection .

Если вы используете YamlFileLoader , то определения маршрута будут выглядеть так:

Чтобы загрузить этот файл, вы можете использовать следующий код. Предполагается, что ваш файл routes.yaml находится в том же каталоге, что и в коде ниже:

Кроме YamlFileLoader , существует два других загрузчика, которые работают таким же образом:

Если вы используете PhpFileLoader , то вам нужно предоставить имя PHP файла, который возвращает RouteCollection :

Маршруты, как завершители¶

Также существует ClosureLoader , который вызывает завершитель, и использует результат в качестве RouteCollection :

Маршруты, как аннотации¶

Наконец, существует AnnotationDirectoryLoader и AnnotationFileLoader , для загрузки определений маршрута из аннотаций класса. Конкретные детали здесь не рассматриваются.

In order to use the annotation loader, you should have installed the doctrine/annotations and doctrine/cache packages with Composer.

Annotation classes aren’t loaded automatically, so you must load them using a class loader like this:

Маршрутизавтор “всё-в-одно씶

Класс Router является пакетом “всё-в-одном”, для быстрого использования компонента Routing. Конструктор ожидают экземпляр загрузчика, путь к главному определению маршрута и некоторые другие настройки:

С опцией cache_dir , вы можете включить кеширование маршрута (если вы предоставите путь), или отключить кеширование (если оно установлено, как null ). Кеширование производится фоново автоматически, если вы хотите его использовать. Базовым примером класса Router будет:

Если вы используете кэширование, компонент Routing скомпилирует новые классы, которые сохраняются в cache_dir . Это значит, что ваш скрипт должен иметь разрешение на запись в этой локации.

Поддержка маршрутизации Unicode¶

Компонент Routing поддерживает символы UTF-8 в путях маршрута и требованиях. Благодаря опции маршрута utf8 , вы можете сделать так, чтобы Symfony сопоставляла и генерировала маршрут с использованием UTF-8 символов:

В этом маршруте, опция utf8 установлена как true , что заставляет Symfony рассмотреть требование . на соответствие каким-либо символам UTF-8, вместо одного символа байта. Это означает, что следующие URL будут соответствовать: /category/日本語 , /category/فارسی , /category/한국어 , и т.д. В случае, если вы хотели знать, эта опция также позволяет включать и сопоставлять эмоджи в URL.

Вы можете тоже включать UTF-8 строки в качестве требований маршрутизации:

Кроме символов UTF-8, компонент Routing также поддерживает все свойства PCRE Unicode, которые экранируют последовательности, соответствующие общим типам символов. Например, \p соответствует любым символам верхнего регистра на любом языке, \p соответствует любому греческому символу, \P соответствует любому символу, не включённому в скрипт Chinese Han.

Узнать больше¶

Эта документация является переводом официальной документации Symfony и предоставляется по свободной лицензии CC BY-SA 3.0.

Источник

Компонент Routing¶

Установка¶

Также вы можете клонировать репозиторий https://github.com/symfony/routing.

If you install this component outside of a Symfony application, you must require the vendor/autoload.php file in your code to enable the class autoloading mechanism provided by Composer. Read this article for more details.

Использование¶

Эта статья объясняет как использовать функции Routing как независимого компонента в любом приложении PHP. Прочитайте статью Routing для понимания как использовать его в приложениях Symfony.

Для тог, чтобы установить базову систему маршрутизации, вам нужно три составляющие:

• RouteCollection , который содержит определения маршрутов (экземпляры класса Route )
• RequestContext , который содержит информацию о запросе
• UrlMatcher , который выполняет соединение запроса с единственным маршрутом

Вот быстрый пример. Заметьте, что предполагается, что вы уже сконфигурировали ваш автозагрузчик, чтобы он загружал компонент Routing:

Параметры RequestContext могут быть наполнены значениями, хранящимися в $_SERVER , но легче использовать компонент HttpFoundation, как объясняется ниже .

Вы можете добавлять к RouteCollection столько маршрутов, сколько хотите.

Метод RouteCollection::add() берёт два аргумента. Первый — это имя маршрута. Второй — объект Route , который ожидает URL путь и некоторый массив пользовательских переменных в своём конструкторе. Этот массив пользовательских переменных может быть чем угодно важным для вашего приложения и возвращаться при сопоставлении маршрута.

UrlMatcher::match() возвращает переменные, которые вы установили в маршруте, а также рандомные заполнители (см. ниже). Теперь ваше приложение может использовать эту информацию, чтобы продолжать обработку запроса. В дополенение к сконфигурированным переменным, добавляется ключ _route , который содержит имя соответствующего маршрута.

Если соответствующий маршрут не может быть найден, будет вызвано ResourceNotFoundException .

Определение маршрутов¶

Полное определение маршрута может содержать до семи частей:

1. Маршрут пути URL. Он сопоставляется с URL, переданным RequestContext , и может содержать названные рандомные заполнители (например, ), чтобы соответствовать динамическим частям URL.
2. Массив значений по умолчанию. Содержит массив арбитражных значений, которые будут возвращены, когда запрос соответствует маршруту.
3. Массив требований. Он определяет ограничения значений заполнителей в виде регулярных выражений.
4. Массив опций. Они содержит внутренние настройки для маршрута и является наименее необходимыми.
5. Хост. Сопоставляется с хостом запроса. Смотрите /routing/hostname_pattern , чтобы узнать больше.
6. Массив схем. Форсирует определённую HTTP схему ( http , https ).
7. Массив методов. Форсирует определённый метод HTTP запроса ( HEAD , GET , POST , …).

Рассмотрите следующий маршрут, который объединяет несколько из этих идей:

В этом случае, маршрут сопоставляется с /archive/2012-01 , так как метасимвол соответствует регулярному выражению заданного метасимвола. Однако, /archive/foo не соответствует, так как “foo” не подходит метасимволу месяца.

При использовании метасимволов, они возвращаются в виде массива, при вызове match . Часть пути, с которой сопоставляется метасимвол (например, 2012-01 ), используется в качестве значения.

Если вы хотите сопоставить все URL, которые начинаются с определённого пути и заканчиваются произвольным суффиксом, вы можете использовать следующее определение маршрута:

Использование префиксов¶

Вы можете добавлять маршруты или другие экземпляры RouteCollection к другой коллекции. Таким образом, вы можете построить древо маршрутов. Кроме того, вы можете определить префикс и значение по умолчанию для параметров, требований, опций, схем и хоста для всех маршрутов поддрева, используя методы, предоставленные классом RouteCollection :

Установка параметров запроса¶

RequestContext предоставляет информацию о текущем запросе. Вы можете определить все параметры HTTP запроса с этим классом через его конструктор:

Обычно вы можете передать значения из переменной $_SERVER , чтобы наполнить RequestContext . Но если вы используете компонент HttpFoundation , вы можете использовать его класс Request , чтобы наполнить RequestContext с помощью сокращения:

Генерирование URL¶

В то время как UrlMatcher , пытается найти маршрут, который соответствует заданному запросу, вы можете также построить URL из определённого маршрута:

Если вы определили схему, генерируются абсолютный URL, если схема текущего RequestContext не соответствует требованию.

Проверка существования пути¶

В динамично развивающихся приложениях может быть необходимо проверить существование пути перед генерации URL. В данных случаях не используйте метод getRouteCollection() потому что он пересоздаёт кеш таблицы маршрутизации и замедляет приложение.

Вместо этого попробуйте создать URL и ловите исключение RouteNotFoundException , которое выбросится если маршрут не существует:

Загрузка маршрутов из файла¶

Вы уже видели, как вы с лёгкостью можете добавлять маршруты в коллекцию прямо внутри PHP. Но вы также можете загружать маршруты из множества различных файлов.

Компонент Routing поставляется с определённым количеством классов загрузчиков, и каждый предоставляет вам возможность загружать коллекцию определения маршрутов из внешнего файла какого-либо формата. Каждый загрузчик ожидает экземпляр FileLocator , в качестве аргумента конструктора. Вы можете использовать FileLocator , чтобы определить массив путей, в которых загрузчик будет искать запрошенные файлы. Если файл найден, загрузчик возвращает RouteCollection .

Если вы используете YamlFileLoader , то определения маршрута будут выглядеть так:

Чтобы загрузить этот файл, вы можете использовать следующий код. Предполагается, что ваш файл routes.yaml находится в том же каталоге, что и в коде ниже:

Кроме YamlFileLoader , существует два других загрузчика, которые работают таким же образом:

Если вы используете PhpFileLoader , то вам нужно предоставить имя PHP файла, который возвращает RouteCollection :

Маршруты, как завершители¶

Также существует ClosureLoader , который вызывает завершитель, и использует результат в качестве RouteCollection :

Маршруты, как аннотации¶

Наконец, существует AnnotationDirectoryLoader и AnnotationFileLoader , для загрузки определений маршрута из аннотаций класса. Конкретные детали здесь не рассматриваются.

In order to use the annotation loader, you should have installed the doctrine/annotations and doctrine/cache packages with Composer.

Annotation classes aren’t loaded automatically, so you must load them using a class loader like this:

Маршрутизавтор “всё-в-одно씶

Класс Router является пакетом “всё-в-одном”, для быстрого использования компонента Routing. Конструктор ожидают экземпляр загрузчика, путь к главному определению маршрута и некоторые другие настройки:

С опцией cache_dir , вы можете включить кеширование маршрута (если вы предоставите путь), или отключить кеширование (если оно установлено, как null ). Кеширование производится фоново автоматически, если вы хотите его использовать. Базовым примером класса Router будет:

Если вы используете кэширование, компонент Routing скомпилирует новые классы, которые сохраняются в cache_dir . Это значит, что ваш скрипт должен иметь разрешение на запись в этой локации.

Поддержка маршрутизации Unicode¶

Компонент Routing поддерживает символы UTF-8 в путях маршрута и требованиях. Благодаря опции маршрута utf8 , вы можете сделать так, чтобы Symfony сопоставляла и генерировала маршрут с использованием UTF-8 символов:

В этом маршруте, опция utf8 установлена как true , что заставляет Symfony рассмотреть требование . на соответствие каким-либо символам UTF-8, вместо одного символа байта. Это означает, что следующие URL будут соответствовать: /category/日本語 , /category/فارسی , /category/한국어 , и т.д. В случае, если вы хотели знать, эта опция также позволяет включать и сопоставлять эмоджи в URL.

Вы можете тоже включать UTF-8 строки в качестве требований маршрутизации:

Кроме символов UTF-8, компонент Routing также поддерживает все свойства PCRE Unicode, которые экранируют последовательности, соответствующие общим типам символов. Например, \p соответствует любым символам верхнего регистра на любом языке, \p соответствует любому греческому символу, \P соответствует любому символу, не включённому в скрипт Chinese Han.

Узнать больше¶

Эта документация является переводом официальной документации Symfony и предоставляется по свободной лицензии CC BY-SA 3.0.

Источник