2015-08-08, 09:10:50
It breaks extend..
An easy to use config file wrapper for plugins is easy with 3.4, if you want to make one go ahead ill add it to 3.4
The problem without plugin classes, is you have to throw the plugin id around, there is no way to know which plugin is trying to do stuff.
( we register hooks and use debugg_backtrace to log the file and stuff, but this is being removed in 3.4 as it is inefficient and unecessary, so it cannot be used, it is also a non production function )
only register_plugin knows what the plugin id is at runtime, hmm
Maybe a interesting back portable class could be reachable by old plugins.
of course making stuff like that plugin useful might be neat
configdatatype extends class plugin.config
plugin.config.adddatatype($configid);
datatype wysiwyg
An easy to use config file wrapper for plugins is easy with 3.4, if you want to make one go ahead ill add it to 3.4
The problem without plugin classes, is you have to throw the plugin id around, there is no way to know which plugin is trying to do stuff.
( we register hooks and use debugg_backtrace to log the file and stuff, but this is being removed in 3.4 as it is inefficient and unecessary, so it cannot be used, it is also a non production function )
only register_plugin knows what the plugin id is at runtime, hmm
Maybe a interesting back portable class could be reachable by old plugins.
Code:
$myplugin = getPlugin($thisfile);
$config = $myplugin->getConfig();
$config->addConfig('color','red');
$config->save;
of course making stuff like that plugin useful might be neat
configdatatype extends class plugin.config
plugin.config.adddatatype($configid);
datatype wysiwyg