WooCommerce Compatibility Checker – Show if plugins active or inactive

Hello,

Thanks for the feedback, I’ve passed it along to our product team.

I think deactivating the plugins directly in this area is a bit out of scope, as the plugins screen for doing this is only one click away.

And then also it is best to uninstall un-used plugins rather than keeping them around ??

Hi Caleb,

Thanks for the reply.

Yes, (2) was an optional extra (just as 1 is an optional first).
But although the uninstall is just a click (or two) away, they are also page reloads, and scrolls. This list that is presented by WooCommerce is specifically only those which need to be handled.
On the other hand, if WooCommerce was able to have some hightlighted way to display the plugins which are on this list, in the plugins list, or make a submenu (on the left sidebar) for these plugins – then that would help the user decide how they want to process the plugins.

(1) is especially handy, in the case that it helps show if “all” the plugins are of unknown compatibility are inactive, then there is no immediately reason to prevent the update. It would continue to be useful, if it detected the activation or installation of plugins of unknown compatibility, after the update of WooCommerce.

Qa) Does WooCommerce continue to check plugins installed after the update?

Qb) Does WooCommerce continue to check plugins installed before, but activated after the update?

(1) is handy, in any case because the user can then deal with the plugins which are active.

Presently the method requires making a mental note, or jotting down the list, or copy and paste to notepad. In order to cross reference while on the plugins list. This is the kind of task, which computers are very good at doing. Every time a pen is needed, is time to ask if this is the best way (it may be the best way, but it is worth checking).

A bit of an extra understanding
The approach of uninstalling unused plugins, is good, but it is based on the proviso that if it is unused then it it is not going to be used.
This is not the case, when a user is trying out different options of plugins that cover the same needed functions – something which needs to be done when previously used plugins are either out of date, or become incompatible with the system.
The problem with plugins is that many have significant overlaps in function, with other plugins that may not be very closely related in their core function, which causes interference.

I have provided feedback to at least one plugin management plugin, with these processes in mind, and currently can do swap in/out tests more easier.

Thanks for forwarding to the product team.

In the system status report at WooCommerce > Status, you can get a list of plugins and their compatibility status at any time.

Hi Caleb,

Thanks for that info.

What I notice though, is that the Status lists “all” the “Active” Plugins.

Whereas WooCommerce’s Update Compatibility Checker looks for all the “installed WooCommerce plugins” both “Active and De-Active”.
The WC Update Checker is not interested in other plugins, only the WooCommerce related plugins.

Additional Suggestions ;
a) What is also useful, is that Status list shows the plugin names with links to their plugin site. If this was done on the WooCommerce Compatibility Checker list, then it would make it much easier for users to report incompatibility to the respective plugins.

b) The Status list could be a good place to show all WooCommerce plugins, and whether they are Active/De-Active, and Compatible/InCompatible.

Thanks

• This reply was modified 6 years, 8 months ago by Jan Dembowski.
• This reply was modified 6 years, 8 months ago by MKSnMKS. Reason: improved formatting and layout

Ah true, the system status report only shows active plugins. But again back to an earlier point where it shouldn’t really be common to have deactivated plugins on a live site. I do get what you are saying, but a deactivated plugin isn’t really high priority.

If the plugin has provided a contact link, then there should be a “Visit plugin site” or similar link under the plugin on the plugin’s listing page. It isn’t good to duplicate such behaviors, so best to just utilize that location if a link is needed.

Hi Caleb,

1) Re

it shouldn’t really be common to have deactivated plugins on a live site

This may have been what was previously normal, though even then – not the only operational situation especially for smaller users.
But nor has it been previously normal to have plugins that require declarations of compatibility such as WooCommerce now does.

So, especially during the change in the resulting operational environment, there should be many users that are disabling plugins of “unknown” compatibility, so they can update WooCommerce.

If you are suggesting that they then go on to delete these plugins that they have had to disable (temporarily till the plugins get updated), then WooCommerce is having a greater effect by this new requirement.

This situation therefore has a significant effect on plugins which are ill informed about the new requirement to declare compatibility, compared to those select plugins which are informed. So there is a biased outcome for plugin projects which is based on the information they are provided, rather than their programming proficiency or popularity of product.

2) Re

It “isn’t good” to duplicate “such” behaviors

There are many situations where behaviors are duplicated – the programming is not duplicated, just the same function is presented elsewhere. One example (using WordPress), is plugins that place their “settings” in the “Settings” menu on the left side of the dashboard, and “settings” under the plugin in the plugin listing, and “settings” within the plugin. This is up to three places that the same function is presented.
So it is not a big ask to repeat the same function, in locations where it is convenient to have it available to the user.

Instituting this feature will help the typical user help clean up problems with uncompatible plugins. There may not be many WooCommerce users presently reporting uncompatibilities to plugin authors, so one might conclude “therefore methods to assist the user to report are not needed because not many do”. But is is also possible to conclude “therefore the user needs to have better assistance to make a report, so that many more can and do make reports”.

What might be important to consider is ; “Due to WooCommerce’s actions, how many plugins are likely to be adversely effected and possibly dropped from popular usage?” – I don’t need to know the answer to that, but I do hope that it is being considered.

Thank you for continued discussion on this topic.
Appreciated.

Thanks for the feedback. There is definitely room for improvement with the compatibility checking. Another good place for this would be in a dev chat: https://woocommerce.wordpress.com/2018/03/20/march-27th-dev-chat-20/

We also accept pull requests ??

Hi Caleb,

Thanks for the thanks, and for the link.
I prefer to keep comms at WP, otherwise I’d be all over the place with different plugins.

But please, feel free to copy and paste – no accreditation needed – just aim for getting what is helpful, through to where it needs to go – probably the dev team.

How does pull requests work?

Thanks

Pull requests would be contributing the needed code to the WooCommerce plugin. Would recommend starting with a discussion in Github before working on the code though.