New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement a version check for extensions. #15478

Closed
claudiulodro opened this Issue Jun 6, 2017 · 12 comments

Comments

Projects
None yet
@claudiulodro
Contributor

claudiulodro commented Jun 6, 2017

See: This comment thread.

We need to implement a good solution for managing extension version requirements. A lot of stuff broke on sites when people upgraded WooCommerce to 3.0 without having WooCommerce 3.0-compatible extensions.

One proposed solution is to have a "Tested up to" item in the extension docblock. Plugins that don't have the correct WooCommerce version in their "Tested up to" will get a warning, potentially get deactivated, etc.

More planning is needed to determine the correct behavior for extensions that haven't been tested up to the minimum WooCommerce version.

====================================
Components

  • Plugins screen inline and modal notice.
  • Bulk plugins screen modal notice.
  • Prevent auto-updating of WC if major release and plugins untested.
  • Good-looking modal notice design (@mikejolley)
@NickGreen

This comment has been minimized.

Show comment
Hide comment
@NickGreen

NickGreen Jun 6, 2017

Plugins that don't have the correct WooCommerce version in their "Tested up to" will get a warning, potentially get deactivated, etc.

To expand on this idea: now that WC is using semantic versioning, what if major releases had capability to deactivate, but point releases would simply produce a warning?

That would prevent the issue of a quick WC bugfix release deactivating swaths of extensions, but still prevent major "backwards compatibility" issues.

NickGreen commented Jun 6, 2017

Plugins that don't have the correct WooCommerce version in their "Tested up to" will get a warning, potentially get deactivated, etc.

To expand on this idea: now that WC is using semantic versioning, what if major releases had capability to deactivate, but point releases would simply produce a warning?

That would prevent the issue of a quick WC bugfix release deactivating swaths of extensions, but still prevent major "backwards compatibility" issues.

@thenbrent

This comment has been minimized.

Show comment
Hide comment
@thenbrent

thenbrent Jun 6, 2017

Member

Also for posterity, link to initial Slack discussion: https://woocommercecommunity.slack.com/archives/C4TNYTR28/p1496765681939300

Member

thenbrent commented Jun 6, 2017

Also for posterity, link to initial Slack discussion: https://woocommercecommunity.slack.com/archives/C4TNYTR28/p1496765681939300

@bekarice

This comment has been minimized.

Show comment
Hide comment
@bekarice

bekarice Jun 7, 2017

Contributor

Plugins that don't have the correct WooCommerce version in their "Tested up to" will get a warning, potentially get deactivated, etc.

Rather than deactivating the plugin, the issue here is updating WC core without having updated the plugin first. I'd recommend showing a notice / requiring confirmation before updating WC itself instead.

While this isn't always a hard requirement (upgrading extensions first), it does ensure the smoothest experience for the merchant, as compatibility code is therefore already in place.

Example:

  • I run WC 3.0.8 and Subscriptions 2.2.7
  • WC 3.1.0 comes out, and Subscriptions doesn't have WC tested up to: 3.1.0 yet in the header (or any number of other plugins)
  • When I go to update WC, it warns me of this:

    Heads up! The following plugin(s) are not listed compatible with WooCommerce 3.1.0 yet. If you upgrade without upgrading these extensions first, you may experience issues:

    • WooCommerce Subscriptions
    • Plugin 2, etc

      [Abort Upgrade] [Upgrade Now]

Obviously hosting auto-updates of WC core will still pose an issue, so potentially as Nick mentioned, looking at deactivating plugins then could be an option with major updates:

Heads up! The following plugins are not listed as compatible with WooCommerce 4.0.0, which is a major update. These plugins have been deactivated as a precaution; you can re-enable them at your own risk, but please upgrade as soon as possible:

  • Plugin 1
  • Plugin 2

In this sort of case, though, I'd be pretty hesitant to deactivate essential plugins without emails and every flashing light possible sent to site admins as well. Imagine if you sell subscription products and you have no subscriptions now, if you have a payment gateway that wasn't compatible and now you can't take orders, or if you run a membership site, but haven't upgraded Memberships yet, and all content is public when it's deactivated. The best course is prompting for extension updates first.

It sounds like working with hosts that auto-upgrade would probably be a more sane solution so as not to upgrade to a major version automatically, letting users see the "these plugins need an update" alert instead.

Contributor

bekarice commented Jun 7, 2017

Plugins that don't have the correct WooCommerce version in their "Tested up to" will get a warning, potentially get deactivated, etc.

Rather than deactivating the plugin, the issue here is updating WC core without having updated the plugin first. I'd recommend showing a notice / requiring confirmation before updating WC itself instead.

While this isn't always a hard requirement (upgrading extensions first), it does ensure the smoothest experience for the merchant, as compatibility code is therefore already in place.

Example:

  • I run WC 3.0.8 and Subscriptions 2.2.7
  • WC 3.1.0 comes out, and Subscriptions doesn't have WC tested up to: 3.1.0 yet in the header (or any number of other plugins)
  • When I go to update WC, it warns me of this:

    Heads up! The following plugin(s) are not listed compatible with WooCommerce 3.1.0 yet. If you upgrade without upgrading these extensions first, you may experience issues:

    • WooCommerce Subscriptions
    • Plugin 2, etc

      [Abort Upgrade] [Upgrade Now]

Obviously hosting auto-updates of WC core will still pose an issue, so potentially as Nick mentioned, looking at deactivating plugins then could be an option with major updates:

Heads up! The following plugins are not listed as compatible with WooCommerce 4.0.0, which is a major update. These plugins have been deactivated as a precaution; you can re-enable them at your own risk, but please upgrade as soon as possible:

  • Plugin 1
  • Plugin 2

In this sort of case, though, I'd be pretty hesitant to deactivate essential plugins without emails and every flashing light possible sent to site admins as well. Imagine if you sell subscription products and you have no subscriptions now, if you have a payment gateway that wasn't compatible and now you can't take orders, or if you run a membership site, but haven't upgraded Memberships yet, and all content is public when it's deactivated. The best course is prompting for extension updates first.

It sounds like working with hosts that auto-upgrade would probably be a more sane solution so as not to upgrade to a major version automatically, letting users see the "these plugins need an update" alert instead.

@franticpsyx

This comment has been minimized.

Show comment
Hide comment
@franticpsyx

franticpsyx Jun 7, 2017

Member

Add my vote to what Beka just said.

Deactivating plugins is not something I'd consider ad an option under any circumstances. A notice should be enough to make people think twice.

What I'd look into for the first iteration of this warning system is a way to make it work reliably when bulk-updating.

Another point already brought up is the need to work with hosts to ensure that this "warning system" will prevent auto-updates. Better yet, I would also try to educate them on the need to update WC extensions (WC tested up to) before WC core.

Member

franticpsyx commented Jun 7, 2017

Add my vote to what Beka just said.

Deactivating plugins is not something I'd consider ad an option under any circumstances. A notice should be enough to make people think twice.

What I'd look into for the first iteration of this warning system is a way to make it work reliably when bulk-updating.

Another point already brought up is the need to work with hosts to ensure that this "warning system" will prevent auto-updates. Better yet, I would also try to educate them on the need to update WC extensions (WC tested up to) before WC core.

@mikejolley mikejolley modified the milestone: 3.2.0 Jun 7, 2017

@douglsmith

This comment has been minimized.

Show comment
Hide comment
@douglsmith

douglsmith Jun 7, 2017

Contributor

According to the Creating a Plugin page, extensions are already supposed to have a WC requires at least and WC tested up to headers in the readme.txt file along with the standard WordPress headers.

I attempted to reference these in preparation for upgrading to WC 3 but there were too many extensions without them for it to be useful. So part of what is needed here is as much policy and education as code. A good first step would be requiring all extensions sold through WooCommerce.com to have them.

Contributor

douglsmith commented Jun 7, 2017

According to the Creating a Plugin page, extensions are already supposed to have a WC requires at least and WC tested up to headers in the readme.txt file along with the standard WordPress headers.

I attempted to reference these in preparation for upgrading to WC 3 but there were too many extensions without them for it to be useful. So part of what is needed here is as much policy and education as code. A good first step would be requiring all extensions sold through WooCommerce.com to have them.

@ben72

This comment has been minimized.

Show comment
Hide comment
@ben72

ben72 Jun 7, 2017

Bare in mind many updates are carried out using remote systems like iThemes Sync, ManageWP etc. Warning messages will not work in those cases.

So warning messages can be a good complement but education seems to be the simplest and most reliable way to go.

ben72 commented Jun 7, 2017

Bare in mind many updates are carried out using remote systems like iThemes Sync, ManageWP etc. Warning messages will not work in those cases.

So warning messages can be a good complement but education seems to be the simplest and most reliable way to go.

@NTShop

This comment has been minimized.

Show comment
Hide comment
@NTShop

NTShop Jun 19, 2017

I agree with @ben72 - education is realiable. Loads of developers won't know to add any particular plugin header tags, so in those cases version checking won't help. What might help is somehow warning site operators that an update might break their site if they proceed. So in other words, add glaringly obvious descriptive info the WC "update available" notice that can be read before they click to update, and maybe hooking into the update process to intercept the update process before proceeding to confirm that they're sure they've check compatibility and really want to proceed. Some JS could help with the latter, there are unique class names in the list of plugins on the plugins page that can be used, same for the Dashboard -> Updates page (except hooking into it with JS would be different since it's a form).

NTShop commented Jun 19, 2017

I agree with @ben72 - education is realiable. Loads of developers won't know to add any particular plugin header tags, so in those cases version checking won't help. What might help is somehow warning site operators that an update might break their site if they proceed. So in other words, add glaringly obvious descriptive info the WC "update available" notice that can be read before they click to update, and maybe hooking into the update process to intercept the update process before proceeding to confirm that they're sure they've check compatibility and really want to proceed. Some JS could help with the latter, there are unique class names in the list of plugins on the plugins page that can be used, same for the Dashboard -> Updates page (except hooking into it with JS would be different since it's a form).

@claudiulodro

This comment has been minimized.

Show comment
Hide comment
Contributor

claudiulodro commented Jul 13, 2017

@mikejolley

This comment has been minimized.

Show comment
Hide comment

@mikejolley mikejolley removed this from the ⚡ 3.2.0 - Sprint 5 milestone Aug 13, 2017

@mikejolley mikejolley closed this Aug 21, 2017

@webdados

This comment has been minimized.

Show comment
Hide comment
@webdados

webdados Oct 11, 2017

Contributor

Just a heads up that the documentation says the headers should be on the readme file, but actually they should be on the plugin main file.
https://docs.woocommerce.com/document/create-a-plugin/#section-8

I was updating a couple of plugins of mine and couldn't make the "Not tested with the active version of WooCommerce" message go away because I was adding the headers to readme.txt instead on the plugin main file.

Contributor

webdados commented Oct 11, 2017

Just a heads up that the documentation says the headers should be on the readme file, but actually they should be on the plugin main file.
https://docs.woocommerce.com/document/create-a-plugin/#section-8

I was updating a couple of plugins of mine and couldn't make the "Not tested with the active version of WooCommerce" message go away because I was adding the headers to readme.txt instead on the plugin main file.

@claudiosanches

This comment has been minimized.

Show comment
Hide comment
@claudiosanches

claudiosanches Oct 11, 2017

Member

@claudiulodro I just updated it, but feel free to improve.

Member

claudiosanches commented Oct 11, 2017

@claudiulodro I just updated it, but feel free to improve.

@claudiulodro

This comment has been minimized.

Show comment
Hide comment
@claudiulodro

claudiulodro Oct 11, 2017

Contributor

Looks good. Thanks @claudiosanches!

Contributor

claudiulodro commented Oct 11, 2017

Looks good. Thanks @claudiosanches!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment