Force the custom rollback/beta version updater to appear all the time about git-updater

[lifedispenser]

Some untested code for class-theme-updater.php.

private function append_theme_actions_content( $theme ){

        $details_url            = self_admin_url( "theme-install.php?tab=theme-information&theme=$theme->repo&TB_iframe=true&width=270&height=400" );                
        $theme_update_transient = get_site_transient( 'update_themes' );

        //if the theme is outdated, display the custom theme updater content
        //if theme is not present in theme_update transient response ( theme is not up to date )
        ob_start();
        if ( empty( $theme_update_transient->up_to_date[$theme->repo] ) ) {
            $update_url = wp_nonce_url( self_admin_url( 'update.php?action=upgrade-theme&theme=' ) . urlencode( $theme->repo ), 'upgrade-theme_' . $theme->repo );
            ?>
            <strong>There is a new version of <?php echo $theme->name; ?> available now. <a href="<?php echo $details_url; ?>" class="thickbox" title="<?php echo $theme->name; ?>">View version <?php echo $theme->remote_version; ?> details</a> or <a href="<?php echo $update_url; ?>">update now</a>.</strong>
            <?php
        } 
        //display the custom rollback/beta version updater all the time 
            $rollback_url = sprintf( '%s%s', wp_nonce_url( self_admin_url( 'update.php?action=upgrade-theme&theme=' ) . urlencode( $theme->repo ), 'upgrade-theme_' . $theme->repo ), '&rollback=' );
            ?>
            <p>Try <a href="#" onclick="jQuery('#ghu_versions').toggle();return false;">another version?</a></p>
            <div id="ghu_versions" style="display:none; width: 100%;">
                <select style="width: 60%;" 
                    onchange="if(jQuery(this).val() != '') {
                        jQuery(this).next().show(); 
                        jQuery(this).next().attr('href','<?php echo $rollback_url ?>'+jQuery(this).val()); 
                    }
                    else jQuery(this).next().hide();
                ">
                <option value="">Choose a Version...</option>
                <option><?php echo $theme->branch; ?></option>
                <?php foreach ( $theme_update_transient->up_to_date[$theme->repo]['rollback'] as $version => $url ){echo'<option>'.$version.'</option>';}?></select>
                <a style="display: none;" class="button-primary" href="?">Install</a>
            </div>
            <?php
            return trim( ob_get_clean(), '1' );
    }

[afragen]

Firstly you must remember rollback is only for themes, not plugins.

I'm not sure I like the aesthetic of seeing the rollback all the time. In the instance you show, if you have an update pending and still want to rollback to a previous version, you could just do the update and then do a rollback right after. There's no time delay.

@scarstens what do you think?

At this time I'm not convinced of the need as this can be accomplished already, just with an extra click or two.

[scarstens]

Indeed. The purpose of the rollback function is to enable you to "update without worry" since you can always go back to the previous version if it doesn't work. Thus, its an end user function more then a developer function. While we do enable the updates to development versions (for developers) the goal is not to serve developers as a way to move around.

One would hope if you are using GIT to bounce between versions, that GIT already allows you to move your local code between tags. Develop locally and as you move between tags you will automatically update your site with the version you desire. Since this is already the development model built around GIT I don't see any reason to rebuilt it into the web GUI.

Its not to say your use case isn't viable, but the workaround of clicking update before you rollback should not prohibit you from moving between versions should you decide not to use GIT the way it was intended to be used on local development.

@afragen I do believe the rollback functionality for plugins should be enabled, since a plugin could break a site and need to be rolled back as well. Any idea where we should start to accomplish this? I'll be happy to find a way to build the UI in the admin area if you will provide a means of pulling the rollback on the server side.

[scarstens]

That being said, you could develop your own plugin to extend the updater that you would use and install on development sites only. Should you decide to do that, and run into any issues please let me know and I'll do what I can to assist you in your extension.

[afragen]

@scarstens perhaps a new issue re: plugin rollback to get a sense of what others think.

[lifedispenser]

Not a problem guys, thanks for your efforts. I am using it for development purposes (and not for scheduled, bug tested roll outs). I came across a bug that you would click 'update' because there was a new version, and it would go to do update but then would say the theme is already up-to-date. I assumed it was because of the limited number of times you could poll github for changes, and just wanted a 'force pull' button, which is what the rollback also conveniently provides.

If the use case is particular to me, I'll just modify my own code and use it in that way. Thanks again, it's been super helpful.