Но разлогин не помогаетТо есть после разлогина в сессии остается $_SESSION['logged_user']?
function check_user_role($max_role, $role) {...
Исправляюсь вот полный код (там есть ответ на клиента!):Я понял, вы считаете что метод response()->json() сам выполняет ответ клиенту и завершает работу скрипта. Во первых, это не так (иначе там не нужен был бы ретурн), во вторых - респонс ожидается только из контроллера и роутера, и уже там происходит вывод клиенту. Сам респонс является как бы инструкцией что и как отдать.
а где банально посмотреть список этих ошибок на хосте?Зависит от хостинга. На некоторых вам дают полный доступ до директории логов, на некоторых это можно посмотреть только в каком-то разделе панели управления хостингом, а на каких-то логи выведены в директорию конкретного домена. Именно по этому гораздо эффективнее временно включить вывод ошибок. Да, это "не модно и фу, профи так не делают", но это в 10 раз быстрее и эффективнее. Хочешь рюшечек и восхищенных взгядов брутальных админов и коллег - смотри логи. Хочешь быстро пофиксить проблему - включи вывод ошибок. Хорошим вариантом может быть управляемое включение - например по какой-то гет переменной, но это может работать только с единой точкой входа, а у тебя какой-то самопал...
Может быть такое?нет, по тому что и 404 тогда бы не было, была бы та же 500, так как домен тот же.
All routes and controllers should return a response to be sent back to the user's browser. Laravel provides several different ways to return responses. The most basic response is returning a string from a route or controller. The framework will automatically convert the string into a full HTTP response
return response()->json($validator->errors(), 422);так это не кривой урл
Удивительно что на такой фундаментальный вопрос нет ответа "а как правильно"Ничего удивительного, так как структуры типа nested sets и EAV очень плохо дружат с реляционными схемами хранения, не в плане плохо хранят, а в плане плохо собираются как запросы. В следствии этого факта рождаются не всегда удачные решения, или более-менее применимые в каких-то случаях, но полного и четкого ответа нет именно по причине того что эти структуры больше подходят для итеративного рекурсивного перебора, нежели для индексированной выборки. Вот и плодятся разные способы, ситуативно подходящие в каких-то конкретных случаях.
ini_set('error_reporting',E_ALL);
ini_set('display_errors', 1);если обращаться напрямую, то выдает вот это:Это не напрямую, это вы обращаетесь к несуществующей папке, так как не очень понимаете как работает веб сервер...
А вопрос был также в том как потом запрашивать товарыникак, они должны дергаться одним запросом, через джоин к выбранным категориям, а не выбираться на основе какой-то логики приложения.
годится ли WHERE INГодится, но выглядит костыльным решением, так как опирается на логику приложения, создавая массу запросов на пустом месте...