Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Не удержусь, дам ещё годноты 
Когда-то писал собственные обёртки DBAL над mysqli и PDO. В частности, для упрощения работы с массивами. Так вот, если вы хотите "автоматизировать" списки параметров из массива, можете вместо пустого массива подставлять NULL. Таким образом избежите синтаксических ошибок и лишних if-ов в вызывающем коде.
Запрос вида
.. WHERE x IN (NULL)вернёт пустой набор, даже если x null-able и в колонке есть значения NULL !
Пруф: http://sqlfiddle.com/#!9/1cd3c3/1
Про магию NULL в SQL полезно знать даже тем, кто не использует SQL напрямую 
кто делает "обновления", тот и будет владельцем, очевидно. в то же время, скрипты сайта могут создавать свои файлы, как например кеш, загруженные пользовательские файлы, логи и т.п. поэтому как минимум некоторые папки придется дать на запись группе. но п.м.с.м. таки не для всего сайта, а только то, что необходимо.
хорошая паранойя не повредит.
ри условии, что www-data - владелец корневой папки ресурса, а пользователь, от имени которого осуществляются, например, "обновления" на сервере, входит в группу www-data
а вот такие расклады это как раз "особые условия". и ответ кажется очевиден )))
Если нет особых условий, то права рекомендуется давать только владельцу, отказывая даже единогрупникам, т.е. не боле чем 0755 для папок и 0644 для файлов.
P.S. так как PHP 5 уже не поддерживается официально ( http://php.net/supported-versions.php ), тебе полюбомупора сменить хостинг. ну или задать вопрос службе поддержки, вдруг они предоставляют возможность апгрейда до PHP 7.1.
Недавно начал изучать Laraval 5.4
…
"Ожидается символ ?". Вот дословный текст ошибки "Parse error: syntax error, unexpected '?'
в точности наоборот, означает неожиданное появление "?".
для Laraval 5.4 достаточно PHP >= 5.6.4 https://laravel.com/docs/5.4/installation
ты видимо поставил какую-то другую версию. в v5.5 там действительно есть фишки из седьмого PHP:
$arguments[1] ?? null
в то время как в 5.4 там такое:
isset($arguments[1]) ? $arguments[1] : null
как поставить laravel определённой версии:
https://stackoverflow.com/a/35163627/272885
Вспомнил про старый способ : <script src="{{ asset('js/funcs.js') }}{{ "?dt=".time() }}"></script>
<script src="{{ asset('js/app.js' ) }}{{ "?dt=".time() }}"></script>
<script src="{{ asset('js/my_app.js') }}{{ "?dt=".time() }}"></script>вроде, помогает...
Это будет означать устаревание кеша при каждом запросе. Если ваша цель нагрузить свой сервер по максимуму, а посетителя нагрузить лишним трафиком, то да, норм решение.
Мой совет: привязать версию ассетов к деплою. одно обновление сайта - одна смена версий. https://php.ru/forum/threads/versii-ass … ost-542044
У тебя значение по умолчанию для сортировки почему-то "*". "order by *" это что-то новенькое 
Сколько параметров у метода get() ? А сколько ты пытаешся использовать?
Когда тебе надо отсортировать по нескольким колонкам, вызови метод orderBy несколько раз, или передай ему массив.
Пробуй, ёмана, опыт сын ошибок трудных.
зачем в классе указывать пространство имён? Почему оно не определяется автоматически на основе пути к файлу?
потому что пока что люди командуют машинами, а не наоборот. машины могли бы просто расставить нужные байты на нужных места. а в человеческом мире надо чтобы читающий видел полное имя класса, т.е. неймспейс + имя.
судя по всему, это костыль.
автоматически вычисленный обратный адрес не соответствует реально существующему и поэтому зарубается почтовой системой. надо просто явно указывать From и Reply-To, а не суперглобальные переменные портить
С другой стороны, какие альтернативы? Писать SQL от руки и вставлять данные прямо в него, рискуя получить SQL injection? Построитель запросов - меньшее зло.
можно вообще без зла: SQL запрос с параметрами.
сам же пишешь, что "цепочка запросов это приближение к SQL", — истинная правда. некоторое подмножество запросов можно довольно дословно выразить через эти цепочки, а некоторые будет трудновато или вообще не получится, потому что SQL очень богат.
построитель запросов отлично справляется там, где нужен именно построитель запросов, простите за тавтологию. например когда визуальный "фильтр" с чекбоксами и радиобатонами надо транслировать в запрос к базе.
ну или для тех разработчиков, кто ниасилил SQL и ему проще оставаться в рамках Query Builder.
Но поинтересуюсь: а за что такого страшного в старом добром SQL?
Proger_XP пишет:В том, что где сырой запрос, там и SQL injection.
ага, а ORM типа без использования SQL работает, на чистом волшебстве.
топикстартер изначально показал запрос с плейсхолдером. почему вдруг контекст поменялся на прямую вставку строки в тело запроса?
Я всего лишь спросил совета, как мне в сыром запросе адекватно вставить переменную в условие IN().
создать столько плейсхолдеров внутри IN, сколько елементов в массиве. принцип тот же, что и на "голом PDO".
https://stackoverflow.com/a/29653461/272885
очевидно что пустому массиву соответствует пустой результат, и запрос можно не выполнять вообще.
С какой-то непонятной ошибкой может справиться только какой-то непонятный специалист.
Больше конкретики, пожалуйста.
Тот случай, когда непонятно зачем избегали SQL
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)
