Download
2015-07-27, 23:42:40
The example plugin is awful and dated.
Our plugin system is awful and dated....
3.4 does add a few fileio helpers so plugins do not have to deal with things like paths and security, or backups, or thumbs, but some things are still a pain in the ass, namely how plugins add sidemenus and their own pages with a mix of register_plugin params, hooks, and defined function callbacks.
These need to be easier and not so confusing. ( why does add_action sidemenu need to call createsidemenu )
wrappers for add_sidemenu, add_nav makes more sense.
registering callbacks for plugin pages should be easier than specifying which page i the register plugin params, which is only used for tab highlighting, which is again terribly confusing.
A bunch of params are passes around just to highlight stuff....
I think oop is a good way to go , but it needs to be extremely abstracted for ease of use.
and very easy to use, no advanced knowledge of autoloading or constructors.
plugins load.php action callbacks are confusing, you only get one, you can't add arguments, you have to merge in your own hooks and request checking, so whats the point. Stuff like this is what i find to be hard to understand.
This should be easy and can be
But we have no support in core for this stuff
we need action support, argument fetching support, plugins should not have to check POSTs, they should be passed from core to the plugin if the plugin registered a page etc.
Translation should be standard in a sample plugin
A standard config/collection file format and saving and reading with data path wrapping, so you only need to know your subpaths, and not have to deal with GSDATAOTHERPATH etc.
<items><item>
better way to register plugins, not a function call with arguments.
this plugin name =
this plugin id =
this plugin author =
non global pollution
Also a simple asset structure included with htaccess files
or a very minimal mvc struture
/assets/js,css,
/inc/
and a simple plugin for doing simple hooks or filters
a sample content filter, sitemap filter etc.
I like little plugins, that is the whole point, you want to send custom headers, why write the code and inject it somewhere, use a 5 line plugin.
I convert components into plugins all the time when they exceed more than say 5 functions or so.
( I use my component_hook plugin alot )
The biggest pain is global polution and unique naming, so here is where a class really shines, code reuse for the basic stuff that is in every single plugin.
Our plugin system is awful and dated....
3.4 does add a few fileio helpers so plugins do not have to deal with things like paths and security, or backups, or thumbs, but some things are still a pain in the ass, namely how plugins add sidemenus and their own pages with a mix of register_plugin params, hooks, and defined function callbacks.
These need to be easier and not so confusing. ( why does add_action sidemenu need to call createsidemenu )
wrappers for add_sidemenu, add_nav makes more sense.
registering callbacks for plugin pages should be easier than specifying which page i the register plugin params, which is only used for tab highlighting, which is again terribly confusing.
A bunch of params are passes around just to highlight stuff....
I think oop is a good way to go , but it needs to be extremely abstracted for ease of use.
and very easy to use, no advanced knowledge of autoloading or constructors.
plugins load.php action callbacks are confusing, you only get one, you can't add arguments, you have to merge in your own hooks and request checking, so whats the point. Stuff like this is what i find to be hard to understand.
This should be easy and can be
But we have no support in core for this stuff
we need action support, argument fetching support, plugins should not have to check POSTs, they should be passed from core to the plugin if the plugin registered a page etc.
Translation should be standard in a sample plugin
A standard config/collection file format and saving and reading with data path wrapping, so you only need to know your subpaths, and not have to deal with GSDATAOTHERPATH etc.
<items><item>
better way to register plugins, not a function call with arguments.
this plugin name =
this plugin id =
this plugin author =
non global pollution
Also a simple asset structure included with htaccess files
or a very minimal mvc struture
/assets/js,css,
/inc/
and a simple plugin for doing simple hooks or filters
a sample content filter, sitemap filter etc.
I like little plugins, that is the whole point, you want to send custom headers, why write the code and inject it somewhere, use a 5 line plugin.
I convert components into plugins all the time when they exceed more than say 5 functions or so.
( I use my component_hook plugin alot )
The biggest pain is global polution and unique naming, so here is where a class really shines, code reuse for the basic stuff that is in every single plugin.
