Aggancio / azione del plugin di aggiornamento di Wordpress? Dal 3.9

L'ho cercato un paio di volte, ma la mia ricerca non rivela molto, tranne il codice personalizzato che può o meno essere una buona pratica di WordPress.

A partire dalle ultime versioni (WordPress 3.9 "Smith"), è stato aggiunto un hook al processo di aggiornamento del plugin? Lo sto chiedendo perché è un'esigenza fondamentale, eppure non lo vedo aggiunto al codice (ancora). In caso contrario, quali sono gli sviluppatori comuni e delle best practice impiegati?

EDIT: Solo per chiarire, non sto parlando di attivazione, ma di aggiornamento, in questo modo, se ci sono cambiamenti nel database o altrimenti può essere risolto.

Non penso che sia stata aggiunta un'azione. Puoi vedere i dettagli della versione per qualsiasi versione e vedere eventuali nuove azioni aggiunte.

Il modo WordPress per eseguire il codice sull'aggiornamento del plug-in è ciò che è descritto qui :

Il modo corretto di gestire un percorso di aggiornamento consiste nell'eseguire una procedura di aggiornamento solo quando è necessario. Idealmente, dovresti archiviare una "versione" nell'opzione del database del tuo plug-in, quindi una versione nel codice. Se non corrispondono, è necessario attivare la procedura di aggiornamento e quindi impostare l'opzione del database in modo che sia uguale alla versione nel codice. Questo è il numero di plug-in che gestiscono gli aggiornamenti e anche il core funziona.

e con un esempio di codice qui :

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' );

Dalla discussione in cui hanno deciso di non aggiungere un hook / una funzione specifici specifici per l'aggiornamento , sembra che la maggior parte delle persone (già 4 anni fa) usino register_activation_hook, poiché viene chiamata quando un plug-in viene aggiornato attraverso la pagina di amministrazione; la maggior parte degli esempi che ho visto da allora seguono questa tendenza.

Per la maggior parte dell'utilizzo suggerirei di non collegarmi plugins_loaded, poiché verrebbe chiamato ad ogni caricamento della pagina. L'eccezione è menzionata nella discussione: i percorsi di aggiornamento tramite FTP / SVN sono "casi limite", poiché WP non avrebbe un meccanismo per sapere che il plugin è stato modificato, nel qual caso la risposta precedente potrebbe essere più pertinente.

Vedere https://gist.github.com/zaus/c08288c68b7f487193d1 per un esempio di "framework semplice" che utilizza register_activation_hook.

Da WordPress 3.9 è possibile utilizzare upgrader_process_completehook.
Vedi riferimento 1 , 2

Ecco un esempio di codice:

<?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

Una volta aggiornato il plugin, imposterà l'attività in db usando la set_transient()funzione. Non è consigliabile aggiungere il codice di aggiornamento mentre si chiama upgrader_process_completehook.
Quindi, se si passa ad un'altra pagina di amministrazione, l' plugins_loadedhook funzionerà e il codice di aggiornamento funzionerà lì.

Nota che questo plugin deve essere attivato per far funzionare l'hook di aggiornamento.
Questo non funziona con l'attivazione del plug-in, quindi, se si desidera che il codice funzionante attivi il plug-in, è necessario codificarlo in register_activation_hook()funzione.