Wordpress Update Plugin Hook / Acción? Desde 3.9

15

He investigado esto varias veces, pero mi búsqueda no revela mucho, excepto el código personalizado que puede o no ser una buena práctica de WordPress.

A partir de las últimas versiones (WordPress 3.9 "Smith"), ¿ se ha agregado un gancho al proceso de actualización del complemento? Lo pregunto porque es una necesidad muy básica, pero aún no lo veo agregado al códice (todavía). Si no es así, ¿qué emplean los desarrolladores comunes y las mejores prácticas?

EDITAR: Solo para aclarar, no estoy hablando de activación, sino de actualización, de esa manera, si hay cambios en la base de datos o de lo contrario se puede abordar.

usuario1915665
fuente
Respuesta de @drzaus siempre que no haya una buena práctica.
Rens Tillmann
@RensTillmann además de que esto está 2 años desactualizado de todos modos, el q / a vinculado tiene básicamente la misma respuesta, pero es anterior a esta pregunta por otros 2 años, de ahí el 'duplicado'.
drzaus

Respuestas:

15

No creo que se haya agregado una acción. Puede ver los detalles de la versión para cualquier versión y ver las nuevas acciones agregadas.

La forma en que WordPress ejecuta el código en la actualización del complemento es lo que se describe aquí :

La forma correcta de manejar una ruta de actualización es ejecutar solo un procedimiento de actualización cuando sea necesario. Idealmente, debería almacenar una "versión" en la opción de base de datos de su complemento, y luego una versión en el código. Si no coinciden, debe iniciar su procedimiento de actualización y luego configurar la opción de base de datos para igualar la versión en el código. Así es como muchos complementos manejan las actualizaciones, y así es como funciona el núcleo también.

y con el ejemplo de código aquí :

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' );
Milo
fuente
Gracias, simplemente usaré ese método entonces. WP realmente tiene que agregar una acción para esto: D
user1915665
8
técnicamente se supone que debes usar register_activation_hook, ya que en la mayoría de los casos un complemento se desactiva / activa cada vez que lo actualizas desde el administrador. Enganchar a plugins_loadedhará su verificación en cada carga de la página (incluida la interfaz). Se habló de presentar register_update_hook, pero fue marcado como WONTFIX hace un tiempo. La discusión allí es útil.
drzaus
44
Es importante comprender que una actualización masiva de complementos NO ejecuta ganchos de activación, DEBE, pero no lo hace en 3.9.2. Por "actualización masiva" me refiero a una actualización realizada desde la página de actualización del Tablero. Las actualizaciones individuales realizadas desde la página del complemento ejecutan los ganchos muy bien.
Brian C
44
La cuestión es que los complementos también se pueden actualizar a través de FTP, lo que significa que el gancho no se disparará en ningún caso. Es por eso que necesita recurrir a la opción almacenada en la base de datos.
giraff
44
Para ampliar el comentario de @ giraff, lo mismo es cierto para las personas que administran su código con control de fuente como SVN o Git. Por eso, esta respuesta es la mejor manera de manejar las actualizaciones.
doublesharp
3

De la discusión en la que decidieron no agregar un enlace / función personalizado específico para la actualización , parece que "la mayoría de la gente" (a partir de hace 4 años) usa register_activation_hook, ya que se llama cuando se actualiza un complemento a través de la página de administración; La mayoría de los ejemplos que he visto desde entonces siguen esa tendencia.

Para la mayoría de los usos, sugeriría que no se conecte plugins_loaded, ya que se llamaría en cada carga de página. La excepción a esto se menciona en la discusión: las rutas de actualización a través de FTP / SVN son 'casos extremos', ya que WP no tendría un mecanismo para saber que se modificó el complemento, en cuyo caso la respuesta anterior podría ser más relevante.

Ver https://gist.github.com/zaus/c08288c68b7f487193d1 para un ejemplo de 'marco simple' usando register_activation_hook.

drzaus
fuente
register_activation_hookno se garantiza que se ejecute en las actualizaciones, consulte make.wordpress.org/core/2010/10/27/…
Flimm
Mucho, NO lo use plugins_loaded, ejecuta cada carga y puede ser pesado / lento.
random_user_name
3

Desde WordPress 3.9 puedes usar upgrader_process_completehook.
Ver referencia 1 , 2

Aquí hay un código de ejemplo:

<?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 vez actualizado el complemento, configurará la tarea en db usando la set_transient()función. No se recomienda agregar un código de actualización al llamar a upgrader_process_completehook.
A continuación, si navega a otra página de administración, el plugins_loadedenlace funcionará y el código de actualización funcionará allí.

Tenga en cuenta que este complemento debe estar activado para que funcione el enlace de actualización.
Esto no funciona en el complemento de activación, por lo tanto, si desea que el código que funciona active el complemento, debe codificarlo en register_activation_hook()función.

vee
fuente