WordPress.org

Ready to get started?Download WordPress

Forums

[resolved] Automatic plugin update problem (10 posts)

  1. Jacob N. Breetvelt
    Member
    Posted 2 years ago #

    On automatic update of plugins, the activation hooks are not executed.

    This results in the fact that required updates of db tables are not performed and therefore the generation of run-time (sql) errors.

    The plugin developer (me) assumes de-activation before and re-activation after a plugin upgrade.

    A workaround is to have my own 'db revision level' and checking it in every admin page of the plugin and run the required routine then.

    Leaves us with errors when this has not been done yet.

    Is the ommission of running the (de)activation hooks a feature or a bug? To me its a bug.

  2. s_ha_dum
    Member
    Posted 2 years ago #

    To me its a bug.

    If this is the case, I agree.

    Honestly, I wish the auto-update feature wasn't there at all but if it is going to be it should follow a deactivate-update-reactivate pattern. Have you looked around the WordPress Trac?

  3. Jacob N. Breetvelt
    Member
    Posted 2 years ago #

    I made it a bug on Trac, but they wont fix it and suggest the workaround i do already. Thanx

  4. s_ha_dum
    Member
    Posted 2 years ago #

    Why won't they fix it? What is the reasoning? What is the trac ticket URL?

  5. http://core.trac.wordpress.org/ticket/17833

    This has been a design choice. In the past, the activation hooks ran but not the deactivation hooks (as too many plugins would remove data on deactivation).

    The suggested method is to utilise a 'plugin_version' option, and upgrade any options, and database tables when plugin_version != Hardcoded version in plugin file (And do it when is_Admin() or similar).

  6. Jacob N. Breetvelt
    Member
    Posted 2 years ago #

    This means that we can forget about the activation hook entirely.

    Is there an add_action() hook i can use and be sure all wp core is loaded?
    I need is_user_logged_in() and get_currentuserinfo() during this process.

    Simply adding a call to my init routine fails here.

  7. Jacob N. Breetvelt
    Member
    Posted 2 years ago #

    It looks like add_action('admin_init', 'my_setup_routine') works, altough it is executed twice, once at the top of the screen and once in the wp stats window on the dadhboard. But that does no harm.

    The structure of my_setup_routine is like:

    function my_setup_routine() {
    global $wpdb;
    
    $oldrev = get_option('my_rev', 100);
    if ($oldrev < '306') {
    $my_table = ...
    require_once(ABSPATH . 'wp-admin/includes/upgrade.php');
    
    dbDelta($my_table);
    $iret = fill_new_columns_with_data(); // uses get_currentuserinfo()
    make_my_directories_if_not_exist(); // uses get_currentuserinfo()
    set_my_default_options_if_they_are_new();
    if ($iret !== false) update_option('my_rev', '306');
    
    }
    }
  8. Jacob N. Breetvelt
    Member
    Posted 2 years ago #

    When updating manually, you read:

    Plugin de-activated
    
    Plugin updated
    
    Plugin successfully activated

    One thinks it is activated, (and hence will run the hook)

    The text could rather be:

    Plugin turned off
    
    .
    
    .
    
    Plugin turned back on
  9. You can suggest that verbage change in the trac ticket if you want.

  10. TechStudio
    Member
    Posted 2 years ago #

    I am also looking for something to hook to when plugins are automatically updated. There must be a definitive way to add an action when this event occurs.

Topic Closed

This topic has been closed to new replies.

About this Topic

Tags

No tags yet.