Add updating workflow #381

…method.

- `get_tgmpa_status_url()` -> url to the tgmpa page for a certain view - `tgmpa_complete()` -> do we have actions on the registered plugins or not ? - `is_plugin_installed()` - `is_plugin_active()` -> similar to WP native `is_plugin_active()` - `can_plugin_update()` -> check whether the minimum WP requirement for a plugin update has been met - `can_plugin_activate()` -> check whether a plugin complies with an optionally set minimum version of the plugin and is currently inactive - `get_installed_version()` -> get the version nr of an installed plugin - `does_plugin_require_update()` -> check whether a plugin complies with an optionally set minimum version of the plugin - `does_plugin_have_update()` -> check whether there are updates available for a plugin, required or otherwise - `get_upgrade_notice()` -> get the upgrade notice from the plugin readme if supplied by the plugin author - `get_plugins()` -> wrapper for WP native `get_plugins()`

Most significant changes: - added views: 'to install', 'update available', 'to activate' - simplified the `_gather_plugin_data()` method by abstracting parts of it to separate methods - reverted the change to the constructor arguments from PR #227 as that breaks things, instead overload the `get_table_classes()` method which archives the same effect as PR #227 intended - added 'version' column and a method to generate the output for it - made column to display dependent on the chosen view - abstracted the plugin row actions to a separate method - made the row actions always visible (was on hover), similar to the WP native plugins table - added upgrade notice information to a plugin row if available

Most significant changes: - Changed the class we are overloading from WP_Upgrader to Plugin_Upgrader - The `run()` method was a copy of the original from WP_Upgrader (not overloaded in Plugin_Upgrader) with some additional code for automatic activation. This activation code has now been abstracted to its own method which we hook into a filter within the `run()` method (yeah, I know, abusing a filter for an action, but makes for so much cleaner code). We still overload run but only to reset any potential fall-out from the filter abuse after the parent function has run. - The `bulk_install()` method is largely a copy of the `bulk_upgrade()` method with customizations to allow for new installs rather than upgrades. This method has been updated to be completely in line with the current (4.2.1) implementation in core with clear comments on where it differs for ease of future updating. - Removed the `plugin_info()` and `add_install_strings()` methods as those were copied from Plugin_Upgrader and as we're now extending that class, we don't need the copies anymore.

…ades. Most significant changes: - add install_type as part of the arguments passed so we know whether we are dealing with a bulk install or bulk update - Both the `before()` and `after()` methods were copies of the original with only the a different title. As we can set the title as an optional argument, there was no need to copy the code, so largely simplified the overloaded methods. - Updated the `bulk_footer()` method to be in line with the way things are done in the base class - Deprecated two unnecessary methods

…to deal with updates as well Most significant changes: - Add if/else switch code to deal with both install as well as update requests - Introduced new `inject_update_info()` method which adjusts the update_plugins transient to contain information on external and pre-packaged plugins as WP checks the transient before executing an update - Introduced new `get_plugins_api()` method to retrieve information from the wp.org repo API and apply some minimalistic caching for that. - Re-evaluated what information really needs to be passed to the Upgrader classes and how and implement this properly. - Updated the `maybe_adjust_source_dir()` to deal with the changes in passed information - Only update a plugin if the new version is compatible with the WP version installed

… refactoring of the method

Most significant changes: - Adjusted remaining functions to use the new abstracted logic methods - Leaner loading - only hook our actions in if we actually have something to do, also allows for some simplification of the `admin_menu()` method - activation methods now take WP version into account - Introduced the update related text strings and aligned the text strings in example.php with the ones in the main file - Added call to action for TGMPA native translations to the example file and created initial .pot file for people to use to send in translations. Take note: this file is to stay in the develop branch for now and should not be included in master yet.

…ion and add an update link depending on: - activate: whether the plugin complies with minimum required version - deactivate: 'force_activation' setting - update link: whether an update is required by the theme

@SInCE

Also: - checked that all new methods have a @SInCE tag

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add updating workflow #381

Add updating workflow #381

Commits on May 3, 2015