1) для разных типов роутов нужны разные экшены контроллера
2) роуты описываются сверху вниз от более точных до более частных, потому что роутер обрабатывает первое совпадение из списка роутов
Дмитрий, реализация пустого интерфейса это условная метка, это значит что класс начинает входить в какую-то группу более высокого уровня. Благодаря этому в коде можно уходить от конкретики при тайпхинтинге, можно указывать тип элемента как SomethingInterface $somethingClassInstance, и под это определение подойдут любые реализации интерфейса. Можно почитать про принцип подстановки Барбары Лисков, во многих шаблонах проектирования используется этот подход. Тут нет потребности реализовывать методы, только заставить класс явно входить в какую-то логическую группу и оперировать понятием группы, а не конкретной реализации
Andrei St, значит надо поднимать версии пакетов до полной совместимости с composer 2, или заводить локальный composer.phar ниже версии 2.0 в проекте, чтобы не бороться с пакетами, которые не имеют совместимости с ним
По самой ошибке не могу подсказать, но могу посоветовать снизить количество вложенных ифов (почитайте про цикломатическую сложность и как ее рефакторить), и поменять переменные на более осмысленные, чтобы не было случайного переиспользвания не той переменной, что нужна в итерации
alcoholivanov, чисто концептуально - вызов метода и запись основных и промежуточных данных в памяти всегда чего-то стоят, а какая структура этих данных будет и сколько они займут это второй вопрос. Вызов процедурной функции без класса тоже что-то потребит в памяти...
Андрей Ежгуров, go это хорошо, но php с ним не взаимозаменяемые. Сейчас так в нормальных проектах писать не принято, это ухудшает читаемость и типизируемость методов
Александр Иванов, нет, не нужно слать в личку) проверьте построчно значение $v на каждой строке, где Вы с ним работаете, тогда станет понятно где он ломается
У нас был нежесткий гитфлоу, сначала на дев серверах делали и тестили одну задачу-одну ветку, потом все протестированные задачи сливали в dev и выкатывали на стейджинг, если были баги то делали бранч от дева, фиксили и вливали фикс в дев. Потом идеально рабочий дев вливали в мастер, тестили на проде, после тестов вливали мастер в дев. Правда не помню, задачи для бранчей мы форкали от мастера или от дева, но идея была в том что после релиза дев ветка была условной копией мастера, а другие подвисшие задачи ребейзились с девом в случае чего.
Павел, похоже что у Вас в базе нет никакого флага, что заказ обработан или в процессе обработки (колонка status или что-то похожее), нужно переписать так, чтобы забранный заказ сразу помечался как занятый и не попадал больше в выборку.
Фокс Йовович а такой подход это альтернатива способу "маппим папку с логами из контейнера на папку внешней системы" или есть какой-то дополнительный смысл читать логи через команду? Это вопрос относительно подхода, для себя хочу понять, если можно объясните пожалуйста
2) роуты описываются сверху вниз от более точных до более частных, потому что роутер обрабатывает первое совпадение из списка роутов