Wordpress Update Plugin Hook / Action? Depuis 3.9

J'ai fait des recherches à ce sujet plusieurs fois, mais ma recherche ne révèle pas grand-chose, sauf le code personnalisé qui peut ou non être une bonne pratique WordPress.

Depuis les dernières versions (WordPress 3.9 "Smith"), un crochet a-t-il été ajouté au processus de mise à jour du plugin? Je demande parce que c'est un besoin très basique, mais je ne le vois pas (encore) ajouté au codex. Sinon, quelle est la norme et les meilleures pratiques employé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 sinon cela peut être résolu.

Je ne pense pas qu'une action ait été ajoutée. Vous pouvez consulter les détails de la version pour n'importe quelle version et voir toutes les nouvelles actions ajoutées.

La manière WordPress d'exécuter du code lors de la mise à jour du plugin est décrite 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, vous déclencheriez votre procédure de mise à niveau, puis définir l'option de base de données pour égaler la version dans le code. C'est ainsi que de nombreux plugins gèrent les mises à niveau, et c'est ainsi que le core fonctionne également.

et avec l'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' );

D'après la discussion où ils ont décidé de ne pas ajouter de hook / fonction personnalisé spécifique à la mise à niveau , cela ressemble à "la plupart des gens" (il y a 4 ans) register_activation_hook, car il est appelé lorsqu'un plugin est mis à niveau via la page d'administration; la plupart des exemples que j'ai vus depuis lors suivent cette tendance.

Pour la plupart des utilisations, je suggère de ne pas accrocher 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 marginaux '', car WP n'aurait pas de mécanisme pour savoir que le plugin a été modifié, auquel cas la réponse précédente pourrait être plus pertinente.

Voir https://gist.github.com/zaus/c08288c68b7f487193d1 pour un exemple de «cadre simple» utilisant register_activation_hook.

Depuis WordPress 3.9, vous pouvez utiliser le upgrader_process_completehook.
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, il définira la tâche dans db en utilisant la set_transient()fonction. Il n'est pas recommandé d'ajouter du code de mise à jour lors de l'appel du upgrader_process_completehook.
Ensuite, si vous accédez à une autre page d'administration, le plugins_loadedhook fonctionnera et le code de mise à jour y fonctionnera.

Veuillez noter que ce plugin doit être activé pour que le crochet de mise à jour fonctionne.
Cela ne fonctionne pas sur l'activation du plugin, donc si vous voulez que le code qui fonctionne sur l'activation du plugin, vous devez le coder en register_activation_hook()fonction.