[wp-hackers] Improving Plugin (and Theme) metadata

Peter Westwood peter.westwood at ftwr.co.uk
Fri Jan 25 08:52:39 GMT 2008

Hash: SHA1

Some design improvements below after sleeping on the idea.

Peter Westwood wrote:
| Some goals for the implementation:
| 1. Provide the ability for plugin/theme meta data to be translated.
| 2. Seperate the meta-data from the rest of the plugin/theme.
| 3. Combine the parsing code used for plugins and themes.
| 4. Allow for extensible metadata.
| Requirements:
| 1. Use gettext so as to integrate with the rest of a plugins translation.
| 2. Protect against malformed plugins breaking the admin with PHP errors.
| Possible Solution:
| 1. Plugins have to be stored within a folder under PLUGINDIR.
| 2. All plugins have a metadata.php file.
| 3. metadata.php file is included by the admin plugin page (not in global
| scope to keep it clean) as a way of discovering the available plugins.

Rather than a metadata.php file we move back to single file plugins.

When we are discovering plugins we define('WP_PLUGIN_DISCOVER',true);
the simple plugin file my_plugin.php which is in the root PLUGINDIR becomes:



register_plugin( __FILE__,
~                 __('Description'),
~                 __('Plugin Name'),
~                'http://example.com',
~                'Joe Bloggs',
~                 'http://joe.bloggs.name'),);

if ( !(defined('WP_PLUGIN_DISCOVER') )
	//All plugin code goes here including includes.

//The End

You can still use a folder and a metadata.php if you want.

- --
Peter Westwood
http://blog.ftwr.co.uk | http://westi.wordpress.com
~ C53C F8FC 8796 8508 88D6 C950 54F4 5DCD A834 01C5
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the wp-hackers mailing list