Ловить исключение нужно там, где функция может его выбросить, в Вашем случае я не вижу функций, которые это могут делать (потому что код в процедурном стиле с простыми функциями, а не ООП). Достаточно проверки на некорректные значения, как написал rPman.
Это функция для имитации строки с уязвимостью, чтобы вручную не воспроизводить эту уязвимость в натуральном виде. Мне кажется что эта статья из Psalm хорошо описывает смысл этой уязвимости и способы устранения (а значит и смысл существования функции) https://psalm.dev/articles/detect-security-vulnera...
A constant is an identifier (name) for a simple value. As the name suggests, that value cannot change during the execution of the script (except for magic constants, which aren't actually constants).
Тут два ответа сразу, почему не должно работать и не будет - константа не может принимать выражения и константа не должна меняться во время выполнения (у Вас она зависит от магической константы __DIR__)
Один из вариантов поиска: database design for checkbox values.
Самые частые подходы - отдельная таблица с набором опций как колонок или же поле в основной таблице, где варианты ответов это побитовая маска.
Должен быть базовый layout (где есть блоки со статичным контентом) и файлы динамических блоков, которые его расширяют - так придется единожды менять футер/хедер/меню и по потребности - страницы с контентом. Это очень удобно реализовано в шаблонизаторах вроде blade и twig (они на 80% похожи)
DTO просто помогает отвязаться от прямой работы с сущностью/моделью и выносить туда всю предварительную инициализацию/обработку/валидацию, получается как дополнительный слой ответственности передачи данных, чтобы не решать это на уровне тех же моделей/сущностей или сервисов.
С DTO на разных сторонах двух микросервисов вопрос сложный)
ParamConverter (и ArgumentResolver) это дополнительные прослойки в жизненном цикле запроса симфони, это просто разруливатели сырых параметров запроса и их валидация/преобразование в объекты до этапа попадания в экшен контроллера. Судя по документации, в Yii2 такого функционала нет и действительно надо делать самому или упрощать его.
Daria Motorina
@glaphire Автор вопроса, куратор тега PHP
PHP developer
Я не знаю как это могло влиять, но я убрала xdebug из сборки докер контейнера и проблема ушла.
Буду рада комментариям и ответам, если кто-то может объяснить причину) UPD.
Оказывается есть такой баг, но описан на сайте xdebug https://bugs.xdebug.org/bug_view_page.php?bug_id=0...
Судя по сорцам класса Page, то никак, но можно попробовать создавать ивенты клика по элементам через джаваскрипт и запускать этот код через $page->evaluate. Гуглить по "javascript fire click event"
Эти ограничения заложены со стороны инфрастуктуры/веб-серверов вконтакте, в сдк этого и не должно быть - это просто прослойка кода для облегчения работы
Технически это возможно.
На практике так не делают, потому что код должен соответствовать стандартам PSR. Одно из явных упоминаний есть в PSR-1, пункт 3. https://www.php-fig.org/psr/psr-1/
Альтернативный синтаксис в php имеет смысл только при смешении php и не-php кода в одном файле. В случае в javascript это не так работает - php сразу влияет на структуру страницы, еще на этапе подготовки и отдаче кода браузеру, а js влияет на структуру dom-дерева (т.е. когда браузер сможет превращать код на странице в то, с чем js может работать). Самое близкий ответ на вопрос - это шаблонизаторы на js с похожими конструкциями, но это уже "надстройка", отдельные пакеты, а не конструкция языка
Можно использовать array_shift, чтобы удалить первый элемент и переиндексировать остальные. Массив будет передаваться по ссылке, поэтому он изменится после этой функции
Нужно найти место, где вызывалась эта константа и переписать код на использование редиректа.
Надо найти соответствие урла в браузере с обработчиком этого урла в коде (это или просто php файл, или контроллер с методом экшена, если речь про фреймворк).
В документации по функции header есть упоминание в комментариях, как делать 301й редирект.
