Wordpress -> WordPress breaks quotations

[toscho]

Today a default filter was committed that changes misspelled WordPress in 'the_content', 'the_title', 'comment_text': ​http://core.trac.wordpress.org/changeset/14996

This breaks quotations containing the misspelled name.

An example: In ​http://toscho.de/2010/wordpress-cms/ I quote someone else who uses the lower »p«, and some comments address this. The now introduced filter damages the conversation (in many blogs; this is a common topic).

So my request is: Either fix this filter to change »Wordpress« outside of quotations only or remove it from the default list.

Also it should still be possible to write:

It’s WordPress not Wordpress.

[nacin]

Hah, this was filosofo's initial (joke) reaction.

This has been running on wordpress.com for more than two years. It is a filter and filters can be removed.

With the changeset, perhaps this will now be a less common topic?

[matt]

For preserving historical mistakes I recommend using the HTML entity for the lowercase letter p, which I can't find right now. There's also probably a way to trick it with unicode, invisible spaces, or cats. It is impossible for the function to be perfect, and its cost goes up with any attempt, so we have to embrace the imperfection of it, as with life.

(I realize that's a funny thing to say when talking about a function whose goal is to correct an imperfection itself.)

[ocean90]

Wordρress
Wordṗress
Wordｐress

:)

[toscho]

My main problem is: It is altering the meaning of existing posts. This should never happen.
So put it into a plugin – this would be a perfect replacement for the Hello Dolly demo. Or check at least if the filtered content is newer than this filter. The current implementation is just rude – which is not the WordPress way, I hope. :)

[matt]

If you feel like the meaning of your posts has been altered, then you should definitely write a plugin to either disable the filter or, as you suggest, selectively enable it based on certain criteria, like the post or comment date. (Clever idea.) In the countless thousands of posts I've read about WordPress, though, what you describe is an edge case, which we generally treat as plugin territory. We face the same challenges with Texturize and AutoP (which has nothing to do with the P in WordPress).

[Denis-de-Bernardy]

I'm re-opening this, because it breaks links with Wordpress in them. And it adds a useless filter that adds CPU cycles. Not to be a tree hugger, but... actually yeah, I actually am a tree hugger and this is completely useless code.

[nacin]

It only changes links with 'Wordpress' in them, with the capital W. All we're doing is then capitalizing the P at that point.

As previously stated, this has been running on wordpress.com for 25 months with no problems, and it's a very light filter. Suggesting re-close as wontfix.

[Denis-de-Bernardy]

Yes, well, if WP.com wants to be a contributor to new deep-sea oil wells, it's their problems.

As far as I'm concerned, with a disaster worse than Exxon Valdez off of the shore of the Mexican coast, how can we possibly be adding unnecessary CPU cycles to WP? If you want this fixed across the board, replace the hello.php plugin with something more "useful" such as this, but do *not* make the problem worse by requiring more deep water drilling. Else you're asking for PR trouble, and I can guarantee you I *will* blog about about it.

[Denis-de-Bernardy]

s/Mesican/Gulf of Mexico/ even. But you got the point.

[johnonolan]

*tumbleweed*

[matt]

It works in practice, but not in theory.

[Denis-de-Bernardy]

What do you mean by in practice but not in theory? It's completely useless code, whose only purpose is "marketing" in spite of the fact that everyone knows WP. You don't need this in the code base, and it *does* mindlessly break old posts -- not to mention links -- as a result.

[johnjamesjacoby]

I don't understand how adding this filter kills trees, or prevents you from hugging them?

[hakre]

IMHO there is no reason at all to have this in core code. It speaks for itself that no ticket has been created to introduce it. If you want to look this project being driven by the work of one-eyed cretins, then you obviously need to leave that in.

I have written statements by automattic that do far more speak clearly about what this is about: forcing the softwares users into Matts marketing sprak.

Replying to nacin:

As previously stated, this has been running on wordpress.com for 25 months with no problems, and it's a very light filter. Suggesting re-close as wontfix.

That statement by Nacin is wrong. It definitely breaks things, WP.COM staff knows that. WP.COM has no intentions to change this for obvious (political) reasons.

Their own reasons weight higher then their users interests. For WP.COM that might be totally okay and covered by TOS, but for .org there is something really wrong-going in this free and open source project. But that only as a side-note for those who would actually like to make their mind about this.

Forever eliminate 'Wordpress' from the planet (or at least the little bit we can influence). props matt.

Wouldn't it be far more wise Matt, if you step a bit back and just get it removed again? For sure, there are many little boys dreaming of supremacy, but I ever thought you didn't want to count yourself into that group. At least a bit more flexible.

[azaozz]

Oh, the length people would go taking something out of context and applying different conspiracy theories to it... Don't get me wrong, I'm a fan of some of the conspiracy theories too but that is what they are - theories :)

Related tickets:

#7810

​http://core.trac.wordpress.org/ticket/9798#comment:9

​http://core.trac.wordpress.org/ticket/9798#comment:18

[hakre]

Replying to azaozz:

Oh, the length people would go taking something out of context and applying different conspiracy theories to it...

Please write down what you think people would to take out of context. I do not understand your comment.

[hakre]

Just to have this noted here: This might have some legal implications over here in germany (and maybe worldwide as well) as a good friend of mine just pointed to me. Until this is not further clarified and to be on the safe side, you should not deploy 3.0 on servers w/o written consent of all of the blogs authors to gain allowance to automatically alter posts their existing (and future) posts.

Keep in mind that this is the same for using the auto-update function.

[dd32]

consent of all of the blogs authors to gain allowance to automatically alter posts their existing (and future) posts.

Please be advised, That WordPress already does, and always has modified the content of blog postings through the use of the various filters applied to post content, Including shortcodes, Linking, autop and texturize, All these functions vary in their output every release. Due to people ability to remove or modify these filters, This wouldn't affect the release status of WordPress 3.0.

Anyone concerned can use ​a plugin to remove the functionality of the Wordpress conversion, Just as you'll find plugins to disable Autop and Texturize.

[hakre]

Replying to dd32:

consent of all of the blogs authors to gain allowance to automatically alter posts their existing (and future) posts.

Please be advised, That WordPress already does, and always has modified the content of blog postings through the use of the various filters applied to post content, Including shortcodes, Linking, autop and texturize, All these functions vary in their output every release. Due to people ability to remove or modify these filters, This wouldn't affect the release status of WordPress 3.0.

The change discussed here is of different quality by changing the posts content w/o the intend of the user. That makes the difference. So this is more about the meaning of change then the technical side of it.

Shortcodes for example as well as the other stuff you noted are methods of input. That's something different because it's used by the author to write.

Chaning complete words because it fits better for Matt naturally something different.

Anyone concerned can use ​a plugin to remove the functionality of the Wordpress conversion

Can you please point to the place where to find that plugin in the repository? I think this would be helpfull for wordpress 3.0 users.

[hakre]

Okay I just saw that the plugin is already linke. Let's make that more Prominent maybe:

​Remove Wordpress to WordPress filter (WordPress Plugin; ​direct ZIP link)

[hakre]

Related: #13971

[hakre]

Related to violating coding standard function naming: #12519

[miqrogroove]

Could we please filter all instances of "wp-content" so that they are "WP-Content" from now on? It would make upgrading so much easier...

[Denis-de-Bernardy]

Replying to miqrogroove:

Could we please filter all instances of "wp-content" so that they are "WP-Content" from now on? It would make upgrading so much easier...

Err, no. That sounds like plugin material.

*grin*

[toscho]

Changeset ​http://core.trac.wordpress.org/changeset/15377 fixes some problems, but the quotation issue is still open. Quoted text should never be altered. I’m not sure how to do this without affecting performance …

[markjaquith]

This is an edge case. If you're doing meta discussion about this particular misspelling, you'll have to do something to confound the filter. Like Word<span>press</span>. Or you can install a plugin that removes the filter.

It's also worth noting that "quote" has always been altered by WordPress — the quotes are curled! If you don't want that to happen, you have to use " to force straight quotes or install a plugin to remove WordPress' default filters.

[chipbennett]

Apparently, *everything* is an "edge case".

Users should not have to jump through hoops to prevent WordPress from making un-desired editorial changes to content.

And before it gets used again: let us dispense with the canard that texturize is in any way analogous. Changing a quote to a curly quote is a *cosmetic* change. Changing -- to an emdash is a *cosmetic* change. Changing ... to an ellipsis is a *cosmetic* change. All of these changes *preserve* user intent.

Changing spelling and/or capitalization is an *editorial* change. Such a change *alters* content from that which the user intended.

Argue editorial changes on their own merits; just don't try to equate them to cosmetic changes.

[nacin]

Replying to chipbennett:

All of these changes *preserve* user intent.

Couldn't have said it better myself. The user's intent, whether they know it or not, is to write WordPress, not Wordpress. For the rare instance where that is *not* the intent, then it is an edge case (complete with workaround) just like other cosmetic changes in texturize.

[chipbennett]

Replying to nacin:

Replying to chipbennett:

All of these changes *preserve* user intent.

Couldn't have said it better myself. The user's intent, whether they know it or not, is to write WordPress, not Wordpress. For the rare instance where that is *not* the intent, then it is an edge case (complete with workaround) just like other cosmetic changes in texturize.

You absolutely cannot assume user intent with respect to editorial changes. Further, it is rather the epitome of hubris to dictate to the user what his intent is, "whether they know it or not".

I think it is a lack of understanding of this point that contributes to the disconnect between the outspoken opposition to this function from many in the community, and the adamant support of it by some of the core development team.

[JohnONolan]

I'm sorry but that's just not true, we absolutely can assume user intent with respect to editorial changes in this circumstance. The word is WordPress, that is the correct and trademarked name. It should always be written as WordPress, there is no alternative correct way to write it. The only time that you would not want to write WordPress would be to demonstrate the incorrect writing of the word which, as Nacin has already said, is an edge case.

For the record this isn't adamant support for anything at all, it's just stating the facts.

[strider72]

Replying to JohnONolan:

The word is WordPress, that is the correct and trademarked name. It should always be written as WordPress, there is no alternative correct way to write it.

Aha. Perhaps then we should alter the filter so it changes "Wordpress" to "WordPress™" ? Seeing as you're doing it to protect trademark and all....

[strider72]

See... here's the problem with the "trademark" argument:

I might write in my blog: "Slap a band-aid on it." Yes, that is incorrect use of the Band-Aid brand, but despite the fact that their lawyers would much prefer me to write "Slap a Band-Aid™ Brand Adhesive Bandage on it", it is my blog and my writing, not Johnson & Johnson's. It's simply not their decision to make.

[JohnONolan]

I mentioned the fact that it was trademarked in passing, to signify the official spelling of the word. Move on.

[chipbennett]

Replying to JohnONolan:

I'm sorry but that's just not true, we absolutely can assume user intent with respect to editorial changes in this circumstance.

No, you cannot. Period. End of story. Only the *user* gets to define his intent.

If you were at *all* concerned with helping the user, this capitalization correction would exist as a spell-check rule. As implemented, it merely exists to scratch a pedantic itch.

The word is WordPress, that is the correct and trademarked name.

Utterly and completely irrelevant. Trademark has nothing to do with this discussion, or with the capital_P_dangit filter.

It should always be written as WordPress...

That's not your call to make. Remember: free software. The developer's intent is irrelevant. Only the user's intent matters. If the user writes "Wordpress" the software should not filter that content to output "WordPress", just because the developer believes that it "should always be written" that way.

there is no alternative correct way to write it. The only time that you would not want to write WordPress would be to demonstrate the incorrect writing of the word which, as Nacin has already said, is an edge case.

Ironically, this filter itself is creating another, very-likely scenario: mis-capitalizing "WordPress" as a form of protest.

For the record this isn't adamant support for anything at all, it's just stating the facts.

What facts?

[chipbennett]

Replying to JohnONolan:

I mentioned the fact that it was trademarked in passing, to signify the official spelling of the word. Move on.

If we should just "move on", then why keep bringing up the irrelevant trademark argument? Don't bring it up, and we won't keep shooting it down.

[azaozz]

It seems that 7-8 people have been very vocal in trying to persuade the rest that this filter is "evil" :-) (yes, the bulk of the comments both here and on wp-hackers are from the same few people). However the main argument used seems misleading.

This filter does not change user content or the meaning of it. Grammatically the word "WordPress" in a name (whether trademarked or not). All text editing software would capitalize names correctly by default if the user mistypes them.

This filter has been available to millions of WordPress users for a long time. Adding it in core makes it available to all users. I'm sure almost everybody has had an accident where a spelling mistake has caused them embarrassment, grief, loss of reputation or even larger problems.

Why would the opponents of this filter want to deny the benefit it brings to so many WordPress users?

[chipbennett]

Please note: I do not believe I have ever associated the term "evil" with the capital_P_dangit filter. I merely have stated that it was a wrong decision to add it to core. (The closest I've come to such rhetoric is to state that editorial changes to user content without user notification or approval is contrary to the principles and definition of free software, as defined by GNU.)

Changing capitalization *is* an editorial change to user content. The relative severity/impact of the change does not alter the nature of such change - and it is the editorial (as opposed to cosmetic) nature of the change that is important. No text-editing software would change the capitalization of a word without notifying the user (and asking permission). If it did so, the action would be reversible.

Neither of these criteria apply to the current filter.

Many things *could* be put into core, to be available to millions of users. Normally, such inclusion is driven by established demand from the user community. The functionality represented by this filter has been requested by barely 300 users in almost three years.

Thus, one can reasonably conclude that this filter represents an extreme edge case. In all other analogous edge cases, the functionality is deemed "plugin territory". No reasonable justification has been presented for why this otherwise "plugin territory" edge case should have been added to core.

[nacin]

Replying to chipbennett:

Normally, such inclusion is driven by established demand from the user community. The functionality represented by this filter has been requested by barely 300 users in almost three years.

Yes, but that's not always a valid indicator. Those who recognize that plugin's need and purpose (and seek it out, and download/install it) already have the knowledge and muscle memory to type "WordPress" properly. Ergo, 300 downloads.