Для поиска шелла иногда полезно сделать поиск по всем файлам проекта на наличие "eval". Мне нередко такой метод помогал найти и вычистить зловреда. А вообще да, если держать сайт на очень популярном движке и не заниматься своевременным обновлением, то шансы взлома очень велики.
siv1987: Учитываю скорость их выполнения, этот примерно тот же случай.
Не могу согласиться. Все зависит от контекста, в случае ТС "стоимость" вызова php_sapi_name, empty, а также sizeof и count всерьез рассматривать, действительно, смысла нет. Peace :)
будет выполняться и на локальном и на продакшп серверах, т.е значение $_SERVER["REMOTE_ADDR"] везде будет одинаковым (127.0.0.1 в вашем случае) и подстановка конфигурации в зависимости от окружения не будет работать
siv1987: За то куда быстрее чем выполнения hostname.
Это к предмету обсуждения (нашего с вами, в рамках этой ветки) отношения не имеет.
---------- Добавлено 28.05.2013 в 22:29 ----------
siv1987: А "вызов" функции это та же фингя как спорить что быстрее sizeof или count.
Empty не является функцией, в отличие от php_sapi_name(), поэтому их вызов существенно отличается по потреблению ресурсов. Сравнивать быстродействие sizeof или count - несколько другой случай.
---------- Добавлено 28.05.2013 в 22:33 ----------
R34-zevs, попробуйте вот такой вызов в кроне на продакшн-сервере:
$hostname = trim(`hostname`);
if ('production.server.host.name' == $hostname) {
// Используем данные для продакшн-сервера
} else {
// Используем данные для локального сервера
}
MarkDuck: Как то, что js убирается в отдельный файл, влияет на скорость страницы?
Влияет вот как - при первой загрузке страницы работать будет медленнее, потому что вместо 1-го HTTP-запроса браузеру придется делать 2: первый на саму страницу и второй на js-файл. Но при повторном визите браузер пользователя будет загружать только html-код, без javascript, js-файл уже будет в кэше. Если ваши пользователи будут заходить на страницу по 5 раз в день, то выносить javascript в отдельный файл имеет смысл, если же страницу одни и те же пользователи будут посещать нечасто, то лучше js-код не выносить.
Для поиска шелла иногда полезно сделать поиск по всем файлам проекта на наличие "eval". Мне нередко такой метод помогал найти и вычистить зловреда. А вообще да, если держать сайт на очень популярном движке и не заниматься своевременным обновлением, то шансы взлома очень велики.
Учитываю скорость их выполнения, этот примерно тот же случай.
Не могу согласиться. Все зависит от контекста, в случае ТС "стоимость" вызова php_sapi_name, empty, а также sizeof и count всерьез рассматривать, действительно, смысла нет. Peace :)
И что с того я так и не понял?
Вот это условие:
будет выполняться и на локальном и на продакшп серверах, т.е значение $_SERVER["REMOTE_ADDR"] везде будет одинаковым (127.0.0.1 в вашем случае) и подстановка конфигурации в зависимости от окружения не будет работать
За то куда быстрее чем выполнения hostname.
Это к предмету обсуждения (нашего с вами, в рамках этой ветки) отношения не имеет.
---------- Добавлено 28.05.2013 в 22:29 ----------
А "вызов" функции это та же фингя как спорить что быстрее sizeof или count.
Empty не является функцией, в отличие от php_sapi_name(), поэтому их вызов существенно отличается по потреблению ресурсов. Сравнивать быстродействие sizeof или count - несколько другой случай.
---------- Добавлено 28.05.2013 в 22:33 ----------
R34-zevs, попробуйте вот такой вызов в кроне на продакшн-сервере:
А в самом скрипте вот такой вызов:
getenv("IS_PROD_SERVER_ENV");должен вернуть заданное значение.
А crontab это что, внешний сервер? Тут уж ТС как-то сам разберется какой у него локальный а какой нет.
А если и на локальном и на продакшн серверах нужно будет в cli запускать?
Это против фэншуя?
Без понятия, не силен в фэншуе. Но вызов функции по-любому "дороже" проверки переменной на пустое значение.
или
У ТСа вроде CLI на production, а такой код сделает скрипт нерабочим, т.к. будут использоваться реквизиты для локального сервера.
Кстати, самый простой способ проверки на CLI-режим, это:
и не нужно никаких php_sapi_name()
Вот for93t -тот спалил нужный плаг раньше времени ;)
Ага, не дотерпел 🤣
InstantCMS, позиционируется как система управления сообществами. Посмотрите, возможно, вам подойдет.
WP Minify умеет объединять все нужные CSS и JS файлы в один попутно сжимая их. Полагаю, это то, что вам нужно.
Как то, что js убирается в отдельный файл, влияет на скорость страницы?
Влияет вот как - при первой загрузке страницы работать будет медленнее, потому что вместо 1-го HTTP-запроса браузеру придется делать 2: первый на саму страницу и второй на js-файл. Но при повторном визите браузер пользователя будет загружать только html-код, без javascript, js-файл уже будет в кэше. Если ваши пользователи будут заходить на страницу по 5 раз в день, то выносить javascript в отдельный файл имеет смысл, если же страницу одни и те же пользователи будут посещать нечасто, то лучше js-код не выносить.