Статьи

Совет: Предотвращение несовместимости плагинов WordPress

Поскольку WordPress занимает более 25% веб-сайтов, разработчики должны иметь возможность подготовить свой плагин для максимальной совместимости. Согласно последним статистическим данным , WordPress может быть установлен на шесть различных версий PHP без гарантии того, что пользователь, работающий с сайтом, использует последнюю версию WordPress.

Есть еще люди, которые запускают WordPress версии 3.0 согласно статистике.

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

Несовместимости плагинов WordPress

Обнаружение несовместимости при активации плагина

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

Некоторые другие преимущества включают в себя:

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

Основная концепция

Чтобы сделать это правильно, есть несколько вещей, которые необходимо сделать:

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

Давайте работать наш код на основе установленного потока выше.

Проверка выполнения требований

Сначала мы создадим функцию, которая будет проверять среду на соответствие нашим требованиям, которая будет возвращать либо true либо false В этой функции мы можем свободно проверять все, что мы хотим, будь то версия WordPress, версия PHP или что-либо еще, что необходимо для обеспечения бесперебойной работы нашего плагина. Давайте начнем с простых требований, которым нужен как минимум WordPress 4.0, а также PHP 5.3. Чтобы добавить немного сложности, нам также потребуется активировать расширение ftp PHP.

 function prefix_is_requirements_met() { $min_wp = '4.0'; $min_php = '5.3'; $exts = array('ftp'); // Check for WordPress version if ( version_compare( get_bloginfo('version'), $min_wp, '<' ) ) { return false; } // Check the PHP version if ( version_compare( PHP_VERSION, $min_php, '<' ) ) { return false; } // Check PHP loaded extensions foreach ( $exts as $ext ) { if ( ! extension_loaded( $ext ) ) { return false; } } return true; } 

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

Отключите плагин и покажите уведомление об ошибке активации

Затем мы можем запустить эту функцию в главном файле нашего плагина, и если требования не будут выполнены, мы добавим две функции обратного вызова, к каждому из admin_init и admin_notices соответственно.

 if ( ! prefix_is_requirements_met() ) { add_action( 'admin_init', 'prefix_disable_plugin' ); add_action( 'admin_notices', 'prefix_show_notice' ); } 

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

 function prefix_disable_plugin() { if ( current_user_can('activate_plugins') && is_plugin_active( plugin_basename( __FILE__ ) ) ) { deactivate_plugins( plugin_basename( __FILE__ ) ); // Hide the default "Plugin activated" notice if ( isset( $_GET['activate'] ) ) { unset( $_GET['activate'] ); } } } 

Прежде чем мы сможем безопасно вызвать функцию deactivate_plugins , мы проверяем разрешение текущего вошедшего в систему пользователя, а также проверяем, активен ли плагин. Это сделано для того, чтобы справиться с некоторыми крайними случаями, когда плагин мог уже быть активным ранее по какой-либо причине, например, во время обновления плагина. Обратите внимание, что мы дополнительно сбрасываем переменную $_GET['activate'] , в противном случае уведомление «Плагин активирован» все равно будет отображаться, даже если плагин не активирован. Это должно предотвратить путаницу для конечных пользователей.

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

 function prefix_show_notice() { echo '<div class="error"><p><strong>Plugin Name</strong> cannot be activated due to incompatible environment.</p></div>'; } 

Условная загрузка оставшейся части кода плагина

Для этого просто else оператор else в наш предыдущий блок кода, где мы выполняем проверку. Таким образом, окончательная версия кода будет:

 if ( ! prefix_is_requirements_met() ) { add_action( 'admin_init', 'prefix_disable_plugin' ); add_action( 'admin_notices', 'prefix_show_notice' ); } else { // The rest of plugin's code } 

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

Вывод

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