Zhaz

- Посмотрите, что в логах (/storage/logs/)
- Проверьте права на запись к папке /storage
- В .env включите APP_DEBUG=true

кому ваши гроши нужны? вы сначала сделайте. может, и жертвовать вам будут доллар в год. или вы собираетесь таким образом от налогов .... ах вы хитрец.

Используйте паттерны проектирования, SOLID. Прочитайте про архитектуру БД. Этого, в принципе, достаточно, чтобы не напороть ерунды в начале.

Паттерны - это реальные инструменты, позволяющие добиться реализации концепции объектно-ориентированного проектирования и принципов SOLID

Ссылка на SOLID

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

Один из наиболее часто встречающихся мне примеров, это пример принципа "Принцип открытости/закрытости" , когда класс - описывающий некую сущность(например модель комментария) , описывает только свои базовые назначения( создание, удаление, редактирование), при этом такие механизмы, как модерация, прикрепление файлов, лайки , реализуется другими классами и "прикручиваются" к классу моделей через интерфейсы и наследование/ трейты / примеси

При этом :
1) Никак не изменяется код класса "Комментарий" (кроме подключения интерфейса) и в будущем мы добавляем поведения без изменения класса + стабильность системы, гибкость
2) Каждый класс имеет свое четкое назначение + легкость модификации, порядок
3) Комментарии наследуют некоторое поведение, путем подключения поведения, но также могут поступать любые другие классы - сущности (посты, блоги итп) , то есть интерфейс и реализация лайков универсальна, и весь функционал работы лайков находится только (строго!!!) в одном месте + легкость модификации, Универсальность, стабильность, интуитивная понятность

Из википедии :

Признаки плохого проекта
Закрепощённость: система с трудом поддается изменениям, поскольку любое минимальное изменение вызывает эффект "снежного кома", затрагивающего другие компоненты системы.
Неустойчивость: в результате осуществляемых изменений система разрушается в тех местах, которые не имеют прямого отношения к непосредственно изменяемому компоненту.
Неподвижность: достаточно трудно разделить систему на компоненты, которые могли бы повторно использоваться в других системах.
Вязкость: сделать что-то правильно намного сложнее, чем выполнить какие-либо некорректные действия.
Неоправданная сложность: проект включает инфраструктуру, применение которой не влечёт непосредственной выгоды.
Неопределенность: проект трудно читать и понимать. Недостаточно четко выражено содержимое проекта.

Оттуда же про SOLID

Избавиться от "признаков плохого проекта"[4] помогают следующие пять принципов SOLID:

Принцип единственной ответственности (The Single Responsibility Principle)
Существует лишь одна причина, приводящая к появлению класса.

Принцип открытости/закрытости (The Open Closed Principle)
«программные сущности … должны быть открыты для расширения, но закрыты для модификации.»

Принцип подстановки Барбары Лисков (The Liskov Substitution Principle)
«объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.»

Принцип разделения интерфейса (The Interface Segregation Principle)
«много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения.»

Принцип инверсии зависимостей (The Dependency Inversion Principle)
«Зависимость на Абстракциях. Нет зависимости на что-то конкретное.»

Отправляете засечку времени от клиента на сервер (можно для точности 2-3 ajax-запроса), а сервер - считает смещение (в "+" или в "-" и на сколько) минус время на доставку пакета (по http/tcp-заголовкам).
Но лучше, это делать через websocket, периодически отсылая сигнал синхронизации сразу всем клиентам.

Наверное, надо написать что-то похожее на cинхронизацию времени между клиентом и серверами в NTP. Это потребует нескольких запросов к серверу, чтобы оценить время отклика – т.е. не сразу с загрузки страницы удастся точно запустить таймер. Показать его можно сразу, и в течение следущих секунд скорректировать. Есть готовое решение: NTPJS, не пробовал.

В простейшем варианте можно обойтись одним AJAX запросом после полной загрузки страницы. Запомнить текущее локальное время var tPing = (new Date).getTime();, запросить ajax'ом с сервера его текущее время tServ, получить ответ и запомнить локальное время tPong, когда ответ получен. И положиться на очень грубую гипотезу, что сервер ответил точно посередине интервала tPing..tPong. Т.е. решить, что разница серверного времени и локального составляет ровно tDiff = tServ - tPing + (tPong - tPing) / 2;

Теперь для получения предполагаемого серверного «точного» времени, просто прибавлять к текущему локальному времени этот tDiff.

Если файл уже под контролем (был ранее добавлен в репозиторий), то .gitignore на нем работать не будет. Что, собственно, и логично.
Есть два варианта:
- удалить файл -> закомитить -> добавить в .gitignore -> вернуть файл
- удалить из индекса (git update-index --assume-unchanged your-file) -> добавить в .gitignore