WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#13971 closed defect (bug) (fixed)

"Wordpress" being turned into CamelCase "WordPress" breaks URLs

Reported by: tfotherby Owned by:
Milestone: 3.0.1 Priority: normal
Severity: normal Version: 3.0
Component: Formatting Keywords:
Focuses: Cc:

Description

I have a image called "WordpressLogo_blue-m.png" in one of my posts: http://www.bitvolution.com/wordpress-image-gallery-plugin and it has broken since I upgraded to v3.0.

The image is broken because WordPress is renaming it to "WordPressLogo_blue-m.png" - i.e. WordPress is auto camelcasing "Wordpress" to "WordPress" (note the uppercase 'P').

I also tested this in the lastest 3.1-alpha version.

I wouldn't mind too much because I agree it is my fault I have spelt Wordpress incorrectly. However, for resources like images, it is not easy to change the filename so I think the automatic renaming should be disabled?

Attachments (6)

13971.diff (1.1 KB) - added by nacin 4 years ago.
From MarkJaquith
remove-capital-Wordpress.diff (1.8 KB) - added by greenshady 4 years ago.
Patch to deprecate the capital_P_dangit() function and remove the filters on text
13971-more-judicious.diff (1.9 KB) - added by markjaquith 4 years ago.
13971-more-judicious.002.diff (1.4 KB) - added by markjaquith 4 years ago.
13971-cdata-content.diff (1.6 KB) - added by dougal 4 years ago.
Generic mechanism for applying filters only to 'CDATA' text, and not to HTML elements, with specific application to the capital_P_dangit problem.
13971-spaces.diff (429 bytes) - added by dangayle 4 years ago.

Download all attachments as: .zip

Change History (113)

comment:2 tfotherby4 years ago

The workaround is to install this plugin:

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

comment:3 follow-up: hakre4 years ago

It's a Bug, not a Feature.

Related: #13583

comment:4 in reply to: ↑ 3 tfotherby4 years ago

Replying to hakre:

It's a Bug, not a Feature.

  • To upgrade a existing working WordPress installation and have images broken is a bug to me.
  • Having a "correct filename" changed to "incorrect filename" is a bug to me.

I think the filter should only apply to new posts so that at least the author will be able to use "preview" to know that they have broken images.

Also, how can I rename the image file using the WordPress admin interface without deleting the image and re-uploading it with the new name?

comment:5 mrmist4 years ago

Also see #13987

I've been watching this with curious interest since #13583

It does seem that this addition causes unnecessary annoyances whilst not really adding core benefit. Surely this should be the plugin, rather than people having to add a plugin to remove it?

There's a lot of talk around what should sit in plugin land and what shouldn't, and I very much feel that were not Matt behind this one, there could be no justification for it being part of core.

comment:6 mrmist4 years ago

  • Milestone changed from Unassigned to 3.0.1

See also http://wordpress.org/support/topic/411617?replies=30#post-1559585

This is not an isolated incident, it's starting to affect many users.

comment:7 zeo4 years ago

Revert or improve [14996]?

comment:8 follow-up: dd324 years ago

A possible alternative:

$in = 'wordpress test.com/file-wordpress-test.jpg"> Test wordpress "!Wordpress" </a> <span>Wordpress</span>'; 

$out = preg_replace('!(^|[ >"\'])wordpress\b!i', '$1WordPress', $in); 

var_dump($out);
string 'WordPress test.com/file-wordpress-test.jpg"> Test WordPress "!Wordpress" </a> <span>WordPress</span>' (length=100)
}}

comment:9 in reply to: ↑ 8 toscho4 years ago

  • Cc toscho added

Replying to dd32:

A possible alternative:

This is way to slow. I’m with mrmist: Put the spell changing into a plugin, keep the core backwards compatible.

comment:10 dd324 years ago

This is way to slow.

By what standard? Compared to the other expressions run on the content?

comment:11 toscho4 years ago

Not compared but in addition to the other regexes. We had already problems with regexes on long posts. Introducing new ones for something that don’t even fixes a real bug and runs on every post ever published is not efficient, imho.
There has to be a better solution. Moving the filter to a plugin seems to be the best option.

comment:12 johnbillion4 years ago

  • Summary changed from Problem due to "Wordpress" being turned into CamelCase "WordPress" in a image name to "Wordpress" being turned into CamelCase "WordPress" breaks URLs

What an incredibly ill thought out and pointless changeset [14996] was. If only I'd seen that changeset at the time I would have opened a ticket to point out the problems it causes.

In addition to src URLs in <img> tags, this breaks links where the URL contains 'Wordpress'. That has the potential to be just as widespread an annoyance as the <img> problem, not only for outbound links but also for anyone who installed WordPress in a 'Wordpress' directory.

Recommending that [14996] is reverted rather than wasting time on a regex.

comment:13 miqrogroove4 years ago

+1 revert ASAP

comment:14 sirzooro4 years ago

  • Cc sirzooro added

+1 for reverting this too.

comment:15 follow-up: markjaquith4 years ago

There's a lot of talk around what should sit in plugin land and what shouldn't, and I very much feel that were not Matt behind this one, there could be no justification for it being part of core.

This was run past the other leads. I brought up the argument that this might break a great many links. Matt said that they'd been running it on WordPress.com for several years with, I believe, only one recorded instance of it breaking anything. That satisfied me that this reported bug would occur infrequently.

However, what if, instead of a regular expression, with its speed and complexity concerns, we do three search/replace pairs (explicitly running the filter on priority 11):

" Wordpress" => "WordPress" — that is, {SPACE}Wordpress to {SPACE}WordPress. That should eliminate all URL/src false positives.

">Wordpress" => ">WordPress" — which should get the HTML-wrapped or beginning-of-paragraph uses.

"&#8220;Wordpress" => "&#8220;WordPress" — which should get all instances of WordPress at the beginning of a double quote.

Using those three replacements should greatly decrease our false positives.

comment:16 Ipstenu4 years ago

Revert or apply Mark's fix in the inevitable 3.0.1 bugfix.

comment:17 mrmist4 years ago

Mark's idea would seem to address most of the user-facing issues that I've read about. The side issues I'm not overly concerned with.

comment:18 miqrogroove4 years ago

{SPACE}WordPress. That should eliminate all URL/src false positives.

It's going to fix installations in /Wordpress/ but is incorrect to say that it wont break URLs. href="http://www.mydomain.com/My Wordpress Essay.pdf" will never work with this junk in core.

comment:19 in reply to: ↑ 15 johnbillion4 years ago

Replying to markjaquith:

That satisfied me that this reported bug would occur infrequently.

Why introduce a completely pointless feature that introduces any bug at all, irrespective of how frequently or infrequently it'll occur? I agree that it's not going to happen often, and it's not a major bug, but it's an annoyance for those users who do experience it.

comment:20 harrym4 years ago

See also #14043, which has a patch.

This filter shouldn't exist at all. Debating how to fix it rather misses the point as far as I'm concerned.

The WP core has no business enforcing editorial style on blog authors.

+1 revert asap.

comment:21 Denis-de-Bernardy4 years ago

+1 to save CPU cycles by reverting asap.

comment:22 hakre4 years ago

+1 to revert ASAP as well.

comment:23 shidouhikari4 years ago

I'd agree with it if the function was on core and there was a checkbox in an admin page to enable filtering.

But why can't plugin developers add links to their plugin sites with option to disable the link and option checked by default, and Wordpress can filter its name forcing us to use PHP code to disable it, without even a checkbox to be unchecked?

comment:24 follow-ups: JDTrower4 years ago

-1 to reverting. I think most people here who are pushing to reverting this is forgetting one thing; WordPress is a registered trademark. It happens to be registered by Automattic Inc. As such that company has the legal right to enforce proper usage of their trademark, which includes the capital 'P'. Failure to do so, results in the watering down of the trademark. Look at Kleenex for example, Kleenex is officially a registered trademark, but common usage of that word, has watered that trademark down because everyone uses the work Kleenex to refer to any tissue paper, not just Kleenex tissue paper.

Automattic, desiring to protect their trademark, which they have the right to do, has chosen to add a filter to the WordPress software that enforces correct capitalization. I agree that to help prevent most of the false positives, that Mark's proposed fix above should be implemented, but I disagree with the reverting of this. What I personally disagree with is those that are going to remove the filter to prevent proper capitalization of WordPress. That just perpetuates the incorrect capitalization, which only serves to waterdown the trademark.

I'm curious to know why the stark opposition to the enforcement of a trademark. Personally, I think this is the right step, because it helps enforce the trademark, and hopefully through this, other journalists and other non-WordPress users will use the correct capitalization as well.

comment:25 miqrogroove4 years ago

Health check:

SELECT * 
FROM wp_posts
WHERE post_content COLLATE utf8_bin LIKE '%Wordpress%'

comment:26 in reply to: ↑ 24 Denis-de-Bernardy4 years ago

Replying to JDTrower:

-1 to reverting. I think most people here who are pushing to reverting this is forgetting one thing; WordPress is a registered trademark. It happens to be registered by Automattic Inc.

I think you're forgetting there's a WP foundation, that WP != Automattic (in theory anyway), and that at the end of the day it's my business if I want to spell it Wordpress.

Oh, and it wastes CPU cycles, too. Recall they're drilling in the Gulf due to this kind of wasteful PR-related code.

comment:27 in reply to: ↑ 24 harrym4 years ago

Replying to JDTrower:

[...] As such that company has the legal right to enforce proper usage of their trademark [...]

That's utter nonsense. Trademarks do not confer any right to dictate people's spelling.

comment:28 holizz4 years ago

  • Cc tom@… added

comment:29 in reply to: ↑ 24 holizz4 years ago

Replying to JDTrower:

I'm curious to know why the stark opposition to the enforcement of a trademark.

This isn't enforcement of a trademark. Enforcement of a trademark is through the courts (or at least a threat to take somebody to court). And as much as I think the legal system is broken, I think attempting to enforce the law through software is even more misguided. Here's an example: I may like to tell people "it's not spelt Wordpress, it's spelt WordPress" - I wouldn't be able to tell people that using Wordpress - so now Wordpress is a tool of censorship that doesn't allow discussion of alternate spellings. I would also be prevented from intentionally un-camelcasing as an act of civil disobedience.

comment:30 GautamGupta4 years ago

IMO, After the Deadline should be added instead of the default spell checker. It recognizes the "Wordpress" error.

comment:31 harrym4 years ago

  • Cc harrym added

We should resolve this one way or the other, right?

Seems to be a balance here in favour of removing. Including from core devs. It would be good to get an opinion from Matt if that's the only thing that's holding us back!

comment:32 demetris4 years ago

  • Cc dkikizas@… added

comment:33 markjaquith4 years ago

Automattic, desiring to protect their trademark, which they have the right to do, has chosen to add a filter to the WordPress software that enforces correct capitalization.

The trademark is in the process of being transferred to the WordPress Foundation, which is under Matt's personal direction. So if some day Matt leaves Automattic, the trademark doesn't stay with the company. And this has nothing to do with trademark enforcement. We were just annoyed at how prevalent incorrect capitalization was, and we have the ability to influence that positively.

Seems to be a balance here in favour of removing. Including from core devs.

None of the core committers has expressed a desire to remove.

I wouldn't be able to tell people that using Wordpress - so now Wordpress is a tool of censorship that doesn't allow discussion of alternate spellings. I would also be prevented from intentionally un-camelcasing as an act of civil disobedience.

Oh calm down. It's free/libre software with a hook infrastructure that makes removing this filter a one-line affair. No one is trampling on your rights.

nacin4 years ago

From MarkJaquith

comment:34 follow-up: nacin4 years ago

  • Component changed from General to Formatting
  • Keywords has-patch commit added

Attached please find MarkJaquith's suggestion in patch form.

comment:35 in reply to: ↑ 34 ; follow-up: Denis-de-Bernardy4 years ago

  • Keywords needs-patch added; has-patch commit removed

Replying to nacin:

Attached please find MarkJaquith's suggestion in patch form.

It has bugs, in that it won't catch sentences that start with WP for instance. And it might still interfere with scripts, object tags, the list goes on... If you want anything truly robust, tags need to be ignored, and then the filter should be applied. This'll needlessly slow down millions of sites for vanity.

comment:36 in reply to: ↑ 35 nacin4 years ago

  • Keywords has-patch added; needs-patch removed

Replying to Denis-de-Bernardy:

It has bugs, in that it won't catch sentences that start with WP for instance.

Note the first thing it looks for -- " WordPress".

If you want anything truly robust, tags need to be ignored, and then the filter should be applied. This'll needlessly slow down millions of sites for vanity.

Like smiles, curly quotes, texturize, special characters?

comment:37 harrym4 years ago

We were just annoyed at how prevalent incorrect capitalization was, and we have the ability to influence that positively.

Yes. *You* were annoyed. And you are free to spell it however you like, and to persuade others when you can.

To use your privileged positions as developers of WordPress to enforce your personal pedantry on people is just rude. I'll say it again: WordPress have no business putting code in the core to force other people to conform to their preferences.

I'm genuinely baffled that any of you think this is reasonable. Who do you think you are?

comment:39 follow-up: Denis-de-Bernardy4 years ago

Note the first thing it looks for -- " WordPress".

I fail to see how a prepended space catches:

Wordpress is spelt WordPress.

Btw, my iPad just tried to autocorrect the camelcase to Wordpress. ;-) I take it the iPhone does as much. Maybe that's where you guys ought to be looking...

comment:40 miqrogroove4 years ago

"Word Press", "Word-Press", and "word-press" are also quite popular. Why not break all of them?

comment:41 follow-up: Denis-de-Bernardy4 years ago

Heh, so are worpress and wordress. There even is a forum tag for the second one:

http://wordpress.org/tags/wordress

comment:42 in reply to: ↑ 41 michaelh4 years ago

Replying to Denis-de-Bernardy:

Heh, so are worpress and wordress. There even is a forum tag for the second one:

http://wordpress.org/tags/wordress

Merged wordress into wordpress tag.

comment:43 in reply to: ↑ 39 ; follow-up: johnbillion4 years ago

Replying to Denis-de-Bernardy:

I fail to see how a prepended space catches:

Wordpress is spelt WordPress.

The filter in the path from Mark is applied after wpautop therefore "Wordpress" at the beginning of a line will always be prepended with ">" (eg "<p>") which is also handled in that patch.

comment:44 sirzooro4 years ago

If you want to use rules which use preceding character, you should also add few new cases:

  • non-breakable space, as HTML entity (&nbsp;), or entity with its dec or hex code;
  • hyphen (e.g. in "non-Wordpress");
  • all other punctuation marks - it is quite possible that someone will not enter extra space between punctuation mark and "Wordpress". Note: case when dot is not followed be space cannot be fixed this ways, because it will break URLs;
  • all kind of braces - some will fall under above category (missing space separator), some because there is no handler for used shortcode.

BTW, I still vote for removing this completely.

comment:45 in reply to: ↑ 43 Denis-de-Bernardy4 years ago

Replying to johnbillion:

Replying to Denis-de-Bernardy:

I fail to see how a prepended space catches:

Wordpress is spelt WordPress.

The filter in the path from Mark is applied after wpautop therefore "Wordpress" at the beginning of a line will always be prepended with ">" (eg "<p>") which is also handled in that patch.

... unless a line break creeps in.

comment:46 ozh4 years ago

Simpler (so maybe faster, for those concerned) regexp that seems to match valid HTML tags:

preg_replace( "/Wordpress(?!([^<]+)?>)/i", "WordPress", $text);

Doesn't work with dd32's example, but works ok with standard stuff like

Wordpress <a href="/bleh/Wordpress" class="link">Wordpress</a> <img src="/img/Wordpress-blue.png" />

comment:47 jestro4 years ago

+1 for reverting. I am baffled and and somewhat appalled that the core devs think this is OK. Without a doubt plugin territory.

comment:48 greenshady4 years ago

+1 for reverting. No need for me to rehash all the reasons why.

comment:49 Utkarsh4 years ago

  • Cc admin@… added

+1 for reverting

comment:50 aesqe4 years ago

  • Cc aesqe@… added

+1 for reverting, this is nonsense

comment:51 nathanrice4 years ago

The filter was introduced in good spirited humor, and without negative intentions. I can appreciate that. But the amusement has no doubt run its course. It's probably time to recognize this for what it was, and then remove it. There are some hills that are not worth dying on.

+1 Revert/Remove

comment:52 husobj4 years ago

I am sure the filter was introduced with good intentions and I quite like the 'idea' of being able to protect the Wordpress (oops WordPress) brand in this way.

I love the humour and personally that surrounds WordPress and it's code - Keep your easter eggs, keep your twentyten theme footer emoticon, keep Hello Dolly...

But I think altering what people have explicitly written is a bad idea. WordPress is a CMS and although this change in itself is no big deal, I think people may dislike the fact that you are in effect dictating what they are allowed to write. If you really really must, by all means flag misspellings to the user somehow (subtly) but please don't tell me what I am and am not allowed to write.

+1 Revert/Remove

comment:53 wet4 years ago

  • Cc r.wetzlmayr@… added

comment:54 ryanhellyer4 years ago

+1 Revert/Remove

Wordpress does not need this in core. If someone wants to misspell something then they should be allowed to IMO.

comment:55 nacin4 years ago

  • Priority changed from normal to lowest

comment:56 strider724 years ago

+1 on revert/remove.

As a matter of principle WordPress should not be editing people's text for them. I'm all for adding it to the spell check, but just silently changing things isn't cool.

comment:57 nkuttler4 years ago

  • Cc office@… added

+1 Revert

Yeah, I have far too much time.

comment:58 follow-up: johnjamesjacoby4 years ago

You can remove this filter just like you can remove the 'pretty quotes' filter. I haven't heard many people complain about WordPress making their punctuation proper in a while.

To me this isn't any different than the iPhone auto-correcting "iphone/iPhone" "ipad/iPad" "imac/iMac".

Mark's patch filters text and doesn't break attachments, so I'm +1 Mark's patch.

The only reason I can think to revert this, is to be able to continue to tell which WordPress "professionals" actually know how to spell the platform they claim to use professionally.

comment:59 mrmist4 years ago

IMO folk shouldn't have to remove this filter, and for those that have had broken site links caused by it, it's a hassle that they should have been able to do without.

It would have been, I think, far better from the PR side of things to bundle this as an included plugin. You could even have taglined it "Support proper WordPress captilization", plus, for non-technical users, it would be obvious how and why you might need to disable it.

That said, if there's a patch ready that solves the actual reported issues on this, I'd rather see that committed than see the status quo prevail amidst bickering over revert discussion.

comment:60 carlhancock4 years ago

+1 for reverting. The CMS shouldn't exert control over editorial content without the writers consent. The iPhone auto-correction is optional, you have a chance to tell it NOT to correct what you are typing. If you want to say iphone instead of iPhone you can. It isn't automatic and doesn't do it without the users consent.

greenshady4 years ago

Patch to deprecate the capital_P_dangit() function and remove the filters on text

comment:61 follow-up: jorbin4 years ago

Keep the filter. I like this feature.

WordPress isn't editing any text. All of the changes are cosmetic and anyone is welcome to remove the filter. Much like curly quotes.

</bikeshedding>

comment:62 in reply to: ↑ 61 tfotherby4 years ago

Replying to jorbin:

Keep the filter. I like this feature.

WordPress isn't editing any text. All of the changes are cosmetic and anyone is welcome to remove the filter. Much like curly quotes.

I disagree - the changes are not just cosmetic, the changes break urls which results in broken images, broken stylesheets, broken page references, broken sitemaps, etc, etc.

comment:63 toscho4 years ago

Mark, could you add a check for quoted text? ‘Wordpress’ inside a quotation shouldn’t be altered too.

comment:64 dougal4 years ago

  • Cc dougal added

I was all ready to ignore this issue as "dontcare" until I realized that it could break URLs. So now I find myself reversing my feelings on it in favor of removing the filter.

However, since all indications are that it *won't* be removed, I can at least offer a patch that might be more robust than the ones I've seen here.

I've got a callback function in my Text Filter Suite plugin that can fix this s. I'll try to whip up a quick patch based on it

comment:65 in reply to: ↑ 58 dougal4 years ago

Replying to johnjamesjacoby:

To me this isn't any different than the iPhone auto-correcting "iphone/iPhone" "ipad/iPad" "imac/iMac".

Except that the iPhone spelling correction gives you that little 'X' every time, providing the option to use your preferred misspelling. Without the need for a plugin.

dougal4 years ago

Generic mechanism for applying filters only to 'CDATA' text, and not to HTML elements, with specific application to the capital_P_dangit problem.

comment:66 dougal4 years ago

I think I hurt my brain reworking my original code to use create_function instead of introducing an intermediate function globally. I'm not happy with how ugly that whole preg_replace_callback->create_function->call_user_func chain looks, but it works and it's generic enough for reuse elsewhere.

With this, you can make filters which only affect 'CDATA' text, and which ignore any content within HTML elements and their attributes.There could be edge cases I'm not aware of, so if anybody wants to give it rigorous testing, I'd welcome feedback.

comment:67 follow-ups: filosofo4 years ago

dougal, I'm concerned about the performance implications of using a couple of lookbehinds and a lambda function to filter something so trivial to begin with, especially on something ubiquitous like the_content and comment_text. Are the possible edge cases it addresses really worth it?

comment:68 markjaquith4 years ago

Even a simple regular expression that does what my str_replace() does is about 20 times slower. Don't think it's worth it for the edge cases.

comment:69 markjaquith4 years ago

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

(In [15377]) More judicious Wordpress-to-WordPress correction, to avoid bungling reasonable URLs. fixes #13971

comment:70 markjaquith4 years ago

(In [15378]) More judicious Wordpress-to-WordPress correction, to avoid bungling reasonable URLs. fixes #13971 for 3.0

comment:71 in reply to: ↑ 67 dougal4 years ago

Replying to filosofo:

dougal, I'm concerned about the performance implications of using a couple of lookbehinds and a lambda function to filter something so trivial to begin with, especially on something ubiquitous like the_content and comment_text. Are the possible edge cases it addresses really worth it?

Oh, almost certainly not. Honestly I think we should just ditch the damned P function. Even with just a nice fast str_replace, I don't think it's worth the hassle. You can keep on adding new test cases to the array of replacements, and somebody will eventually come up with another case we hadn't thought of yet. And as somebody else brought up, there are cross-cultural implications to mucking around with content.

Just because it *can* be worked around, doesn't mean that it should go in.

I'm sure it seemed like a trivial, cute little change when it went in. And if I was on the core team, I'm sure that I wouldn't have predicted the crapstorm that it's caused, either. But I think this is just one 'enhancement' that really should be reconsidered.

If my opinion had any weight, I'd suggest leaving the function in, removing it from default-filters, and just documenting its availability for plugin and theme authors. Another option might be to disable it via a define in wp-config, enabled by default, but visible and documented in the wp-config.php file (e.g., "Uncomment the next line to disable 'WordPress' auto case correction").

comment:72 F J Kaiser4 years ago

  • Cc 24-7@… added

comment:73 in reply to: ↑ 67 dangayle4 years ago

  • Cc dangayle added

Replying to filosofo:

dougal, I'm concerned about the performance implications of using a couple of lookbehinds and a lambda function to filter something so trivial to begin with, especially on something ubiquitous like the_content and comment_text. Are the possible edge cases it addresses really worth it?

Lambda functions in PHP can't be optimized or cached, and can lead to memory issues. Given that this function group would be called on practically every page/query, the performance degradation really should be looked at.

comment:74 chrisbliss184 years ago

So I'm late to the party, but I just have to throw my hat in this discussion. Honestly, I have to say that I'm amazed. Amazed and disturbed by this entire situation. And frankly, it's lowered my opinion of some developers that I have had very high regard for in the past.

As a software developer, I am constantly concerned about making my code as efficient as possible. Why? Because I never know when some poor coding practice will make the difference between someone's server being able to handle the load and complete failure. And it is my responsibility as a coder to ensure that my code doesn't needlessly waste resources.

Let's all be honest with ourselves and admit that this entire situation is silly and highly unnecessary. Some core devs chatted about their dislike of the misspelling and *BAM* in goes code. No concern over bugs (nor of the bug reports). No concern over the efficiency issue. No concern over the freedom of words that Matt talked about in San Francisco. No concern over anything other than personal pet peeves. Frankly, it's unacceptable.

Now some may argue that it is insignificant in the grand scheme of the code stack. True, but it is mighty absurd to add to the execution stack over the need to scratch an itch. Beyond that, it's rude to the community at large to leverage core contributor authority over such trivial matters and an amazing level of arrogance to be so dismissive when genuine issues and complaints come up. On top of that is how we are wasting valuable devs time trying to "optimize" and "improve" such code to not have bugs when its value is nil to begin with.

"It's plugin territory" should be reserved for adding trivial bits of code, not for adding more code to remove the actions of trivial bits of code. "Acceptable edge cases" should be reserved for solving issues that are genuine software or usability issues which has benefit that outweighs the detriment. "Let's stop wasting our time" should be reserved for commentary about adding such trivial code not for commenting on the outcry to remove such trivial code. "It can be removed with one line of code" should only affect developers and not users. Marking a legitimate bug as "fixed" when it has neither been properly addressed nor fixed is also a critical problem.

Citing other filter actions such as autop, et al as justification for such short-sighted actions is absurd. Those filters add what most would agree is benefit to the user. Since most would easily, seamlessly, and without complaint benefit from these filters without a chance of a site-breaking bug, using their existence and general acceptance for justification is irrational.

Since the only benefit of this filter is perceived (the devs who like this and support its inclusion "feel" better about the world due to its existence), the staunch determination to keep the code in spite of the massive backlash is inane. To uphold the inclusion of the code based upon the only justification being "I don't like seeing it spelled that way" is to hold your personal beliefs above those of the other millions of users of WordPress... across the world... regardless of language or technical skill.

The only obvious answer from a software development, project management, public relations, or community management standpoint is to remove it. There simply is no rational reason on any level to keep it, no matter what your opinion or lack of opinion about the spelling of WordPress is.

If WordPress is truly a community project as numerous Automattic employees and core contributers constantly profess, how can it be that things like this (which everyone admits is trivial) which has massive negative community feedback are still so difficult to affect change in. This is the true heart of the issue: the helpless feeling of the community to make even the slighted shift in core contributer opinion on the most trivial of matters. I think it is this central issue that will leave a stain on devs opinion of WordPress, Matt, and core contributers for some time to come.

Can devs and users walk? Surely, but the point is that people don't truly want to walk over something so stupid. At least make it a fight worth fighting.

comment:75 chrisbliss184 years ago

So I'm late to the party, but I just have to throw my hat in this discussion. Honestly, I have to say that I'm amazed. Amazed and disturbed by this entire situation. And frankly, it's lowered my opinion of some developers that I have had very high regard for in the past.

As a software developer, I am constantly concerned about making my code as efficient as possible. Why? Because I never know when some poor coding practice will make the difference between someone's server being able to handle the load and complete failure. And it is my responsibility as a coder to ensure that my code doesn't needlessly waste resources.

Let's all be honest with ourselves and admit that this entire situation is silly and highly unnecessary. Some core devs chatted about their dislike of the misspelling and *BAM* in goes code. No concern over bugs (nor of the bug reports). No concern over the efficiency issue. No concern over the freedom of words that Matt talked about in San Francisco. No concern over anything other than personal pet peeves. Frankly, it's unacceptable.

Now some may argue that it is insignificant in the grand scheme of the code stack. True, but it is mighty absurd to add to the execution stack over the need to scratch an itch. Beyond that, it's rude to the community at large to leverage core contributor authority over such trivial matters and an amazing level of arrogance to be so dismissive when genuine issues and complaints come up. On top of that is how we are wasting valuable devs time trying to "optimize" and "improve" such code to not have bugs when its value is nil to begin with.

"It's plugin territory" should be reserved for adding trivial bits of code, not for adding more code to remove the actions of trivial bits of code. "Acceptable edge cases" should be reserved for solving issues that are genuine software or usability issues which has benefit that outweighs the detriment. "Let's stop wasting our time" should be reserved for commentary about adding such trivial code not for commenting on the outcry to remove such trivial code. "It can be removed with one line of code" should only affect developers and not users. Marking a legitimate bug as "fixed" when it has neither been properly addressed nor fixed is also a critical problem.

Citing other filter actions such as autop, et al as justification for such short-sighted actions is absurd. Those filters add what most would agree is benefit to the user. Since most would easily, seamlessly, and without complaint benefit from these filters without a chance of a site-breaking bug, using their existence and general acceptance for justification is irrational.

Since the only benefit of this filter is perceived (the devs who like this and support its inclusion "feel" better about the world due to its existence), the staunch determination to keep the code in spite of the massive backlash is inane. To uphold the inclusion of the code based upon the only justification being "I don't like seeing it spelled that way" is to hold your personal beliefs above those of the other millions of users of WordPress... across the world... regardless of language or technical skill.

The only obvious answer from a software development, project management, public relations, or community management standpoint is to remove it. There simply is no rational reason on any level to keep it, no matter what your opinion or lack of opinion about the spelling of WordPress is.

If WordPress is truly a community project as numerous Automattic employees and core contributers constantly profess, how can it be that things like this (which everyone admits is trivial) which has massive negative community feedback are still so difficult to affect change in. This is the true heart of the issue: the helpless feeling of the community to make even the slighted shift in core contributer opinion on the most trivial of matters. I think it is this central issue that will leave a stain on devs opinion of WordPress, Matt, and core contributers for some time to come.

Can devs and users walk? Surely, but the point is that people don't truly want to walk over something so stupid. At least make it a fight worth fighting.

comment:76 chipbennett4 years ago

  • Cc chip@… added

comment:77 gazouteast4 years ago

  • Cc gazouteast added
  • Keywords needs reverting added
  • Resolution fixed deleted
  • Severity changed from normal to major
  • Status changed from closed to reopened

@markjaquith "Oh calm down. It's free/libre software with a hook infrastructure that makes removing this filter a one-line affair. No one is trampling on your rights. "

Then please issue a blog post on how to remove it, and and the instructions for doing so to the install instructions for 3.0.1 onwards - and yes, you are trampling on my rights by breaking links in my sites, causing 404 errors that count against me in Google search ranking, thus decreasing my earnings from ecommerce and affiliate marketing based upon WordPress sites.

@nacin "If you want anything truly robust, tags need to be ignored, and then the filter should be applied. This'll needlessly slow down millions of sites for vanity.
'Like smiles, curly quotes, texturize, special characters?' "

Be careful of disparaging special characters - it could be construed as racist against nations whose alphabet is not the Latin one.

@johnjamesjacoby "You can remove this filter just like you can remove the 'pretty quotes' filter. I haven't heard many people complain about WordPress making their punctuation proper in a while. "

Yes - sorry I haven't been on Wp.org for a while, I've been kinda busy - BTW, WHEN are WP / Automattic going to fix the incorrect forced grammar of a single space after the full stop at the end of a sentence? Or, when are they going to provide a proper British Queen's English version of the en_UK files that allow such correct writing styles?

---

Because of the absolute arrogance and distain for users and non-core devs from some heavyweight WP names in the comments above, I add my list as a vehement ...

+1 for Revert

As a professional card carrying journalist I also am +1 for revert - there are times when wordPress / wordpress / Wordpress are legitimate spellings and nothing whatsoever to do with WordPress - particularly in relation to the printed media and literary worlds. This entire issue reminds me of the European Parliament dictating to agriculturalists how much curvature was / is allowed on bananas and cucumbers, or how much the minimum meat-flesh content must be before an item is allowed to be called a sausage.

Trademark protection, as someone above stated, is for the courts, and if ever a case went to court on this in Automattic's native US, then the counter-suit would most certainly be the freedom of speech standpoint.

Be careful what you wish for (Matt and Co)

Gaz

comment:78 miqrogroove4 years ago

I agree this ticket was not resolved by [15377]. The P filter will still alter HREF values, class names, and plain text.

comment:79 nacin4 years ago

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

comment:80 dangayle4 years ago

Forgive me if I'm wrong, but [15377] seems a bit overblown for something so small. Wouldn't simply requiring spaces around "Wordpress" eliminate 99.9% of URLs, links, editorial quotes, etc?

return str_replace( ' Wordpress ', ' WordPress ', $text );

dangayle4 years ago

comment:81 dangayle4 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:82 nacin4 years ago

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

Please see http://core.trac.wordpress.org/ticket/13971#comment:15.

That would miss the start of paragraphs and the end of sentences, before a comma, etc.

Additionally, those that seem to have an issue with editorial quoting and content here aren't concerned that is surrounded in quotes, but that it's being altered in general (or that it is happening somewhere inside of quotes). They can remove the filter if they are of that opinion, which they are entitled to.

This is staying as is for 3.0.1 and for the foreseeable future. Closing again as fixed.

comment:83 flashingcursor4 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

The new code doesn't change Wordpress to WordPress in several different scenarios where it "should" - inconsistent.

Also breaks code snippet display in many different ways.

See: http://bit.ly/9UzBQk for several examples.

comment:84 wpmuguru4 years ago

What about doing the space before & after as 2 separate strings?

$text = str_replace( array( 'Wordpress ', ' Wordpress' ), array( 'WordPress ', ' WordPress' ), $text );

That would eliminate any links but catch 99.9% of the instances in text.

comment:85 follow-up: gazouteast4 years ago

  • Keywords removing added; has-patch reverting removed

It's a shame he's not around to read this, but George Orwell would certainly have loved the concept of capital_P_dangit() and probably written it into the sequel of "1984" if he had one planned.

Given WP's global popularity, I think it's also passing dangerous ideas into the minds of several rather dodgy regimes too - consider the "at national borders router" censorship that goes on in many countries (including the supposedly free democracies) and then think about the ideas towards web content replacement (as opposed to blocking) that this "little function" passes to the various corridors of power.

This "little function" could become the tip of an avalanche of rewriting that leaves various nations with different versions of history, science, politics, geneticism and so forth - it's dangerous - remove it before it gets perverted in the same way that atomic power was in the early 1940s.

And .... no, this is not an over-reaction if the history of mankind is anything to go by.

comment:86 jane4 years ago

Trac is for code patches and code progress. Can we save the philosophical stuff for other avenues, please?

comment:87 demetris4 years ago

Replying to jane:

Trac is for code patches and code progress. Can we save the philosophical stuff for other avenues, please?

You are wrong!

Trac tickets are for discussing and evaluating patches. (Preferably before the patches are committed.)

The discussion and evaluation is often technical, but, depending on the patch and the reasoning behind it, it can very well be philosophical too.

comment:88 in reply to: ↑ 85 filosofo4 years ago

Replying to gazouteast:

This "little function" could become the tip of an avalanche of rewriting that leaves various nations with different versions of history, science, politics, geneticism and so forth - it's dangerous - remove it before it gets perverted in the same way that atomic power was in the early 1940s.

And .... no, this is not an over-reaction if the history of mankind is anything to go by.

In that case, you've made a comment at the wrong place: this is the WordPress bug tracker, not the Human one.

However, I suspect that "blowing even the smallest thing out of proportion" is already a known issue with humans.

comment:89 lfaria4 years ago

My testimony.
I use a copy of my website, where did the upgrade to WordPress 3.0. Until today had not noticed anything wrong. But today I read the post from Justin Tadlock, and I realized that many links, PDF and pictures, gives error 404.
Had it gets upgraded from WP 3.0 in my main site, would have very bad problems to solve.
In my case it was not a good idea that filter.
Lauro Faria
http://www.bdibbs.com.br

comment:90 sbressler4 years ago

  • Cc sbressler@… added

comment:91 follow-up: MattyRob4 years ago

It seems to me that the function provided in the core to type correct has the potential to cause problems of a greater magnitude than those that it fixes.

Although the usage of Wordpress may irk the coders who work on WordPress it does seem that the code introduced to resolve this has broken a great deal of links on websites that have worked fine with WordPress version prior to 3.0.

So, I would propose thought on the following:

1/ Patch it quickly to get it working in a way that only replaces what should be replaced.
2/ Revert it from core until it can be made to work effectively as above.
3/ Add an easily accessible way for users to turn this feature off either as a plugin or an option in settings.

comment:92 in reply to: ↑ 91 jestro4 years ago

Replying to MattyRob:

3/ Add an easily accessible way for users to turn this feature off...

+ 1 for making this a setting that users can disable if they choose (like convert emoticons). It would fit conveniently under Writing -> Formatting.

Reverting would be preferred, but that doesn't seem very likely at this point. Giving users a way to disable the formatting will at least make it much less intrusive. I think what upsets people is the formatting of content without asking permission or giving regular users (who may not even know about it) the freedom to quickly and easily turn it off without installing a plugin or editing code.

comment:93 follow-up: dd324 years ago

  • Keywords needs removing removed

3/ Add an easily accessible way for users to turn this feature off either as a plugin or an option in settings.

I dont really want to fan any fires, But I'd like to point out the 2nd comment here refers to a plugin which was released before WordPress 3.0 (IIRC), and to date, has had a total of 442 downloads. http://wordpress.org/extend/plugins/remove-wordpress-to-wordpress-filter/

I've reset the Keywords field too, Since it didnt contain any keywords which we use on Trac, The Keywords field is only utilised for Reports/Triage, and makes no difference otherwise, The full list of Trac Keywords we use is available here

comment:94 in reply to: ↑ 93 MattyRob4 years ago

Replying to dd32:

I dont really want to fan any fires, But I'd like to point out the 2nd comment here refers to a plugin which was released before WordPress 3.0 (IIRC), and to date, has had a total of 442 downloads. http://wordpress.org/extend/plugins/remove-wordpress-to-wordpress-filter/

I'm aware of the plugin solution but I would not class this as 'easily accessible'. The end user would need to be aware that the solution was already there as a plugin or chance a plugin search to find it.

A core option to turn it off should be as straight forward as the 3 line plugin and would pacify the WordPress 3.0 users who have seen their sites rendered full of broken links by this code addition.

I'm trying to offer pragmatic solutions to something that, while maybe not a problem to the core devs who know how to work around this problem, may well be a big issue for users who just like to install and use and would have little idea about finding if this issue affects their site, much less know how to fix it.

Think of your end users and make their life easier rather than alienating them.

comment:95 follow-ups: jb5104 years ago

Your saying the solution to this ridiculous filter is to install a plug-in on every single site I manage? What a load of crap. If Automattic wants to run this on wp.com fine, but this has no place in core.

Could someone just create a fork without this garbage?

comment:96 in reply to: ↑ 95 jb5104 years ago

I just want to add that the right way to do this would have been to build this into the editor for new content like an actual spell checker, not to go retroactive changing my content on the fly without notice.

comment:97 in reply to: ↑ 95 MattyRob4 years ago

Replying to jb510:

Could someone just create a fork without this garbage?

While this code addition is obviously irritating forking the code is not a tenable solution. WordPress is already a difficult enough proposition to manage without starting to create forks for each new feature we wish was omitted. You then face a mammoth task keeping your fork up to date with the WordPress core.

A better solution would be to get this feature working to a degree that satisfies the developers and the end users and that will only happen through negotiation and compromise.

comment:98 shidouhikari4 years ago

forking is a bit overreacting, there are many more important tasks that can't be done by plugin and require core editing

just add a plugin that removes the filter or edit core source to remove if for good

comment:99 goto104 years ago

+1 for revert.

comment:100 caesarsgrunt4 years ago

I am absolutely outraged by the whole way in which this has been handled by the core devs. In my opinion, this incident highlights the increasing contempt and disdain shown by the WordPress core devs towards both the users of the software and the non-core developers who pour their time into the project.

In the first place, it is clearly not the business of Automattic, or of the WordPress core devs, or of anyone else, to 'correct' my spelling without my permission. If I write something, you have no right whatsoever to change it unless I ask you to. Are you going to start forcibly auto-correcting other words now? Automatically 'fixing' my grammar? Where do you draw the line? If I write 'Macbook' should TextEdit forcibly fix it? Should Mozilla forcibly prevent me from incorrectly writing 'FireFox' in any textarea? Should Word forcibly prevent MS-haters from from writing 'Micro$oft Windoze'? Surely any reasonable person can see that this censorship is not right.

(I might add at this point that it has often annoyed me that the word WordPress is not supported by the built-in spellchecker, and that the right way to guide people towards correct spelling of the name is to add it to the spellchecker and treat it like any other misspelled word. Highlight it, and let me decide to fix it or not.)

Now, let us give the devs responsible for this abomination the benefit of the doubt, and assume that they were naïve enough not to think of the creepiness factor, and that the obvious bugs which this blind global find-and-replace could create didn't occur to them either. Even so, once these factors have been made apparent, and so many users have voiced their concerns, it is utterly unforgivable that these concerns and brushed aside in this we-know-best-and-you-don't-matter way.

How could any sane person think that forcing the correct spelling of one name is important enough to (a) slow down my site, even my a few microseconds (b) introduce bugs, even rare bugs, or even the faintest possibility of bugs and (c) trample on my freedom of speech?

(An interesting case study - supposing I wanted to write about how to spell WordPress on my blog. Impossible, right? Just a simple example of the type of thing you're preventing people from writing.)

Oh, yes, you say you're not forcing this on anyone, I can disable it with a plugin, etc. Right. So, to disable this crap, I have to actually install a plugin. Slow my server down more. Run more code by a potentially untrustworthy author. Increase my maintenance overheads. Etcetera. There is no way to justify requiring a plugin to fix a bug like this. Besides, that's not the point, this just shouldn't exist in the first place.

I still love the WordPress software. I used to love Automattic. But as time goes on, the leadership becomes more and more dictatorial. Every day the core team becomes more arrogant, more pigheaded, more self-important. Every day, the user becomes less important to the core team. And every day, you become more like the major corporations who don't care about their users. It's a sad transition to watch, but it seems to be too late to do anything about it. The situation has reached this point: if there were a viable fork, I'd switch today. I know a lot of others would too.

comment:101 caesarsgrunt4 years ago

PS. In case it isn't clear from my previous comment, my gripe is mostly with the way in which the core team is treating the community, rather than this specific bug itself.

comment:102 ecb294 years ago

Yeah this is not acceptable, as when I upgrade anything with "Wordpress" etc in the permalinks will start to 404. (obvious) revert

comment:103 bcorcoran4 years ago

+1 revert.

In addition to all the comments here, even the naming of this filter/function are grossly unprofessional. I'm not for being politically correct, but "capital_P_dangit" just screams immaturity.

We get it. You want Wordpress to be "WordPress". You have a trademark and you want to enforce it, but this isn't the way to go about it. Add a filter to the post editor to highlight Wordpress as a spelling error as Chrome is doing to me as I type this post, then call it done. And don't name it capital_P_dangit, dangit.

comment:104 edward mindreantre3 years ago

+1 to bcorcoran. Mighty unprofessional.

comment:105 Denis-de-Bernardy3 years ago

  • Milestone set to 3.1
  • Priority changed from lowest to highest omg bbq
  • Severity changed from major to blocker

Curious to know... I realize this is one of Matt's pet features, but this ticket, on the top of my head, has one of the highest number of votes in trac -- if not the highest. It's a f*cking outrage that it's getting so little attention by committers, on a project that is supposed to be driven by community members.

Could this ticket get any kind of traction before 3.1 gets released please? There are only so many alternatives:

  • A committer can remove this garbage and begone with it once and for all.
  • We can use extensive regexp'ing and fix any underlying issues that remain, at the cost of slowing WP down even more but with the benefit of keeping Matt happy.
  • A committer can close the ticket as wontfix, telling the community to have it up theirs.
  • Committers can leave the ticket open, telling the community to have it up theirs with sand and gravel.

comment:106 nacin3 years ago

  • Milestone changed from 3.1 to 3.0.1
  • Priority changed from highest omg bbq to normal
  • Resolution set to fixed
  • Severity changed from blocker to normal
  • Status changed from reopened to closed

comment:107 Denis-de-Bernardy3 years ago

Thank you. :-)

Note: See TracTickets for help on using tickets.