processwire
making site plugins deactivatable
it can be difficult in PW to track down module conflicts as they only can be deinstalled (thus forgetting their settings) and in some cases cannot even be deinstalled because they are used in fields.
The WordPress way of activating/deactivating plugins without consequences are much easier for me for troubleshooting tasks. I will file a request in "requests".
I was thinking of making a similar request recently. Not so much for troubleshooting (Tracy Debugger has a Module Disabler panel that is useful for that), but for modules that are autoload but not needed at all times. It would be nice to be able to deactivate such modules to avoid overhead when they are not needed but retain the module settings for when they are activated again.
Not to diminish the request, but http://modules.processwire.com/modules/module-settings-import-export/ automatically stores modules settings when it is uninstalled and provides one-click to restore them when you reinstall the module.
Thanks @adrianbj, that can be a good solution for individual cases. But for certain autoload modules where their action is designed to be temporary, it would nice as the module author to be able to suggest in the module documentation that users activate and deactivate them as needed. And to allow for this it would be desirable not to have a third-party module dependency and instead have this possible within the core.
@adrianbj .. I know and use that module - very good to have it...
Problem is:
- some modules cannot be deactivated: used in fields of having other dependencies.
- the save/restore module helps a lot but involves extra steps which makes troubleshooting a time-consuming process (not as easy as WordPress)
@Toutouwai added a good extra point: Being able to activate certain maintenance modules only when needed.
I am roughly thinking of a feature that lets the modules intact but ignores them (or for fields, leave them alone).
(I am fully aware that this request is not an easy one but I see the great benefits in WordPress.)
some modules cannot be deactivated: used in fields of having other dependencies.
How should that behave with a deactivated module though? Like I don't really see how a module shall at the same time not be available, but also not cause errors because of it's unavailability.
@LostKobrakai I know that is not an easy goal. Your point is valid! - I do not mind error messages at all, in fact they would be useful - if they come over the notification system. Just fatal errors should not happen, so you can continue testing and continue removing the dependent modules as well. - And what if modules with dependencies auto deactivate (maybe with a hint "this will also deactivate 1, 2, 3")?
The reason for the suggestion was I was asked to "testing" installed modules for a culprit I discovered. I am used the WordPress way that a good way is to remove modules one by one to see if that cures the problem. - But if this is difficult or not possible?
To find the last problem took me hours and I ended up killing the modules the hard way (skipping save/restore) and finally, after finishing testing, restoring files and database from a backup. And I thought there should be an easier way maybe.
Latest comment from @ryancramerdesign on the other thread before it was closed:
@tbba Glad you found the issue. Regarding disabling PW modules, they can't really be compared to WordPress plugins as they are completely different. PW modules aren't "active" unless some code asks for them. So the closest thing to an "active" state might be a module option in PW called "autoload", which means a module is automatically loaded and active on every request. Modules that attach hooks are typically autoload modules. There already is an option to temporarily disable an "autoload" module, but you must be in advanced mode for it to appear ($config->advanced=true;). The reason it only appears in advanced mode is because there are some dangers with disabling modules, one being that PW supports module dependencies where one module may be dependent upon another. If a dependency is broken due to a disabled module, that could result in a fatal error. So while the option is already there (in advanced mode), I just recommend being careful with it.
Latest comment from @adrianbj on the other thread before it was closed:
"> If a dependency is broken due to a disabled module, that could result in a fatal error." Which is why Tracy's Module Disabler automatically generates an SQL file and restore.php script to get your system up and running again if disabling a module breaks things.
Maybe there is a first hint regarding as solution. Debugging is superadmin work anyway so enabling config->advanced for troubleshoot purposes would be thinkable. Also I did not know that Tracy comes with a modules disabler now, will check that out.
Why those things get important i.m.h.o: There are more and more modules in the repo which were good when they were developed and got praise and rankings by the community but now have been given up and are becoming a potential problem over time. (The module I had to throw out now, I thought being an innocent admin back end helper and not a troublemaker with modals.) So I hope this request can stay open even if here is no easy and quick solution in sight.
@tbba yes the modules directory has some old stuff in it. The modules directory itself is old, and it's one of the next items on the rebuild list (to match the new site). My plan is to remove old modules that don't appear to be maintained any longer, as part of that redevelopment project.
The module disabler mentioned for Tracy sounds like it would be a better bet than using the advanced mode one.
The module disabler mentioned for Tracy sounds like it would be a better bet than using the advanced mode one.
It still requires advanced mode to be on - it's main advantage is that you can disable all autoload modules and then re-enable one-by-one to figure out the problem. And of course the autobackup and semi-automatic restore in case of a problem is a nice bonus.
I was searching for this functionality and found this feature request. It is open and I think the functionality is very useful. The debugging is just one use case. Turning modules on/off in different environments without loosing settings is another. Have some rearely used modules not being loaded all the time as @Toutouwai said is the third. Is there a chance it will get implemented and available in non-advanced mode, @ryancramerdesign?
