Refactor module activation handler and options

[herrvigg]

Disambiguate the confusion between module state and admin options.

• The module state usually depends on other plugin states.
• The admin settings to manually disable or enable the modules are just admin "preferences" for the module activations.

Changes

• Admin settings (checkboxes) Make this option admin (previously core) as it's not used on front side. Rename the ma_module_enabled option to admin_enabled_modules. It is saved only from the admin settings and can be deleted at any time. Make the list display clearer.

• Module state Rename module status to state. Refactor the module state update to be triggered on various events. Rename qtranslate_modules option to qtranslate_modules_state. The admin enabled settings are only read for the state updates.

[herrvigg]

This fixes several bugs, including the change of state from integration plugins.

Still WIP (Work in Progress). Different scenarios to be tested and default values to be completed.

[spleen1981]

Something's wrong when removing check to all modules. I have two modules activable, say woocommerce and slugs:

1. enabling both and saving: ok
2. disabling one and saving: ok
3. disabling remaining module (doesn't matter which one) and saving: not working, check is still there and module is still active.
4. unchecking both from situation at bullet 1 and saving: not working, both modules are still checked and active
5. switching selection at bullet 2 and saving: ok

[herrvigg]

First need #1151, I reworked that bool-array type in an independent patch.

[herrvigg]

The last updates should fix the main problems.

The hardest part with the modules are the activation dependencies coming from other plugins (integration plugin + incompatible plugin). This Pull Request is a major overhaul to separate checkbox settings from the state making it more robust and easier to maintain. The settings should only change when the admin presses "Save". But the states can change on many other events.

I'm also checking special cases after deleting options in DB and initial activation.

[herrvigg]

@spleen1981 Thanks for the last fix, I just noticed that issue! I'm double checking if we want this call here in any case.

The initial activation from zero setting in DB should now work as expected. The first time, all the modules are enabled by default except slugs. But the associated plugin must be activated otherwise the module remains inactive.

However the behavior on save has slightly changed. If a module is disabled (forced due to integration plugin off or incompatible plugin on), its admin_enabled_modules value is saved as false. I didn't really intended it, but this means it won't be re-activated automatically. The module remains inactive even when the related plugin is turned on. Then it needs to be enabled manually - although the default option was true. I'm not sure this is what is expected. Otherwise the default value should be saved in any case, even if the module was inactive at the moment the settings were saved (disabled).

[herrvigg]

@spleen1981 what happened with the last commit, what are you merging? This is wrong. I revert that change.

[spleen1981]

@spleen1981 what happened with the last commit, what are you merging? This is wrong. I revert that change.

oops, sorry I messed up while playing with my fork... thanks

[herrvigg]

I think this patch is ready, I merge to give a new reference point. I have other changes coming to redesign the module classes better.

[herrvigg]

I'm just finishing a few things but I'd like to release this very soon as QTX-XT 3.12.0. It's been a while there hasn't been any release. Initially my plan was only to add slugs without so many changes, but the module refactoring is good to have now.

The next big version will be a version 4 with many breaking changes, moving to higher PHP versions, ...