Textpattern CMS support forum
- Plugin Author
- From: France
- Registered: 2008-07-24
- Posts: 860
Manage plugin extensions lifecycle from a main plugin
Hi, I’m considering to make each oui_player provider a plugin. The idea would be to have the oui_player plugin as a main base and providers as oui_player extensions (oui_player_youtube, etc.).
The thing is that I would like oui_player to manage the providers prefs on install/deletion. I don’t want to include a dedicated lifecycle related code into each extension. It does not seem doable for now because plugins are not loaded in the Plugin tab, so oui_player can’t detect providers (which use a callback to be plugged into the main plugin code) to set/update their prefs. Would I need to create an extension tab with, for example, a button like Update prefs to be able to update the oui_player prefs and the providers prefs from oui_player or is there a trick I can’t think about?
Last edited by NicolasGraph (2018-04-18 08:33:50)
- From: Leeds, UK
- Registered: 2006-01-29
- Posts: 8,498
Re: Manage plugin extensions lifecycle from a main plugin
A good idea. I’ve toyed with this idea in the past. Options:
- Add a tiny (tiny) lifecycle handler in each module that simply invokes a method on the parent plugin on installation and passes the module’s prefs array to it.
- Add a callback in each module on any admin panel of your choice (or all of them in
head_endor something if you can keep the processor cycles short) that checks if the module’s prefs exist. If so, great. If not, call the parent plugin’s installation routine with the module’s prefs array as a parameter.
There are variations on the above, but the key things to remember are that the lifecycle events are only called if the plugins are loaded from the DB, not cache directory. This means the second approach above is more robust as it’ll get called regardless on next admin-side action. I do that in some plugins, for this very reason.
Secondly, defend against situations where the parent plugin is disabled/deleted but the dependent modules are still active. i.e. check if the destination method/class/function exists before making the call to avoid ugly errors.