J'ai fait quelques recherches à ce sujet, mais ma recherche ne révèle pas grand-chose, à l'exception d'un code personnalisé qui peut ne pas être une bonne pratique de WordPress.
Depuis les dernières versions (WordPress 3.9 "Smith"), un hook a-t-il été ajouté au processus de mise à jour du plugin? Je demande parce que c’est un besoin fondamental, mais je ne le vois pas ajouté au codex (pour le moment). Si non, quelles sont les pratiques courantes et les meilleures pratiques utilisées par les développeurs?
EDIT: Juste pour clarifier, je ne parle pas d'activation, mais de mise à jour, de cette façon, s'il y a des changements dans la base de données ou autrement, cela peut être résolu.
Je ne pense pas qu'une action a été ajoutée. Vous pouvez consulter les détails de la version pour n’importe quelle version et voir les nouvelles actions ajoutées.
Le WordPress Way pour exécuter le code sur la mise à jour du plugin est ce qui est décrit ici :
La bonne façon de gérer un chemin de mise à niveau consiste à exécuter une procédure de mise à niveau uniquement lorsque vous en avez besoin. Idéalement, vous stockeriez une "version" dans l’option de base de données de votre plugin, puis une version dans le code. S'ils ne correspondent pas, lancez votre procédure de mise à niveau, puis définissez l'option de base de données sur la version du code. C’est ainsi que de nombreux plugins gèrent les mises à niveau, et c’est ainsi que fonctionne le cœur.
et avec exemple de code ici :
function myplugin_update_db_check() {
global $jal_db_version;
if (get_site_option( 'jal_db_version' ) != $jal_db_version) {
jal_install();
}
}
add_action( 'plugins_loaded', 'myplugin_update_db_check' );
Depuis WordPress 3.9, vous pouvez utiliser upgrader_process_complete
hook.
Voir référence 1 , 2
Voici un exemple de code:
<?php
/**
* Plugin Name: Test plugin 1
* Plugin URI: http://rundiz.com
* Description: A very simple plugin for testing. This plugin do nothing.
* Version: 0.1.8
* Author: Vee Winch
* Author URI: http://rundiz.com
* License: MIT
* License URI: https://opensource.org/licenses/MIT
* Text Domain: test-plugin1
* Domain Path:
*/
$wppstp1_version = '0.1.8';
add_action('upgrader_process_complete', 'wppstp1_upgrade', 10, 2);// will working only this plugin activated.
function wppstp1_upgrade(\WP_Upgrader $upgrader_object, $hook_extra)
{
global $wppstp1_version;
if (is_array($hook_extra) && array_key_exists('action', $hook_extra) && array_key_exists('type', $hook_extra) && array_key_exists('plugins', $hook_extra)) {
// check first that array contain required keys to prevent undefined index error.
if ($hook_extra['action'] == 'update' && $hook_extra['type'] == 'plugin' && is_array($hook_extra['plugins']) && !empty($hook_extra['plugins'])) {
// if this action is update plugin.
$this_plugin = plugin_basename(__FILE__);
foreach ($hook_extra['plugins'] as $each_plugin) {
if ($each_plugin == $this_plugin) {
// if this plugin is in the updated plugins.
// don't process anything from new version of code here, because it will work on old version of the plugin.
file_put_contents(WP_CONTENT_DIR . '/test.txt', 'v'.$wppstp1_version."\r\n", FILE_APPEND); // you will always get the previous version even you update to the new version.
// set transient to let it run later.
set_transient('wppstp1_updated', 1);
}
}// endforeach;
unset($each_plugin);
}// endif update plugin and plugins not empty.
}// endif; $hook_extra
}// wppstp1_upgrade
add_action('plugins_loaded', 'wppstp1_runUpdatedPlugin');
function wppstp1_runUpdatedPlugin()
{
global $wppstp1_version;
if (get_transient('wppstp1_updated') && current_user_can('manage_options')) {
// if plugin updated and current user is admin.
file_put_contents(WP_CONTENT_DIR . '/test-update-by-transient.txt', 'v'.$wppstp1_version."\r\n", FILE_APPEND);// you will always get the updated version here.
// update code here.
// delete transient.
delete_transient('wppstp1_updated');
}
}// wppstp1_runUpdatedPlugin
Une fois le plugin mis à jour, la tâche sera définie en base de données à l'aide de la fonction set_transient()
. Il n'est pas recommandé d'ajouter du code de mise à jour lors de l'appel de upgrader_process_complete
hook.
Ensuite, si vous naviguez vers une autre page d’administration, le hook plugins_loaded
fonctionnera et le code de mise à jour y travaillera.
Veuillez noter que ce plugin doit être activé pour que le hook de mise à jour fonctionne.
Cela ne fonctionne pas sur activer le plugin, donc si vous voulez que le code qui fonctionne active le plugin, vous devez le coder dans la fonction register_activation_hook()
.
Dans la discussion où ils ont décidé de ne pas ajouter de fonction/crochet spécifique à la mise à niveau , cela ressemble à "la plupart des gens" (il y a 4 ans) utilisaient register_activation_hook
, puisqu'il est appelé lorsqu'un plugin est mis à niveau via l'administrateur. page; la plupart des exemples que j'ai vus depuis lors suivent cette tendance.
Pour la plupart des utilisations, je suggérerais de ne pas utiliser le plugins_loaded
, car il serait appelé à chaque chargement de page. L'exception à cela est mentionnée dans la discussion: les chemins de mise à niveau via FTP/SVN sont des "cas Edge", puisque WP n'aurait pas de mécanisme permettant de savoir que le plug-in a été modifié, auquel cas le réponse précédente pourrait être plus pertinent.
Voir https://Gist.github.com/zaus/c08288c68b7f487193d1 pour un exemple de "cadre simple" utilisant register_activation_hook
.