WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#7479 closed defect (bug) (fixed)

Title missing from new get_plugin_data()

Reported by: strider72 Owned by:
Milestone: 2.7 Priority: normal
Severity: normal Version: 2.7
Component: Administration Keywords: plugins has-patch commit dev-feedback
Focuses: Cc:

Description

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.

Attachments (3)

7479_plugin_data_title_field.diff (926 bytes) - added by strider72 7 years ago.
Adds title back to get_plugin_data
7479.diff (6.4 KB) - added by DD32 7 years ago.
7479.2.diff (6.2 KB) - added by DD32 6 years ago.
patch refresh

Download all attachments as: .zip

Change History (17)

@strider727 years ago

Adds title back to get_plugin_data

comment:1 @strider727 years ago

  • Keywords has-patch added

comment:2 follow-up: @DD327 years ago

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

comment:3 @DD327 years ago

  • Version set to 2.7

comment:4 in reply to: ↑ 2 @strider727 years ago

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.

comment:5 @strider727 years ago

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.

comment:6 @santosj7 years ago

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.

comment:7 @DD327 years ago

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.

@DD327 years ago

comment:8 @jacobsantos6 years ago

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

comment:9 @strider726 years ago

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!

comment:10 @DD326 years ago

  • Keywords commit dev-feedback added

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

comment:11 @ShaneF6 years ago

+1, looks good for right now.

comment:12 @ryan6 years ago

Patch needs a refresh.

@DD326 years ago

patch refresh

comment:13 @ryan6 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:14 @strider726 years ago

Thank you ryan. :)

Note: See TracTickets for help on using tickets.