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

[wordpress at santosj.name]

> Hi All.

Hello bro.

> Firstly apologies for starting a new thread but the old one has grown a
> bit and I want to try and refocus the discussion a bit.

No problem, your stuff is good enough to validate a new thread.

> We have a number of issues with the theme and plugin metadata at the
> moment:
>
> 1. You can't localise it. (#3089)

Damn, I knew there was some reason you couldn't use variables, but I
totally forgot what the reason was. I think your suggestion is quite a
good one, but I disagree with one point.

Wait, the variables weren't supposed to be translated. I suppose I should
have just used translate function instead of __().

> 2. It can cause fatal errors due to things like file size etc. (#5651).

Yeah, you know. I fixed both of those issues. Well, yeah, it would be good
to start a topic on why those fixes weren't committed. I don't know about
the patch, or like, WTF, but yeah, I tested those issues and they work for
me.

You've done a really good job cleaning up my last patch, so I'm unsure
whether or not you're doing the same for the current patches. However, it
would be nice to know, if the patch doesn't meet your standards, so that I
could work with you on those issues.

I think, #3141 would solve the memory issue and reduce the support tickets
for this problem a great deal. Let me know what I can do to correct any
issues with #3141 and #5651. I was hoping to get them in before I stopped
having a lot of time, but I'll make the exception for those two and #3089.

> 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.

Makes sense. This pretty much goes along with number two, because each
plugin would have to exist in their own folder. It would also simplify the
code, if number two was also used.

> 2. All plugins have a metadata.php file.

Lets call it something else, so we can use it for more than just metadata.
See below.

> 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.

I would suggest, that 1) we allow for single file (php) files to exist in
the PLUGINDIR root, which we can assume that they are their own plugin and
allow for register_plugin() to exist within that single file.

If there is only one (php) file in directories above PLUGINDIR, then we
can assume that it holds the register_plugin() function.

The reason I suggest this, is that there are too many plugins which exist
in one file anyway, so it would be unreasonable to restrict them.
WordPress 2.5 would go from hundreds of plugins to only a handful. Not
progress in my opinion, even if we provide backwards compatibility.

We also don't want to over complicate plugin authors, if they want to have
just one file, then let them. There is nothing wrong with have simple
plugins contained in one file, and there is nothing wrong with optimizing
plugins and combining many files into one.

I would suggest, that plugin authors that have their plugins contained in
one directory, that they use a library directory for their plugin. That is
to say, that for plugins that I write, the file that contains the metadata
already does contain the metadata and I'm just including other files.
Don't force me to create another file in the root that does the same
thing. If there is already one PHP file, then assume that it contains the
metadata.

I do suggest that metadata be required if it exists, but this can only be
done if there is only one PHP file in the directory. If there is more than
one, then assume that it is using the comment metadata and do not include
it if it isn't valid. This will allow for extra features to be included
eventually, even if it isn't included in 2.5, at least it can get into 2.6
and slow deprecate the old style.

> Example metadata.php file:
>
> <?php
>
> load_plugin_textdomain();
>
> register_plugin( plugin_filename.php,
> ~                 __('Description'),
> ~                 __('Plugin Name'),
> ~                'http://example.com',
> ~                'Joe Bloggs',
> ~                 'http://joe.bloggs.name'),);
>
> //The End
> ?>
>
> What do people think?
>
> westi
> - --
> Peter Westwood
> http://blog.ftwr.co.uk | http://westi.wordpress.com

I like it and will begin working on it, I'm sure someone else is probably
doing so, but I think with something this big, it would be good to have
two or more solutions to throw around and pick and choose the best one.

However, I don't believe, that if you have just metadata.php, that it
should be restricted to just metadata. I would suggest that you include
install and uninstall information and add that into the feature set. Why
have one file for just metadata, when you can register install and
uninstall info also?

I would also suggest that if we had a required file, that we can add more
stuff, like registering configuration pages and simplify that process as
well.

Lets clean up a lot of tickets and just go crazy. I've been waiting for
this moment and it would make adding new features a lot easier. If I do go
crazy, hopefully, the ticket will be included.

I'm not sure how much work you already put into this, but I'll be up to
working on an implementation over the weekend, including tonight and
tomorrow.

Jacob Santos