Виндовс, пути с кириллицей и пробелами... Ох, чую много еще вопросов будет.
Что касается бд - попробуй зайти вручную в базу с указанным логином (root) и паролем.
Насколько я знаю, в новых версиях мускуля нет рута по дефолту. Так что вариантов решения два: либо изменить в .env подключение бд на реального юзера, либо зайти в базу и создать там рута.
Это может значить все что угодно. И то, что в коде есть ошибки, и то, что написанное не нравится проверяющему, считающему себя сеньором.
А вообще я бы предложил такой критерий. Берешь psalm ставишь в нем 0 уровень и прогоняешь по своему коду. Есть ошибки - не сеньор, т.к. сеньор (по моему имхо) не может не использовать статический анализатор сейчас.
PageUp, Вообще-то лучшего ответа представить сложно.
Не только указали на место, где возникает проблема, но еще и показали как и каким способом можно ее локализовать и починить. Опять же, способ - универсальный, и пригодится во многих ситуациях.
То что вы решили вместо этого действовать методом тыка, даже не поняв, что конкретно происходит в коде - ваше право.
Di Lee, Сложно говорить, не зная конкретики.
Например, если эта функция нужна для проверки параметров апи, чтобы потом сообщить, что введено неверно, то имеет смысл всегда возвращать массив errors, а затем действовать в зависимости от \count($errors). Тогда можно обойтись и без mixed.
Если же она должна быть прям универсальной, то тут возможен и вариант с объектом и много других.
Пока, по представленному коду, это все похоже на обычный валидатор. Соответственно все рассуждения относятся именно к валидатору.
В данном конкретном случае, поскольку речь идёт о валидации, то никакое исключение в принципе кидаться не должно.
Кстати да. Что-то я не подумал, что в таком случае если неверных параметров несколько, то мы узнаем только о первом. По-хорошему я бы возвращал true если все в порядке или массив неверных параметров. Исключения в данной ситуации, действительно, ни к чему.
Di Lee, Путаешь. Если метод начинается с is, то да, он должен возвращать true|false, но если метод возвращает true|false это вовсе не значит, что он должен начинаться с is.
Можно, конечно, извратиться и назвать как-то типа IsParamsCorrected, но это вряд ли кому нужно.
Я вообще не понимаю зачем в данном случае разные эксепшены.
Сделать один ParamException и кидать его в этом методе, а в message прикладывать ключ неверного параметра. Больше тут ничего не нужно.
LOWER(...) LIKE LOWER(...)
Вообще лучше бы так не делать, в этом случае будет произведен полный скан по таблице. Лучше сделать function-based index по title.
JQuery уже можно выкинуть.
Angular.js - React.js - Vue.js - выбери что-нибудь одно и лучше не первое.
Django или JavaScript - Node.js - Express - эээ. Не понял, что ты тут хочешь.
SQL - MySQL - PostgreSQL -> MongoDB - Можно оставить только PostgreSQL. В случае чего, не так уж сильно они все отличаются.