Жонглируем версиями PHP в системе

Производительность

В сети можно встретить множество синтетических и реальных тестов производительности разных версий PHP и HHVM, которые говорят только об одном — с каждой версией PHP веб становится быстрее и быстрее. Большинство же моих проектов работают на MODX Revolution и CodeIgniter 3. И, естественно, мне было любопытно узнать, что изменится после смены версии PHP.

MODX Evolution

Конечно, я бы мог проверить изменение производительности и для MODX Evolution, но в этой системе очень много кода, зависящего от, как я написал выше, удалённых расширений PHP. Однако, в версии , подготовленной пользователем , появилась полная поддержка PHP 7.

MODX Revolution

Итак, я взял несколько сайтов, работающих на PHP 5.6. Измеряю я обычно количество запросов и время на генерацию страницы. Логично предположить, что количество запросов мало коррелирует с версией PHP, но лишним добавить и эту информацию не будет. Начиная с версии MODX Revolution 2.5 реализована полная совместимость с PHP 7. До этого была лишь частичная поддержка PHP 7, ввиду чего у меня не работала админка, хотя сам сайт отлично работал.

Сайт №2

PHP 5.6, без кэширования — 166 запросов, 0.66 с.

PHP 5.6, с кэшированием — 3 запроса, 0.06 с.

PHP 7, без кэширования — 166 запросов 0.34 с.

PHP 7, с кэшированием — 3 запроса, 0.04 с.

Сайт №3

PHP 5.6, без кэширования — 177 запросов, 1.82 с.

PHP 5.6, с кэшированием — 10 запросов, 0.39 с.

PHP 7, без кэширования — 177 запросов, 0.51 с.

PHP 7, с кэшированием — 10 запросов, 0.18 с.

Как видно, переключение версии PHP на последнюю положительно сказалось на производительности сайтов, увеличив её в 1.5-3 раза, а кое-где (например, на главной странице моего сайта) даже в 10 раз.

Я не могу похвастаться большим количеством проектов на CodeIgniter, но даже они обязывают внимательно относиться к производительности, так как количество статей и уникальных посетителей в месяц на одном из них исчисляется тысячами. На данный момент я занимаюсь оптимизацией и рефакторингом одного из них, где и без перехода на PHP 7 производительность кое-где возросла в несколько раз. В ближайшее время, когда я закончу текущую работу, я обязательно напишу о результатах смены версии.

HipHop и прорыв в скорости

Facebook написан на PHP — проблему нужно было решать. Их программисты создали для пятой версии собственный интерпретатор языка. Они компилировали его изначально в промежуточные коды, а затем отправляли в обычный интерпретатор Zend Engine. Программисты Facebook ввели статическую типизацию и ускорили работу языка в два раза. Это стало настоящим прорывом. Транслятор назвали HHVM, или HPHP Compiler — «HipHop для языка PHP».

Но команда разработки PHP плотно занялась массивами. Итогом стала седьмая версия, которая работала быстрее HHVM. При этом статической типизации в PHP7 по-прежнему почти нет. Только в параметрах функции — но это так мало, что можно считать, будто нет.

С версии 7.0 до 7.3, которая сейчас в бета-тестировании, язык ускорялся — разница видна по замерам:


Результаты бенчмарков версий PHP на Bolt CMS 3.4.8

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

Защита и куки

Путь к каталогу /wp-admin/По умолчанию:
Позволяет включить загрузку файлов без фильтрования, пользователем с правом . Включает работу права . Если не включить эту константу, то юзеры с правом не будут проходить проверку current_user_can(‘unfiltered_upload’).Может быть:
Имя Cookie для авторизацииПо умолчанию:
Секретный ключМожет быть:
Добавка к секретному ключуМожет быть:
Хэш для генерации имен cookie
Путь к корневому каталогу WordPress.По умолчанию:
Домен который будет использоваться в setcookie() и для которого будут устанавливаться куки. По умолчанию это текущий домен, можно указать конкретный домен, например .site.ru, тогда куки будут действительны для домена site.ru и всех поддоменов: foo.site.ru, bar.site.ruПо умолчанию:
Позволяет переопределять список защитных меток HTML. Смотреть в /wp-includes/kses.php.Может быть: По умолчанию:
Позволяет запретить редактирование тем и плагинов с использованием редактора WordPress.Может быть:

Запрещает любое редактирование файлов в файловой системе WordPress (кроме директории для загрузок wp-content/uploads):

define( 'DISALLOW_FILE_MODS', true );

Учтите, что установив эту директиву вы больше не сможете устанавливать и обновлять темы и плагины через панель администратора. Вам придётся это делать вручную с помощью FTP или SSH.

Может быть:

Позволяет запретить не фильтрованные HTML для всех пользователей, включая админа. Некоторые привилегии можно отключить на уровне
конфигурационного файла wp-config.php, например можно запретить всем пользователям (включая администраторов и сетевых администраторов) публиковать не фильтрованный HTML с помощью:

define( 'DISALLOW_UNFILTERED_HTML', true );

Может быть:

Активирует SSL для админки и в панели управления.Может быть: По умолчанию:
Активирует SSL для страницы входа.Может быть: По умолчанию:
Имя Cookie для авторизации.По умолчанию:
Секретный ключМожет быть:
Секретный ключМожет быть:
Секретный ключМожет быть:
Секретный ключМожет быть:
Имя Cookie для пароляПо умолчанию:
Путь к каталогу плагиновПо умолчанию:
Имя Cookie для SSL авторизацииПо умолчанию:
Секретный ключМожет быть:
Секретный ключМожет быть:
Путь к сайтуПо умолчанию:
Имя Cookie для тестового cookieПо умолчанию:
Имя Cookie для пользователейПо умолчанию:

2) Цикл на основе WP_Query()

Для вывода записей никак не связанных со страницей или создания множественных (дополнительных) циклов можно использовать циклы на основе класса WP_Query. Выглядят они аналогично циклам с использование . Для  используются те же самые параметры, что и для query_posts().

Интересно, что WP_Query является ядром функций и , т.е. обе эти функции работают на основе этого класса.

Пример цикла: выведем все записи из категории 9:

<?php // указываем категорию 9 и выключаем разбиение на страницы (пагинацию)
$query = new WP_Query( 'cat=9&nopaging=1' ); 
if( $query->have_posts() ){
	while( $query->have_posts() ){
		$query->the_post();
		?>
		

<?php the_title(); ?>

<?php the_content(); ?><?php }
wp_reset_postdata(); // сбрасываем переменную $post
}
else
echo ‘Записей нет.’;
?>

Пример создания множественных циклов на основе :

<?php // Цикл 1
$query1 = new WP_Query('cat=-1&nopaging=1'); // все посты, кроме категории 1
while( $query1->have_posts() ){
	$query1->the_post();

	// вывод записей
}
wp_reset_postdata();

// Цикл 2
$query2 = new WP_Query('cat=-2&nopaging=1'); // все посты, кроме категории 2
while( $query2->have_posts() ){
	$query2->the_post();

	// вывод записей
}
wp_reset_postdata();

// Цикл 3
$query3 = new WP_Query('cat=-3&nopaging=1'); // все посты, кроме категории 3
while( $query3->have_posts() ){
	$query3->the_post();

	// вывод записей
}
wp_reset_postdata();
?>

Особенность циклов на WP_Query() в том, что мы создаем новый объект , который никак не связан с аналогичным глобальным объектом $wp_query и поэтому мы никак не нарушаем структуру текущей страницы.

Также, мы можем использовать новый объект в других целях, не только для вывода записей, но и для различного рода проверок: например, записи какого типа страницы  используются в этом новом объекте; можем узнать общее количество записей удовлетворяющих запросу () и т.д. Такие данные могут пригодится при создании дополнительных запросов с пагинацией или где-то еще ().

Зачем нужно использовать ?

В глобальной переменной  хранятся данные текущего поста (если показывается страница поста, то данные этого поста). Когда срабатывает часть кода $query->the_post(), то в переменную $post записываются данные текущего поста в цикле и в конце цикла в этой переменной остаются данные последнего поста из этого цикла, а нужно чтобы $post всегда содержала данные текущего поста страницы. Т.е. получается до использования цикла $post->ID (ID текущего поста) было равно, допустим, 10, а после срабатывания цикла, та же самая переменная $post->ID уже равна, допустим, 56 (ID последнего поста из цикле), а нужно чтобы она по-прежнему равнялась 10.

wp_reset_postdata() используется как раз для того, чтобы вернуть правильные данные в переменную $post.

Когда использовать ?

Если нужно вывести записи не затрагивая основной цикл (допустим записи в боковой панели), если нужно создать множественные запросы. Вообще, я не вижу никаких преимуществ циклов на WP_Query() над циклами с использованием и поэтому рекомендую использовать вместо .

В HTML коде сайта и RSS

Исходники страницы позволяют узнать версию WP сразу несколькими способами. Для этого на сайте кликаете правой кнопкой мышки и в контекстном меню выбираете пункт «Исходный код страницы» (View Page Source).

1. Во-первых, система автоматически создает МЕТА тег generator:

2. Во-вторых, некоторые скрипты/стили в HTML могут отображать номер ветки (как в HEAD, так и внизу в футере). Скриншот ниже кликабельный:

3. Даже, если вы избавитесь от «палева» в плагинах/стилях в самом проекте, то узнать версию WordPress на чужом сайте можно через страницу логина, которая находится по адресу:

 http://ваш_сайт/wp-login.php

Здесь в коде (открывается через контекстное меню) найдете следующие строки:

Скрипты на картинке выше могут отличаться в зависимости от релиза системы. В новых они, по моему, объединены в один вызов, но суть не меняется.

http://адрес_вашего_сайта/feed/

И снова посмотрите исходники:

Данные о RSS канале будут показаны даже, когда у вас настроена переадресация на Feedburner. Если честно, самый неожиданный для меня вариант как узнать версию в Вордпресс. Не думал, что сторонний сервис будет показывать такую информацию.

Выбор движка таблиц в MariaDB

Конфигурация my.cnf в случае с MyISAM и Aria будет одинаковой, и не отличается от конфигурации, приведённой в первой статье. Однако, для Aria следует использовать директиву default-storage-engine=Aria.

Для XtraDB следует задать следующие директивы (привожу только то, что изменил по сравнению с конфигурацией в предыдущей статье):

В качестве критерия выбора я сначала хотел использовать время генерации страниц, однако все типы движков при простом запросе страницы показывали одни и те же результаты, поэтому было решено произвести стресс-тесты с нагрузкой в 100 пользователей. Мой тестовый аккаунт не позволял запускать стресс-тесты с количеством пользователей более 50, однако, как было выяснено опытным путём, было возможно запускать несколько тестов из разных вкладок браузера одновременно, чем я и воспользовался. Проверяем MyISAM. Пользователей: 100 (в другой вкладке чуть раньше запущен такой же тест):

Максимальное время ответа: 17.473 секунды.

Проверяем Aria. Пользователей: 100 (в другой вкладке чуть раньше запущен такой же тест):

Максимальное время ответа: 14.223 секунды. При этом более плавное изменение времени ответа.

Проверяем XtraDB. Пользователей: 100 (в другой вкладке чуть раньше запущен такой же тест):

Максимальное время ответа: 14.355 секунды.

Так как результаты на XtraDB и на Aria оказались почти одинаковыми, оставив при этом позади MyISAM, я решил пойти дальше и увеличивать число запросов, пока сайт на ляжет. На каком движке выдержит большую нагрузку — тот и выберу.

Снова тестируем Aria. Пользователей: 150 (в других двух вкладках чуть раньше запущены такие же тесты):

Упало на 148 пользователях. Время ответа: 19.311 секунды.

Тестируем XtraDB. Пользователей: 150 (в других двух вкладках чуть раньше запущены такие же тесты):

Упало на 150 пользователях. Время ответа: 20.963 секунды. В целом, результаты на Aria и XtraDB почти одинаковые. Но я решил выбрать XtraDB, потому что в дальнейшем хочу реализовать запрос данных для страниц со статьями с помощью NoSQL-решения HandlerSocket, работающее только с InnoDB/XtraDB. В данный момент существует расширение, компилируемое для PHP (php-handlersocket) и библиотека, написанная на PHP (HSPHP). Расширение я успел попробовать совместно с PHP5.6. С его помощью я сделал выборку из БД по PRIMARY KEY примерно в 2.5 раза быстрее, чем с помощью SQL-запроса. Но под PHP7 оно компилироваться отказывается (а следующим шагом у нас будет именно переход на новую версию). Что касается библиотеки HSPHP — замерив время получения выборки с её помощью и с помощью SQL-запроса (с учётом времени на подключение библиотеки), я выяснил, что при одиночном запросе в БД прироста она не даёт. Поэтому от её использования я отказался и теперь жду версии расширения, совместимой с PHP7.

6 ответов

9

ВАЖНОЕ ИЗМЕНЕНИЕ

Это неосознанно привлекло мое внимание, так как это сошло с ума, PHP 5.4 уже достиг EOL, и последняя поддержка безопасности была остановлена ​​14 сентября 2015 года. Согласно официальной документации , PHP 5.5 наконец достигнет своего EOL 10 июля 2016 года ( Активная поддержка уже остановлена, но эта версия будет получать обновления безопасности до окончательной даты EOl от 10 июля 2016 года

Согласно официальной документации , PHP 5.5 наконец достигнет своего EOL 10 июля 2016 года ( Активная поддержка уже остановлена, но эта версия будет получать обновления безопасности до окончательной даты EOl от 10 июля 2016 года.

Итак, чтобы вернуться к исходному вопросу, вы должны работать минимум минимум на PHP 5.5, но обязательно приготовьтесь перейти на PHP 5.6 в течение следующих 8 месяцев с даты этого ответа.

ОРИГИНАЛЬНЫЙ ОТВЕТ

WordPress все еще застрял на версиях PHP для динозавров, поэтому любая версия PHP, более новая или равная 5.3, должна делать.

Однако очень важно отметить, что версии all PHP до версии 5.4 были EOL’ed, последняя версия была 5,3 год назад. Короче говоря, это означает, что любая версия PHP старше 5.4 больше не поддерживается или не обновляется, что приведет к огромным проблемам безопасности, если вы все еще используете ее

Итак, для безопасности, минимальным минимумом, который вы должны безопасно запускать, является PHP 5.4.x, где должна быть последняя безопасность выпуск.

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

4

Для запуска WordPress мы рекомендуем поддерживать ваш хост:

PHP версии 5.6 или выше

MySQL версии 5.5 или выше

Примечание. Если вы находитесь в устаревшей среде, где у вас есть только старые версии PHP или MySQL, WordPress также работает с PHP 5.2.4+ и MySQL 5.0+, но эти версии достигли официального конца жизни и, как таковой, могут вашего сайта для уязвимостей безопасности.

Подробнее см. ссылку на код:

3

Все ответы здесь не учитывают актуальную, функционирующую среду WordPress, но используют аргументы о конце жизни /поддержке (то есть возрасте). Какая разница? То, что действительно нужно, — это стабильность и функциональность. Поэтому следует использовать последнюю версию, которая поддерживает всю систему WordPress (с нужными темами и плагинами). Последнее, потому что PHP, как правило, имеет скорость (и стабильность) улучшений в более новых версиях, но не «последние», потому что стабильность может пострадать.

Наконец, версии PHP могут иметь необходимую или желаемую функциональность, такую ​​как OpCache или php-fpm /mpm-event. В этих случаях будут выполняться 5.5 и 5.6.

Для этого нет (и не должен) быть ответом с любой конкретной версией. Появляются новые версии, старые версии прекращаются.

  • В minimum вы должны использовать поддерживаемую версию PHP. Это гарантирует, что он по-прежнему получает исправления ошибок и (или для менее поздней версии) обновлений безопасности.

  • Предпочтительно вы должны использовать версию last stable PHP. Это обеспечивает максимальную производительность.

WordPress теперь рекомендует использовать PHP 7 или выше — см. https://wordpress.org/about/requirements/

Минимальная поддерживаемая версия PHP на сегодняшний день — это 5.2.4.

Я бы использовал последнюю версию PHP, которая 7.1.

Не используйте хардкодинг

Очень часто нам кажется, что проще вставить значение в код напрямую (например, ссылку), но в итоге время, затраченное на отладку и устранение проблем, которые возникают в результате таких действий, сильно возрастает. Лучше всего использовать функцию для генерации нужного нам результата динамически, что принесет меньше проблем в будущем.

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

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

Использование пробелов

Всегда ставьте пробелы после запятых и по обе стороны логических операторов, сравнений, строк и операторов присваивания.

x == 23
foo && bar
! foo
array( 1, 2, 3 )
$baz . '-5'
$term .= 'X'

Ставьте пробелы по обе стороны открывающих и закрывающих скобок блоков if, elseif, foreach, for, switch.

foreach ( $foo as $bar ) { ...

Определение функции:

function my_function( $param1 = 'foo', $param2 = 'bar' ) { ...

Вызов функции:

my_function( $param1, func_param( $param2 ) );

Выполнение логических сравнений:

if ( ! $foo ) { ...
foreach ( (array) $foo as $bar ) { ...
 
$foo = (boolean) $bar;

При обращении к элементам массива ставьте пробелы вокруг индекса только если он является переменной, например:

$x = $foo; // правильно
$x = $foo; // неправильно
 
$x = $foo; // правильно
$x = $foo; // неправильно
 
$x = $foo; // правильно
$x = $foo; // неправильно

Определяем версию WordPress через PHP

Если вам нужно по каким-то причинам использовать номер релиза в PHP коде шаблона (functions) или плагина, то существует 2 подходящих метода.

Во-певрых, как я сказал выше, имеется специальная глобальная переменная, которая содержит требуемое нам значение и позволяет просто посмотреть версию WordPress проекта. Это — $wp_version. То есть при вызове она отдает номер сборки.

<?php echo($wp_version); ?>

Также значение считывается через функцию get_bloginfo:

<?php echo(get_bloginfo('version')); ?>

Результаты обоих примеров будут одинаковые.

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

Важно просто регулярно обновляться до последней версии Вордпресс и всегда следить за актуальностью установленного релиза

Если знаете еще способы как узнать версию WordPress сайта, пишите в комментах, добавлю их в пост.

Решение

Вы можете скачать любые версии PHP, которые вам нужны, и поместить их в свои собственные каталоги, например,

Все, что вам нужно сделать, это сообщить вашему веб-серверу (Apache), какую версию PHP использовать, что вы делаете, загружая соответствующий модуль. В Apache вы можете сделать это, найдя файл и затем редактируем соответствующую строку:

Конечно, вам нужно будет найти правильные пути — это только для иллюстрации.

Сохранить и перезапустите свой сервер

Обратите внимание, что если вы не перезапустите его, изменения не вступят в силу

Там нет переключателя GUI, чтобы быть в состоянии сделать это, вам нужно отредактировать файл, а затем перезапустите Apache. Выполнение этого занимает всего пару секунд, и вы даже можете закомментировать версию, так что для «переключения» требуется всего пара нажатий клавиш, например,

Используйте PHP 5:

Используйте PHP 7:

Вам не нужно несколько версий XAMPP, или для двойной загрузки, или для использования другой машины, или любого другого «решения», предложившего запутанные обходные пути. ОП хочет использовать XAMPP и сообщить ему, какую версию PHP использовать. Это самый быстрый и эффективный способ сделать это, и он требует только одной установки XAMPP.

Изменить 1 ноября 2017 года: Видимо, некоторые люди говорят, что нет файлы на винде. Ответ, который я дал, был адаптирован из того, как я настроил вещи на моем Mac (который использует файлы вместо ). Принцип ответа, однако, все еще точно верен. Вы используете конфигурационный файл Apache, указать где модуль PHP ( или же ) находится в вашей системе. Таким образом, единственной разницей для Windows будет имя файла и / или путь к нему. Ответ, который я дал, также верен для ванильной установки Apache / PHP (без XAMPP вообще).

71

Пример работы PHP в теме WordPress

Давайте немного углубим понимание с помощью небольшого примера, соединяющего в себе серверную природу PHP и ваш сайт WordPress. Если вернетесь к той картинке с темой «Twenty Seventeen»:Вы увидите, что “sidebar.php”, “header.php”, “comments.php” и т.д. представлены в отдельных PHP файлах.

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

Например:

  • sidebar.php определяет как выглядит и функционирует область боковой панели
  • header.php определяет как выглядит и функционирует заголовочная часть
  • comments.php определяет как выглядит и функционирует раздел комментариев и т. д.

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

Где PHP используется в WordPress?

Если вы скачаете последнюю версию WordPress с WordPress.org, вы можете открыть ZIP архив и убедиться в том, что большая часть основных файлов WordPress представляю собой PHP файлы.Точно также, любая, установленная вами тема, будет включать в себя кучу PHP файлов (скриншот ниже демонстрирует стандартную тему «Twenty Seventeen»):

Тема Twenty Seventeen

И как вы уже догадались, любые установленные вами плагины также будут включать в себя в основном PHP.

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

Например, одна из самых известных функций -the_content();. Хотя этот фрагмент кода выглядит достаточно невинно, фактически – это то, что использует ваша тема для отображения содержимого всех до единого, постов вашего блога. Да-да, вот этот крошечный фрагмент кода, после обработки веб-сервером кода PHP, может превратиться в пост из 10000 слов.

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

Обновление php на сервере для wordpress

Все популярные cms-системы, в том числе и wordpress, часто обновляются и имеют последнюю версию языка программирования и частенько новый функционал. Связано это прежде всего с безопасностью и с обновлениями программного кода.

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

А вот настроить совместимость версий php хостинга и например wordpress, это уже дело администратора сайта. Собственно ради этого и написана данная статья.

Любой администратор знает что обновление php на сервере делается из контрольной панели хостинга двумя кликами мыши. Выбрал необходимую версию php и нажал кнопку «сохранить».

Ну а дальше наблюдаем недоступность своего проекта.

В большинстве случаев это происходит по причине несовместимости установленных расширений с последними версиями php

Поэтому важно следить за обновлениями и стараться не устанавливать расширения, которые давно не обновлялись разработчиком

Совсем не важно знать структура wordpress или другого движка, а достаточно понимать что все изменения происходят именно по этой причине. А раз так, то нужно все это дело проверить

Но расширений может быть не один десяток (плагины для wordpress) и проверить такое количество на совместимость, просто не реально!

А раз так, то нужно все это дело проверить. Но расширений может быть не один десяток (плагины для wordpress) и проверить такое количество на совместимость, просто не реально!

Как быть?

Ссылка на основную публикацию