OOP: I completely moved the plugin to an OOP concept to get rid of all the public functions.
Extended API: The API now comes with an array of arguments. This means that I deprecated the $key argument, as it can simply be built from the label, which makes it easier. I then added in the support for a root, so we can use the WP_CONTENT_DIR, WP_PLUGIN_DIR, WPMU_PLUGIN_DIR and the root as containers for additional plugin directories. It now also works (and this was the main reason for this), if you defined an external location for your plugins. I got several local installations, that all together share the local domain plugins.dev for their plugins. This saves me from copy/pasting and updating plugins in several installations and makes development much easier. Moving the arguments to an array will make altering the API arguments much easier later on. I took some time to make shure, that we'll guide people on how to use the new API without breaking existing installations, so everything's backwards compatible. The last thing that was added, is guidance on when to hook the plugin. It's a simply call to _doing_it_wrong() if the current_filter() isn't plugins_loaded. This prevents the usage of the muplugins_loaded hook, but it isn't a loss, as the filter wouldn't help anything, as the plugin runs later.
Example Plugin: I added an example plugin to show how stuff works and should be done.
Readme: I also added a small changelog to keep people on trac. I got some code somewhere, where we could also extend the plugin info in the list table and move the changelog to a separate file, but that's code for another patch.
Everything's tested in different cases, but you know what: We're all humans and bugs are built in :)
$key
argument, as it can simply be built from the label, which makes it easier. I then added in the support for aroot
, so we can use theWP_CONTENT_DIR
,WP_PLUGIN_DIR
,WPMU_PLUGIN_DIR
and the root as containers for additional plugin directories. It now also works (and this was the main reason for this), if you defined an external location for your plugins. I got several local installations, that all together share the local domainplugins.dev
for their plugins. This saves me from copy/pasting and updating plugins in several installations and makes development much easier. Moving the arguments to an array will make altering the API arguments much easier later on. I took some time to make shure, that we'll guide people on how to use the new API without breaking existing installations, so everything's backwards compatible. The last thing that was added, is guidance on when to hook the plugin. It's a simply call to_doing_it_wrong()
if thecurrent_filter()
isn'tplugins_loaded
. This prevents the usage of themuplugins_loaded
hook, but it isn't a loss, as the filter wouldn't help anything, as the plugin runs later.Everything's tested in different cases, but you know what: We're all humans and bugs are built in :)