Add updating workflow #381
Conversation
- `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
|
+1 good job |
|
@jrfnl got a bug : |
|
General comment - do all of the new methods need to be public? Could some be protected? |
Unfortunately yes. For the TGMPA class methods - nearly all of them are also called from the List_Table/Bulk_Installer/Bulk_Skin classes and therefore those need to be public. For the new methods in the List_Table class - the ones overloading methods in the WP native class have to be public for the code to be compatible with WP < 4.x The scope keywords were left off in the WP versions before that time, so you'd get a E_STRICT warning about the scope being wrong if they are not public. |
|
great work guys, we will test it out soon. Thanks 👍 |
Also: - checked that all new methods have a @SInCE tag
@duckzland I've looked into this and believe I've been able to reproduce the issue and fix it. Could you please test again ? |
|
@GaryJones Thanks for reviewing. I've made the necessary adjustments & pushed. |
…orkflow Add updating workflow
|
@jrfnl I've tested it and seems its working as intended, I think it is better to stop testing untill the code is ready for testing as now it seems that too much changes going on. |
|
@duckzland Thanks for testing. What do you mean by :
Since this PR was merged beginning of the week, nothing has changed which should impact users. |
|
@jrfnl so it is ready for testing with no more major changes and just for bug hunting for 2.5.0 release at this stage? |
|
From my point of view, I don't expect any more big changes for the 2.5.0 release, so yes, testing is very welcome. |
|
I found an issue with packaged plugins that have uppercase letters in their slug, e.g. 'LayerSlider'. and 'Ultimate_VC_Addons'. The install and update options both failed with no errors for these plugins, but worked perfectly when I converted them to lowercase. Everything else I tested worked very well. |
|
@steveboj I have the same issue |
|
I'm having trouble getting the new update function working with multiple bundled plugins from zip files: Scenario 1: I click the "update" link for an individual plugin and I receive the "The plugin is at the latest version." message. Scenario 2: I click the "update" link for a plugin and I see the success messages, but when I return to the updater page it says that plugin still needs to be updated. I click the "update" link again, but this time it shows me the "The plugin is at the latest version." message. When I check the plugins folder it still contains the old copy of the plugin. Scenario 3: I use the bulk "update" function and it goes through each plugin saying they have been updated successfully, but when I return to the plugins page it shows me none of the plugins have been updated. When I try to update any of them individually, I get the "The plugin is at the latest version." message. Scenario 4: I click the "update" link for an individual plugin in the list and it updates perfectly. Has anyone else experienced anything similar? |
|
@steveboj Updating with bundled plugins can only be done by setting a minimum required version of the plugin in the settings file - the TGMPA cannot obtain information about the version nr of bundled plugins, so we need to rely on the information you provide in the settings file to determine if there is an update. [Edit] Oh and make sure the bundled version actually has the correct version nr in the plugin header and such as otherwise WP will still give us the wrong version nr to work with. |
|
@jrfnl The versions numbers seem to all be correctly setup. I'll test some more and see if I can find any more clues. Let me know if you think of anything else that could cause this type of issue. |
|
@steveboj Great - any more clues you can give me to track down why it's not working for you, would be helpful. Insight into your settings and possibly copies of the offending .zip files could help too (old version + new version). |
|
Seems like new changes works well. Any idea, when the new version or stable release is coming? To be used in production. |
|
When it's ready - hopefully, before the end of the month. |
Closes #192, #350, #351
The commits have been set up to facilitate easier code review as these are quite significant changes. Please see the individual commit messages for detailed information on what I've changed, how and why.
Functional highlights:
force_activationistruefor a pluginBranch has been tested, but further testing is very welcome /cc @duckzland @swiderski
Testing on setups with non-direct filesystem access would be much appreciated (should work, but rather would get it confirmed).
Should work with WP 3.7 and higher.
Props [Zauan/Hogash Studio], [Christian], [Franklin Gitonga], [Jason Xie], [swiderski] for the inspiration.
Screenshots: