Где ошибка в SQL запросе?

verdex: наличие кавычек в названии таблиц - позволяет избежать двусмысленности некоторых выражений, например у вас таблица может называться "update", и запрос тоже, быть "update". Т.е. название таблицы может совпадать с одним из ключевых слов БД. И "обратные кавычки" (которые на Ё, не помню, как они называются правильно), позволяют решить эту проблемы. Разницы в том, "на ПХП" запрос или нет - нет вообще никакой, для базы нет разницы, кто именно ей отправил запрос. Это действительно и для MySQL и для других БД, с той разницей, что кавычки в разных БД могут быть разными и иметь разный смысл.

P.S. Значения переменных, заключать в одинарные кавычки обычно крайне желательно, всегда, даже если это целое число. Такой подход может избавить от ряда потенциальных проблем в будущем.

Как установить Laravel на обычный хостинг-сервер?

DenKG: ещё, если у Вас база (набор данных) довольно примитивные, не нуждающиеся в какой-то особой логике и у сервера есть SSH, можно рассмотреть механизм миграций, как рекомендует коллега OnYourLips . Так же при наличии SSH, можно попробовать и compser засунуть туда же, на сервер и обновлять папку "vendor" прямо на сервере. Она обычно самая большая (по кол-ву файлов) и загрузка/обновление через composer может сэкономить немного времени.

Как установить Laravel на обычный хостинг-сервер?

DenKG: именно так. И залить БД, "как есть", на сервер. И создать файлик .htaccess (есть по тексту выше), что бы корешок сервера для лары правильно определялся.

Как установить Laravel на обычный хостинг-сервер?

В большинстве случаев это возможно.

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

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

даже в "лабораторных условиях" и при идеальном раскладе - это не решает проблему примитивизма самих миграций. Теоретическая возможность отката не делает их менее примитивными, не добавляет им все возможные типы данных, которые есть в БД и всего остального. А невозможность выполнить одну любую операцию в производственном цикле, говорит о не ликвидности всей системы. То есть, "пациент либо жив, либо мёртв", вариант "пациент жив на 90%", к сожалению, невозможен. Так же как компьютер, не может работать в отсутствии одного из ключевых компонентов.

Что касается триггеров и т.д., то логика на уровне базы слишком дорого обходится.

При неправильном подходе, даже использование фреймворка слишком дорого обходиться. И есть ряд случаев, когда его использование просто невозможно. Я уже не говорю, про CMS... Есть случаи, когда даже использование JOIN'ов слишком дорого обходится. Но это не повод, перестать использовать JOIN'ы.

Всё зависит от того, что мы хотим получить на выходе. Если у нас стоит цель разработки и поддержки проекта в 1.5 человека, размещаемого на хостинге за 1-2$/мес., где кроме MySQL ничего нет, и сам MySQL настолько ограничен, что кроме создания таблиц - мы ничего не можем создавать кроме простых таблиц (даже View, т.к. это требует доп. привилегий пользователя) - то да, стоимость хостинга проекта на VPS (где мы сможем полноценно использовать хотя бы MySQL), может увеличить в 5-10 раз (до 5-10$/мес.). В этом раскладе в принципе, даже миграции в том виде, в каком они есть в Laravel - выглядят порой довольно привлекательно.

Если же говорить, исключительно о качестве конечного продукта и скорости его работы, предполагая, что мы можем использовать базу на 100%, и даже с учётом того, что базу будет использовать исключительно одно приложение - построение логики работы БД на уровне самой БД - может дать прирост производительности порой в 10-50 раз, за счёт сокращения накладных расходов, возможности использования внутренних механизмов БД. В том числе, планировщик запроса самостоятельно может оценить, какая операция будет менее затратной при использовании того или иного механизма, при получении/обработке данных, в т.ч. используя уже имеющиеся данные/параметры из самой БД. И даже если говорить, о примитивном триггере - триггер реализованный на уровне БД будет много быстрее, чем полная реализация этого же триггера, на уровне PHP-клиента. Хотя бы по тому, что сам механизм триггеров из БД никто не вырезал, и проверка наличия триггеров будет вызываться в любом случае... и было бы крайне странно, если бы запрос на уровне БД, сгенерированный самой БД, не проходящий все этапы парсинга, преобразования и т.д. - работал бы медленнее, чем аналогичный запрос, посланный с клиента и проходящий все эти этапы. Наличие обратного эффекта, говорит как правило, либо о низкой квалификации администратора БД (т.к. он просто не знает, как нужно строить логику на уровне БД правильно), либо о довольно странной реализации движка БД, в котором внутренние механизмы самого же движка, работают медленее, чем аналогичные механизмы написанные на клиенте (с учётом того, что база у нас обычно написана на С/С++, а клиент на PHP в данном случае и с учётом того, что клиент опять же, генерирует запросы к самой БД, а не вмешивается в её файловую систему или внутренние механизмы на низком уровне), либо, о совокупности обоих этих факторов.

Как установить Laravel на обычный хостинг-сервер?

OnYourLips: вообще, примерно у 30% хостеров есть SSH (и там можно в т.ч. попробовать запустить и композер и миграции и пр., но это немного выходит за рамки изначального вопроса). И, это не обязательно, можно напрямую залить базу, через phpMyAdmin, через PHP-скрипт или через любое другое соединение с БД. Или выполнить соотв. запрос, модифицирующий БД нужным образом.

Мы например, миграции в том виде, в котором они есть в Laravel, не используем вообще, за исключением крайне редких случаев, когда нужно где-то сохранить эдакий примитивный "сниппет" вместе с куском структуры данных, принадлежащих персонально ему (например, "новости" [просто "новости", без каких либо доп. механизмов]). В остальных случаях, миграции не только не могут обеспечить сохранение целостности (сохранности) данных, в т.ч. при "откатах", они не имеют даже возможности, создавать такие примитивные вещи, как например, триггеры на уровне MySQL, не говоря уже о каких-то более "глубоких" вещах, свойственных более полноценным БД (например, PostgreSQL). То есть, они даже из типов полей - имеют в своём наборе только базовые типы, не говоря уже про разные параметры (вроде "статистики", или "выражений для смены типа"). По сему, миграции в ряде случаев (в нашем варианте, примерно в 99%), миграции, по природе своей - бесполезны.

Почему могут не загружаться шрифты в мобильных браузерах?

Сергей Киселев: Ну... как Вы понимаете, глубоко в код, в попытках выяснить действительный источник проблемы - я не лез, но судя по первичным признакам "первый шрифт работает, второй нет", а так же основываясь на том факте, что первый шрифт был сконвертирован в форматы отличные от TTF, а второй нет - первое что мне пришло в голову - это как раз, форматы шрифтов (т.к. в консоли ошибок прогрузки шрифтов - не было).

Некорректная работа хеширования?

Что именно не работает, хеши не совпадают? или проверка не работает?

Как перенаправить вывод в лог в консоль PhpStorm?

Читаю вопрос ещё раз:

Но есть одна проблема: я не вижу что в лог появилась ошибка или предупреждение.

Подскажите, как дублировать лог-сообщения в консоль PhpStorm? Или как принято решать эту задачу?

Именно эти 2 задачи решает способ описанный выше. И что важно БЕЗ второго монитора.

Вывод (запись) в лог обычно делает непосредственно сама программа (в данном случае, Laravel), ни в одном известном мне случае, IDE в этом процессе не участвует.

Как перенаправить вывод в лог в консоль PhpStorm?

zencd: а второй монитор то зачем?

Как перенаправить вывод в лог в консоль PhpStorm?

Хорошо :)

Как перенаправить вывод в лог в консоль PhpStorm?

Так на вскидку (первое, что пришло мне в голову), запустить в консоли шторма:
tail -f /path/to/laravel/storage/logs/laravel.log
*это под никсами, под windows - поискать аналог программы tail из линукса.

Как разрешить скачивание файла только после ввода данных?

Cоломон Геннадьевич: я имею в виду, по объёму. тут кое-что написано по этому поводу...

Как разрешить скачивание файла только после ввода данных?

Смотря какой файл, как вариант - отдавать файл PHP-скриптом, предварительно проверяя, что там пользователь навводил.

Как реализовать таймер на php?

NikHaker: если у Вас Linux (за другие ОС не скажу) и Вы будете загружать какой-то файлы часто - он закэшируется операционной системой. Это конечно, не то же самое, что кэш уровня Redis или Memcached, но в целом, "дёргать диск" такая операция не будет. Тут конечно стоит учесть ряд факторов, например BluRay-фильм на 30Гб, вряд ли закэшируется... Но я бы скорее выбрал вариант с БД, там несколько больше возможностей на "будущее" (или же, вариант с Redis - он по моему, вообще идеально подходит, т.к. сам умеет кэш очищать). json_* - особо грузить не будет, если данные в каком-то разумном пределе. В целом такие операции выполняют довольно быстро и у PHP есть намного более чувствительные к производительности места и способы ускорения, нежели отказ от json_* :)

Нужно ли создавать БД под каждого пользователя?

Почитайте про "связи". Обычно делают одну базу, т.к. много баз связать между собой - будет проблематично, к тому же, производительности это не добавит (а скорее наоборот). Сущности хранятся в таблицах, и связь сущности с пользователем - хранится в связующей таблице... довольно сложно объяснить на пальцах это. Почитайте что-нибудь из учебников, по MySQL (она одна из самых простых SQL-баз), и многое Вам станет понятно. Мне в своё время вот такая книга понравилась.

Почему не работают скрипты из внешнего файла?

Игорь Воротнёв: тогда я думаю, вот такой вариант подойдёт.

Как сделать фото на сайте адаптивной для всех экранов?

Mr. Tabrest: я думаю, вот такой вариант подойдёт, с отделенными друг от друга html и body.

Как отказать так, чтобы не порвать отношения с заказчиком?

Денис Букреев: нормальная картина, я обычно так и делаю. Есть конкретная цена и минимальная сумма заказа. Всё остальное идёт лесом :))

Как делать адаптивные страницы?

Виктор Янышев: мне кажется, с документацией так вот сходу будет сложно... Я бы наверное всё же порекомендовал какой-то видео-курс, так будет нагляднее (визуально) :)))

Почему не работают скрипты из внешнего файла?

Решается проблема помещением js-скриптов прямо на страницу шаблона php, но не думаю, что так задумано) Кто-нибудь сталкивался с подобным?

В консоли ошибок нет?

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

Посмотрите заголовки сервера в ответе, возможно браузер кэширует всё это дело. Что бы победить такое поведение, добавляйте к адресу скрипта ?v=10, например так:
<script src="/js/script.js?v=10"></script>, где v=10 - условная версия скрипта. Можно вместо этого выводить например, дату (timestamp) из php. Тогда скрипт не будет кэшироваться. Или, просто отключите кэширование в браузере или на сервере.