Laravel по-русски

да не, вроде в сессии нормально хранить всё. если хостинг простой совсем, можно и сессии в базу перенести (драйвер 'database'), может оказаться что к базе обращаться быстрее чем к файлам…

ps. единственное что надо проверить как всё работает в случае, если пользователь заполнил часть данных в форме создания продукта, они попали в сессию, пользователь закрыл форму создания продукта, ушёл на другую страницу, а потом снова нажимает «создать продукт» – что он увидит в этом случае в данных формы? как эта форма будет работать с учётом того что в сессии уже есть какие-то данные? как это всё должно работать по ТЗ/логике/здравому смыслу/ожиданиям пользователя?

что только люди не придумают, лишь бы редис не использовать

Androbim, попробуй так, для общего развития, представить сколько запросов будет генерировать твой метод и сколько памяти потреблять если нужно будет отранжировать, ну, хотя бы миллион записей…

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

ну это конечно гадание на кофейной гуще, но вот мои варианты:

1) дополнительный редирект после того как произошёл редирект – инпуты и ошибки закидываются в сессию «одноразово», то есть доступны только на следующем запросе. если по какой-то причине следующий запрос закончился также редиректом – они не «доживут» до того чтобы попасть в форму. проверяется открытием вкладки Network в DevTools браузера, отключением очистки списка при переходе и внимательным изучением того, что происходит при отправке формы
2) инпуты и ошибки на самом деле есть в сессии, просто что-то идёт не так при их отображении. проверяется установкой laravel-debugbar если он ещё не установлен и вдумчивым изучением вкладки Session на тему что в ней там такое есть после редиректа

сам FormRequest отдаёт редирект как положено. см \Illuminate\Foundation\Http\FormRequest::response()

я немного уточню – напрямую импортировать фасады из корневого неймспейса \ – нежелательно. причина в том, что сторонние библиотеки и расширения пхп добавляют в корень свои классы и там запросто можно импортировать чего-то не того. самый распространённый случай – пхп-расширение php-redis добавляет в корень класс Redis который перекрывает одноимённый фасад. работать гарантированно не будет и по какой причине – без бутылки не разберёшься

правильным является импорт фасадов из собственного неймспейса фасадов \Illuminate\Support\Facades, для валидатора это будет класс \Illuminate\Support\Facades\Validator. он полностью идентичен \Validator но гарантирует отсутствие конфликтов с окружением

а ещё интереснее – использовать биндинг параметров метода и контракты. в этом случае нам достаточно будет на экшен добавить параметр $validator с тайпхинтом на \Illuminate\Contracts\Validation\Factory. в этом случае мы избавляемся от статических зависимостей и можем покрывать этот код тестами – просто в тестах в качестве параметра будет передаваться не настоящий валидатор, а его mock

ну и пример кода конечно, куда без этого. на всякий случай скажу что пишу по памяти, не копипаста

<?php

namespace App\Http\Controllers;

use \Illuminate\Contracts\Validation\Factory as ValidationFactory;

class MyController extends Controller
{
    public function myAction(ValidationFactory $factory)
    {
        $validator = $factory->make(…);
        …
    }
}

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

ну он-то правильный, но указанной проблемы не должно было быть и с прежним htaccess.

погоди-ка, у тебя там вместо проекта симлинк лежит? у апача был какой-то параметр, при котором он не ходит по симлинкам, если они не принадлежат тому же пользователю, от которого он запущен…

вообще раз проект и так в home и под пользователем – логично было бы стартовать апача под тем же пользователем и назначит корнем хоста папку в /home. в таком случае /var/www и www-data вообще не нужны и даже мешают

ещё мысль есть такая, что с правами могут быть косяки если файлы или папки создавались или правились из-под рута. насколько я понимаю всё работает от www-data (и апач и пхп) в папке /var/www ? это не очень хорошо, но можно попытаться сделать так:

chown -R www-data:www-data /var/www
find /var/www -type f -print0 | xargs -0 chmod 0644
find /var/www -type d -print0 | xargs -0 chmod 0755

– полный сброс прав и владельцев на всё что находится внутри, может поможет?…

crash, ещё раз – задай отношение hasManyThrough и не изобретай то что уже изобретено, тебе Владислав уже даже ссылку на доку дал…

у View есть магический метод __toString(). так что в данном контексте можно сделать просто echo view(…)

ps. а не, невнимательно посмотрел код, в данном контексте ещё проще – $html = (string)view(…). и не надо никаких ob_start()

вывести в браузер конечно. из обработчика запроса можно много чего вернуть. тот же view превращается в текстовый ответ потому что содержит магический метод __toString(), специальной обработки для него там вроде нет. можно вернуть массив или Collection – тогда автоматом будет выставлен content-type: application/json и на результате будет сделать json_encode. в документации всё есть…

по-моему у mokynis просто не включен mod_rewrite в апаче. надо попробовать сделать a2enmod rewrite и выполнить systemctl restart apache2

ps. а не, прочитал первое сообщение, уже сделано. тогда не знаю…

в error.log апач что-нибудь интересное пишет?