Логика в каждом посреднике практически одинакова, просто самого кода этой логики довольно мало, везде используются разные модели и случаются некоторые нестандартные ситуации, всё это можно засунуть в один посредник и все схожие логики сварить в одну, а для обработки тех нестандартных ситуаций сдобрить её некоторым количеством булевских конструкций.
Я думаю тут наверное всё дело уже в психологии, все на столько помешались на принципах solid, что перестали видеть чувство меры. А Laravel настолько SOLID, что для того что-бы взять и навалить всё в один скрипт, нужно заручится психологической поддержкой на тостере))))
Alexander: Вообще ошибки php должны куда-то обязательно писаться, а вот куда они пишутся должно быть указано или в настройках хостинга, или указано в .htaccess
php_value log_errors "On"
php_value error_log /var/log/errors.log
К Laravel это не имеет отношения, у Laravel своя система логирования до которой может просто не дойти.
Иметь под рукой все логи, а именно ошибки скриптов (errors.log) и ошибки доступа (access.log) необходимо, так как кроме логов на продакшн, вам никто ничего не скажет, ибо вывод ошибок на экран на проде должен быть отключен наглухо.
Андрей Самойленко: Ты совсем поехавший? Во первых про php.ini вообще вскользь написано, речь идёт о файле .htaccess, во вторых даже на дешёвых хостингах где в качестве панели установле ISP и есть режим запуска php в режиме CGI то автоматом создаётся php.ini который можно править. Специально для такого как ты, пруф: https://s.mail.ru/DKuU/DHjUVN9Gd Это дешёвый хостинг host-food.ru.
JhaoDa: Действительно, у меня в приложении просто какой-то глюк (или конкретно в моей версии Laravel) Поставил последнюю версию, всё отлично работает. Не понимаю в чём была причина, всё один в один, контроллеры просто скопировал.
... отсутствует столбец, который по смыслу должен содержать переменные сессии (если только payload это не зашифрованный массив), я думаю что при использовании драйвера базы данных для сессии, просто не предполагается хранить в сессии какие-то значения (т.е. сам делай таблицы, и привязывай их к user_id если используешь модель User), хотя не могу пока разобраться.
MrChen: Что значит стоит-ли? Конкретно Remember Token и существует для того что-бы по нему проверяли пользователя. Это как отпечаток уже совершённой аутентификации на конкретном устройстве в конкретном браузере. Это нужно что-бы не вводить каждый раз логин и пароль, и естественно что для этого нужно проверить пользователя по Remember Token. А для задачи "тот ли этот человек, который хочет войти в свой кабинет или какой-то другой" существует другой механизм который называется авторизация.
Сергей Беловенцев: Ну может быть Вам кто-то прям распишет до мелочей, я только направление дал, тут вроде и додумывать особо нечего суть то показана, мы указываем разные таблицы и можем использовать все их поля для условия выборки, если у них есть "общие поля", то просто указывайте их в условиях book.created_at, video.created_at и т.д.
Станислав Почепко: И опережая скажу, что на самом деле я так делать скорее всего не буду, и просто начну пихать всю статистику в google nosql к примеру, просто хочется понять как это можно сделать на Laravel я пока только учусь
Да я читал, там мы указываем имя соединения но оно прописано в массиве конфигов, а в моём случае нужно создать базу и начать с ней работать. Тут как-то надо динамически создать модель которая-бы работала с данным соединением.
Да ничего такого крутого, просто выношу (себе мозг) мусорные данные статистики в отдельные файлы для каждого юзера (костыльный шардинг), дабы не держать их в основной базе и потом каждый месяц убирать в облако до востребования :) На чистом php проблем нет, я так уже делал, а теперь вот как бы это сделать на ларавеле, что-бы по человечески.
Максим: Тут как раз белый список, а не список запрещённых, восклицательный знак же стоит
Например: RewriteCond %{REQUEST_URI} !\.zip$ Файлы кроме тех что с расширением .zip
Алексей Уколов: Большое спасибо за направление мысли, в любом случае мои страхи про производительность неуместны ибо всё тестируется, а вот такую архитектуру как сейчас показывать стыдно.
Алексей Уколов: Да она уже работает, гибкости хватает (пока), просто хочется некоторые моменты сделать правильно, а не "лишь бы работало", хотя повторюсь всё работает. Так что обе ноги я себе уже отпилил)) Теперь вот надо либо учится бегать на культяпках, либо всё заново собирать, я к сожалению не опытен в разработке проектов таких масштабов, а времени на опыт катастрофически не хватает.
Алексей Уколов: Спасибо, но тут есть момент, у области должен быть только один owner и не при каких обстоятельствах не должно быть более одного, а для суперадминов существует ещё одна таблица supervisors где пользователям даётся разрешение с привязкой к группе, пока этого достаточно.
Алексей Уколов: в том числе и ради производительности, это CRM и бд у неё достаточно узкое место, и таблица с пользователями единственная которая не поддаётся шардингу, шардинг как раз строится на пространствах (и подпространствах)
Алексей Уколов: Идея отличная, но не появится ли в результате из за pivot-таблицы (и сама таблица будет увесистая) куча дополнительного кода и как следствие дополнительная нагрузка на бд, ведь вот такое тройное сохранение используется только один раз при создании, в остальных случаях используются отношения.
Я думаю тут наверное всё дело уже в психологии, все на столько помешались на принципах solid, что перестали видеть чувство меры. А Laravel настолько SOLID, что для того что-бы взять и навалить всё в один скрипт, нужно заручится психологической поддержкой на тостере))))