Wordpress Update Plugin Hook / Action? Od 3,9

15

Badałem to kilka razy, ale moje wyszukiwanie nie ujawnia wiele poza niestandardowym kodem, który może, ale nie musi, być dobrą praktyką WordPress.

Czy w najnowszych wydaniach (WordPress 3.9 „Smith”) dodano hak do procesu aktualizacji wtyczki? Pytam, ponieważ jest to bardzo podstawowa potrzeba, ale nie widzę, aby była dodana do kodeksu (jeszcze). Jeśli nie, jakie są najczęstsze i najlepsze praktyki deweloperów?

EDYCJA: Aby wyjaśnić, nie mówię o aktywacji, ale o aktualizacji w ten sposób, jeśli są zmiany w bazie danych lub w inny sposób można je rozwiązać.

użytkownik1915665
źródło
Odpowiedź @drzaus pod warunkiem, że nie ma dobrej praktyki.
Rens Tillmann
@RensTillmann poza tym, że i tak jest o 2 lata nieaktualny, powiązane kw / d ma zasadniczo tę samą odpowiedź, ale poprzedza to pytanie o kolejne 2 lata, stąd „duplikat”.
drzaus

Odpowiedzi:

16

Nie sądzę, że dodano akcję. Możesz sprawdzić szczegóły każdej wersji i zobaczyć wszelkie dodane nowe działania.

Sposób WordPressa do uruchamiania kodu przy aktualizacji wtyczek został opisany tutaj :

Właściwym sposobem obsługi ścieżki aktualizacji jest uruchomienie procedury aktualizacji tylko wtedy, gdy jest to konieczne. Idealnie byłoby zapisać „wersję” w opcji bazy danych wtyczki, a następnie wersję w kodzie. Jeśli się nie zgadzają, uruchom procedurę aktualizacji, a następnie ustaw opcję bazy danych na równą wersji w kodzie. Tak wiele wtyczek obsługuje uaktualnienia i tak działa również rdzeń.

i przykładowy kod tutaj :

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
źródło
Dziękuję - wtedy po prostu użyję tej metody. WP naprawdę musi dodać do tego akcję: D
user1915665
8
technicznie rzecz biorąc, powinieneś używać register_activation_hook, ponieważ w większości przypadków wtyczka jest dezaktywowana / aktywowana za każdym razem, gdy aktualizujesz ją od administratora. Podłączenie do plugins_loadedspowoduje sprawdzenie przy każdym ładowaniu strony (w tym nakładki). Mówiono o wprowadzeniu register_update_hook, ale jakiś czas temu oznaczono go jako WONTFIX . Dyskusja tam jest pomocna.
drzaus
4
Ważne jest, aby zrozumieć, że aktualizacja wtyczki masowej NIE uruchamia haków aktywacyjnych - POWINNA, ale nie w wersji 3.9.2. Przez „masową aktualizację” rozumiem aktualizację wykonaną ze strony aktualizacji deski rozdzielczej. Poszczególne aktualizacje wykonane ze strony wtyczki działają dobrze.
Brian C
4
Chodzi o to, że wtyczki można również aktualizować przez FTP, co oznacza, że ​​haczyk w żadnym wypadku nie zostanie uruchomiony. Dlatego musisz skorzystać z opcji zapisanej w bazie danych.
giraff
4
Aby rozwinąć komentarz @ giraff, to samo dotyczy osób, które zarządzają kodem za pomocą kontroli źródła, takiej jak SVN lub Git. Z tego powodu ta odpowiedź jest najlepszym sposobem na obsługę aktualizacji.
doublesharp
3

Z dyskusji, w której postanowili nie dodawać niestandardowego zaczepu / funkcji specyficznej dla aktualizacji , brzmi to jak użycie „większości ludzi” (sprzed 4 lat) register_activation_hook, ponieważ jest wywoływane, gdy wtyczka jest aktualizowana przez stronę administratora; większość przykładów, które widziałem od tego czasu, podąża za tym trendem.

W przypadku większości zastosowań sugerowałbym, aby nie przechwytywać plugins_loaded, ponieważ byłby wywoływany przy każdym ładowaniu strony. Wyjątek od tego jest wspomniany w dyskusji: ścieżki uaktualnienia przez FTP / SVN to „przypadki brzegowe”, ponieważ WP nie miałoby mechanizmu, aby wiedzieć, że wtyczka została zmieniona, w którym to przypadku poprzednia odpowiedź może być bardziej trafna.

Zobacz https://gist.github.com/zaus/c08288c68b7f487193d1, aby zobaczyć przykład „prostej struktury” register_activation_hook.

drzaus
źródło
register_activation_hooknie gwarantuje się, że będzie uruchamiany przy aktualizacjach, patrz make.wordpress.org/core/2010/10/27/…
Flimm,
Bardzo - nie używaj plugins_loaded- uruchamia się przy każdym obciążeniu i może być uciążliwe / wolne.
random_user_name
3

Od WordPress 3.9 możesz używać upgrader_process_completehaka.
Patrz odniesienie 1 , 2

Oto przykładowy kod:

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

Po aktualizacji wtyczki ustawisz zadanie w db za pomocą set_transient()funkcji. Nie zaleca się dodawania kodu aktualizacji podczas wywoływania upgrader_process_completehooka.
Następnie, jeśli plugins_loadedprzejdziesz do innej strony administratora, hak będzie działał i będzie tam działał kod aktualizacji.

Pamiętaj, że ta wtyczka musi zostać aktywowana, aby hak aktualizacji działał.
To nie działa na aktywację wtyczki, więc jeśli chcesz kodu, który działa na aktywacji wtyczki, musisz ją zakodować w register_activation_hook()funkcji.

vee
źródło