We already tried a cleaner way to do the same thing, which also handles deactivation on uninstall - just filter the value of the option rather than modifying it in the database. However there are two major issues with this approach - it causes an error on the plugins list since a non-existent plugin is marked as “active”, or if WooCommerce is actually still present but deactivated, then it will be re-activated by this code. See: Add the woocommerce/woocommerce.php to active_plugins options by bahiirwa · Pull Request #133 · ClassicPress/classic-commerce · GitHub
Due to the complexity of this issue, and what needs to be done in order to solve it automatically (disable WooCommerce if it still exists on the site, and replace it with something else), I’m not sure if this is a good idea. Not all users will need to install this compatibility plugin, so I think you might want to consider making it optional.
If you really want to avoid an extra, small plugin, it might also be possible to work around this issue using a filter/hook that returns different results depending on where it is called from - but this is not really a type of code that I would call “production-ready”.
I’m also open to other fixes that involve adding new filters to ClassicPress, but any such solution would have the drawback that the plugin requires a minimum version of ClassicPress (and not WordPress) in order to work properly.
How many of these are there really? In any case, the best long-term fix is to get extension authors to update their code for full compatibility.
Oh I see, sorry. That’s an unknown, but there are plugins like EDD, WP RSS Aggregator, etc, that have large numbers of extensions and may need to be forked in the future.
I think and think.
There’s a fix for this. Not in code.
You fork WooCommerce. People need extensions. Ok. There is room here for a dev company to just supply the forked extensions modified accordingly on a paid basis.
This will be structured in time, and it’s the only clean solution.
For now we can think of boundling the most used wc extensions in one big package together with the compatibility plugin. Telling users there is some dev preparing the cc versions.
They can use the free wc boundle, or buy the cc boundle that may come with enanchements of all sorts.
I know I am crazy. But I am an user…
That’s a fair point. The aim to let CC “handle the rest” is still sound even if that means it doesn’t install the plugin. But at the same time, I’m acutely aware of the many rabbit holes this could lead us down.