$str = sprintf( "This is %s and this is %s and if %d", trim($var1), // Переменная один тут строка от туда trim($var2), // Переменная два тут строка от туда $var3 === $var4 ? $var5 : $var6 // А тут должно быть число );
Вообще нечитаемая хрень. Я в голове должен соображать, что куда подставлять. Вместо того, чтобы просто прочитать 1 строчку со всеми переменными.
Prepare не панацея от внедрений кода, в обоих случаях надо подготавливать данные. Чтобы не передали отрицательные числа, как пример. И вообще мусор не закидывали.
А когда у нас запрос динамический это вообще туши свет работать с Prepare. Есть инструменты, и ими надо пользоваться с головой.
Поэтому ВСЕГДА надо обрабатывать данные перед запросом, а когда они от клиента, так в двойне надо всё проверять.
Что касается вопроса ТС, то никакой разницы нет в логике работы, но скобки{} для "" просто лишние и не несут никакой пользы т.к. переменные и так обрабатываются в двойных кавычках. Но мне больше нравится стиль ".$var." т.к. можно быстренько накинуть ".trim($var)." если надо.
Чистая установка или вы пытаетесь обновиться?
В гугле ничего интересного нет?
это очень тормозной способ защиты от ддос и другого спамного трафика, который может приводить к отказам в обслуживании
нужно действовать хотя бы через .htaccess и mod_rewrite
Можно побольше доводов, про "ОЧЕНЬ" почему apache будет быстрее работать, чем PHP?
Я уж промолчу, что apache будет реагировать на все типы файлов, если nginx не подключен.
if (preg_match('@Mozilla/5\.0 \(Macintosh; Intel Mac OS X 10_15_7\) AppleWebKit/537\.36 \(KHTML, like Gecko\) Chrome/(.*?) Safari/537\.36@smi',$_SERVER['HTTP_USER_AGENT'])) { exit(); }
Так я и сам их убрать могу ) Смысл в том, чтобы счетчики, коды рекламы и пр. остались, но оптимизировать их загрузку. Сделать стерильный сайт, состоящий только из текста, несложно как раз.
Я вам говорю о тестовой площадки, что там происходит. На реальном сайте, конечно же надо всё это оптимизировать, чтоб всё осталось.
И что за чудо-инструмент?
Система проксирования любого сайта . Далее происходит сжатие CSS и JS, убирается из HTML разного рода не нужные элементы (метрики, счётчики), включается lazyload, картинки тоже проксируются и сразу оптимизируются.
На выходе получаем уже оптимизированную страницу, которую можно проверить через Google PageSpeed. Если результат есть, то уже можно всё воплощать в жизнь на живом сайте.
Тут ещё информация: https://getmanyspeed.ru/tarif-free.html
Однако в массе всё происходит наоборот. Борьба с последствиями непродуманности. Вот тут и нашли большой отклик все эти оптимизирующие производительность плагины.
Да, реальность диктует свои правила. Именно для этого я создал себе инструмент, который мне показывает результат оптимизации заранее до начала работ. Поэтому у меня есть возможность не тратить время на сайты, которые просто надо переделывать. Объясняю это клиентам. Некоторые понимают, некоторые идут искать "чудо" дальше.
Вы не так смотрите на проблему.
Бесплатные плагины или платные, это лишь "затычки" перед нормализацией работы сайта. Есть платные, есть бесплатные. В бесплатных так же есть платные функции. Но не суть.
Если разработчики уже всё оптимизировали и сделали лёгкий сайт, то оптимизация или вообще не нужна, или лишь "лак для блеска".
В случаи если сайт УГ полное, тогда да, чем "затычка" больше, тем лучше и дольше может оттянуть процесс ускорения самого сайта.
Моя философия проста: "Быстрые сайты создаются, а не потом вдруг становятся"
