Title missing from new get_plugin_data()

[strider72]

As of WP 2.6, get_plugin_data() returns a string called "Title" in the array -- a link to the plugin's homepage, with the plugin name as the link text.

In 2.7 bleeding, that information is missing from the array returned by the "new improved" function. Although the plugin page doesn't use it any more, it should be retained for backwards compatibility -- some plugins use it directly.

[strider72]

Adds title back to get_plugin_data

[DD32]

Hm..

IMO, Maybe just return 'Name' and 'Title' as the same thing.. Else we might as well revert moving the display data entirely, Which would cause issues with Translations.. But would mean no code duplication..

Can you give an example of a plugin which is using it directly?

I'm thinking:

• For backwards compat: return 'Title' and 'Name as the exact same string, with no formatting applied at all
• Encourage any plugins which need to utilise that to do the Formatting/sanitization themselves & to support Plugin meta data translations.

(And i knew there was something i forgot to mention when i wrote up that diff..)

[strider72]

Replying to DD32:

Can you give an example of a plugin which is using it directly?

Well, any of my own, plus some made by people following the suggestions in ​this article (which, yes, I wrote). I have seen other plugins following that article, including some by Frank Beultge (sp?) and Ozh.

I'm thinking:

• For backwards compat: return 'Title' and 'Name' as the exact same string, with no formatting applied at all

If you change it, is it really "compatibility"? I really like that you all decided to make Plugin URL a separate field, but why is it a problem to leave in the one more (Title) field as it was?

• Encourage any plugins which need to utilise that to do the Formatting/sanitization themselves & to support Plugin meta data translations.

Speaking of which, I could use an example of how authors should use the l18n Plugin headers. Is there some sort of automation? (Yeah, I know, different topic. You brought it up. ;-)

(And i knew there was something i forgot to mention when i wrote up that diff..)

Notably, the documentation in the comment above the function _does_ say that Title is returned. So either we put Title back or we remove it from the doc.

Overall, I understand how you might see this as "no big deal", but this to me is a perfect example of the reason so many people complain about WordPress's "upgrade cycle" -- having to constantly rework plugins to keep up with unnecessary changes to core. It's minor, but it's unnecessary, and it adds up.

(Notably, I originally was going to write that article doing the link manually, but the function at the time didn't return _just_ the Plugin URL.)

Please don't change the existing output of a function unless there is a solid reason to do so.

[strider72]

In the interest of following official WordPress coding standards, the {} brackets should be removed from the if() clause.

I'll update the patch this evening if nobody else does so.

[santosj]

Strider is correct that backwards compatibility should be maintained. I don't exactly see the purpose to what Strider is doing, but my opinion doesn't count and is unimportant.

The plugin display doesn't use the title, so we can keep it untranslated for the plugins and they can work translation using the other bits.

You can find a ​write-up of the feature at my blog.

[DD32]

Ah.. I forgot about the plugins which use it for their footers.

• Attached patch moves the Markup/Translation/Sanitization to a new function.
• Default action is to apply markup and translation at the point of get_plugin_data()
• get_plugins() tells get_plugin_data() NOT to apply markup & translations, This is to allow get_plugins() to operate with the plugin upgrader and allows the data to be cached
• plugins.php calls the markup/translation/sanitization on each plugin after retrieving data from get_plugins.

[jacobsantos]

Patch is pretty bad ass. I wonder if it can be committed.

[strider72]

IS this going to be committed for 2.7? It's such a minor fix, but it _will_ goof up existing plugins if this isn't fixed! The patch is here!

[DD32]

It'd be nice to either get this in, Or close as wontfix in the near future.

[ShaneF]

+1, looks good for right now.

[ryan]

Patch needs a refresh.

[DD32]

patch refresh

[ryan]

(In [9272]) get_plugin_data() back compat fixes from DD32. fixes #7479

[strider72]

Thank you ryan. :)