Make WordPress Core

Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#16751 closed enhancement (fixed)

phpdoc breaks plugins in WP 3.1

Reported by: miqrogroove's profile miqrogroove Owned by:
Milestone: 3.1.1 Priority: normal
Severity: normal Version: 3.1
Component: Plugins Keywords: has-patch
Focuses: Cc:

Description (last modified by dd32)

As of #15193, some plugin header styles such as those used here fail to parse correctly (Specifically, @author: Blah)

Ideally, we should support PHP-Doc style comment structures for plugin headers as well as the "standard" style.

Attachments (1)

unhose-plugin-phpdoc.patch (565 bytes) - added by miqrogroove 13 years ago.
Allow phpdoc in php files

Download all attachments as: .zip

Change History (26)

#1 @duck_
13 years ago

I believe miqrogroove is referring to docblock style @ headers, e.g. http://plugins.trac.wordpress.org/browser/simple-shortlinks/trunk/shortlinks.php#L12

See #15193.

#2 @scribu
13 years ago

docblock style works.

Last edited 13 years ago by scribu (previous) (diff)

#3 @scribu
13 years ago

  • Keywords reporter-feedback added

Please give a specific example of a plugin that isn't recognized anymore.

@miqrogroove
13 years ago

Allow phpdoc in php files

#4 @miqrogroove
13 years ago

If it were up to me I'd revert [16215]

I've attached a patch that will allow phpdoc "docblock style @ headers" as duck_ put it.

And of course you guys could just make me revise all my plugins.

#5 @miqrogroove
13 years ago

  • Keywords reporter-feedback removed

Patch tested in version 3.1. It works if you want it.

#6 @scribu
13 years ago

I downloaded the shortlinks.php file duck_ linked to and it works.

Again, give a specific example.

#7 @scribu
13 years ago

  • Keywords close added
  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Ah, you mean you expect @author to be recognized as a plugin header too.

Sorry, but that was never intended functionality. The header name is 'Author'.

#8 @miqrogroove
13 years ago

okie dokie. Back to version 2.9.

#9 @scribu
13 years ago

  • Keywords 2nd-opinion has-patch added; close removed
  • Milestone set to Awaiting Review
  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Type changed from defect (bug) to enhancement

Not that your switch back to WP 2.9 caused me to change my mind, but I guess we can consider this, as an enhancement.

#10 @scribu
13 years ago

  • Summary changed from Plugins Don't Work in WP 3.1 to Allow phpdoc style headers in plugins and themes

#11 @scribu
13 years ago

(note the difference between an inflammatory title and an accurate one)

#12 @miqrogroove
13 years ago

As long as my plugins don't work in WP 3.1, I'll be as inflammatory as I like. It's a fact that I'm caught between ignoring support complaints or finding time I don't have to maintain this code. My first inclination is to submit the one-line patch and avoid the hassle.

#13 @miqrogroove
13 years ago

  • Summary changed from Allow phpdoc style headers in plugins and themes to phpdoc breaks plugins in WP 3.1

#14 @nacin
13 years ago

  • Keywords 2nd-opinion removed
  • Milestone changed from Awaiting Review to 3.1.1

#15 follow-up: @scribu
13 years ago

What exactly do you mean by "don't work"?

Do you use a @plugin name header? Because that's the only case that would cause serious problems that I can think of.

Last edited 13 years ago by scribu (previous) (diff)

#16 in reply to: ↑ 15 @miqrogroove
13 years ago

"Don't work" means I have a confirmed defect in the plugins screen of the dashboard.

No I do not use a @plugin name header.

#17 follow-up: @dd32
13 years ago

  • Description modified (diff)

"Don't work" means I have a confirmed defect in the plugins screen of the dashboard.

In the future, mentioning the actual problem in the description is best practice, and attacking developers for changing something is not ideal either. Had you have tested 3.1, or any of your plugin users had tested 3.1, it would've been identified at the time and fixed.

As it is, The problem is that @ is unexpected input, and does not fit with the WordPres "standard" plugin header, whilst the plugin still "Works" it's just the author details are not read correctly, That being said, That style of headers is something worth while supporting, as it is, a very small percentage of plugins use it, which explains why it was missed in the testing.

#18 @hakre
13 years ago

Thanks for reporting and providing the patch. A very helpful, non-invasive enhancement. Good luck with your userbase!

Patch looks good to me.

#19 in reply to: ↑ 17 ; follow-up: @miqrogroove
13 years ago

Replying to dd32:

In the future, mentioning the actual problem in the description is best practice

No, I actually did that, whereas your edited version of the ticket makes it look like I'm whining about my name not showing up on my plugins, which is not the reason I reported my plugins don't work in 3.1. As usual, nobody at WordPress is even willing to acknowledge a mistake that needs to be patched and you guys are more concerned with telling me that I filed the ticket wrong.

#20 in reply to: ↑ 19 ; follow-up: @nacin
13 years ago

Replying to miqrogroove:

Replying to dd32:

In the future, mentioning the actual problem in the description is best practice

No, I actually did that, whereas your edited version of the ticket makes it look like I'm whining about my name not showing up on my plugins, which is not the reason I reported my plugins don't work in 3.1. As usual, nobody at WordPress is even willing to acknowledge a mistake that needs to be patched and you guys are more concerned with telling me that I filed the ticket wrong.

Chill. You're beginning to sound like hakre. Bemoan all you want, but before you said that, I already moved the ticket to 3.1.1.

Side note, is @author: (with the colon) valid phpdoc syntax?

#21 @miqrogroove
13 years ago

phpxref parses the extra colon like "Version: : 1.0.14". It's not ideal but it's readable.

#22 @markjaquith
13 years ago

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

(In [17516]) Make plugin header parsing slightly more liberal (like it was in 3.0), to allow for PHPdoc style headers. props miqrogroove. fixes #16751 for trunk

#23 @markjaquith
13 years ago

(In [17517]) Make plugin header parsing slightly more liberal (like it was in 3.0), to allow for PHPdoc style headers. props miqrogroove. fixes #16751 for 3.1

#24 @miqrogroove
13 years ago

Hurrah!

Thanks Mark :)

#25 in reply to: ↑ 20 @hakre
13 years ago

Replying to nacin:

Replying to miqrogroove:

Replying to dd32:

In the future, mentioning the actual problem in the description is best practice

No, I actually did that, whereas your edited version of the ticket makes it look like I'm whining about my name not showing up on my plugins, which is not the reason I reported my plugins don't work in 3.1. As usual, nobody at WordPress is even willing to acknowledge a mistake that needs to be patched and you guys are more concerned with telling me that I filed the ticket wrong.

Chill. You're beginning to sound like hakre. Bemoan all you want, but before you said that, I already moved the ticket to 3.1.1.

*ouch* (#16464, #16717)

Note: See TracTickets for help on using tickets.