#13971 ("Wordpress" being turned into CamelCase "WordPress" breaks URLs) – WordPress Trac

#1 @GautamGupta
14 years ago

#13583

#2 @tfotherby
14 years ago

The workaround is to install this plugin:

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

#3 follow-up: ↓ 4 @hakre
14 years ago

It's a Bug, not a Feature.

Related: #13583

#4 in reply to: ↑ 3 @tfotherby
14 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?

#5 @mrmist
14 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.

#6 @mrmist
14 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.

#7 @zeo
14 years ago

Revert or improve [14996]?

#8 follow-up: ↓ 9 @dd32
14 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)
}}

#9 in reply to: ↑ 8 @toscho
14 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.

#10 @dd32
14 years ago

This is way to slow.

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

#11 @toscho
14 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.

#12 @johnbillion
14 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.

#13 @miqrogroove
14 years ago

+1 revert ASAP

#14 @sirzooro
14 years ago

Cc sirzooro added

+1 for reverting this too.

#15 follow-up: ↓ 19 @markjaquith
14 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.

"“Wordpress" => "“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.

#16 @Ipstenu
14 years ago

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

#17 @mrmist
14 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.

#18 @miqrogroove
14 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.

#19 in reply to: ↑ 15 @johnbillion
14 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.

#20 @harrym
14 years ago

#21 @Denis-de-Bernardy
14 years ago

+1 to save CPU cycles by reverting asap.

#22 @hakre
14 years ago

+1 to revert ASAP as well.

#23 @shidouhikari
14 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?

#24 follow-ups: ↓ 26 ↓ 27 ↓ 29 @JDTrower
14 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.

#25 @miqrogroove
14 years ago

Health check:

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

#26 in reply to: ↑ 24 @Denis-de-Bernardy
14 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.

#27 in reply to: ↑ 24 @harrym
14 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.

#28 @holizz
14 years ago

Cc tom@… added

#29 in reply to: ↑ 24 @holizz
14 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.

#30 @GautamGupta
14 years ago

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

#31 @harrym
14 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!

#32 @demetris
14 years ago

Cc dkikizas@… added

#33 @markjaquith
14 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.

@nacin
14 years ago

Attachment 13971.diff added

From MarkJaquith

#34 follow-up: ↓ 35 @nacin
14 years ago

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

Attached please find MarkJaquith's suggestion in patch form.

#35 in reply to: ↑ 34 ; follow-up: ↓ 36 @Denis-de-Bernardy
14 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.

#36 in reply to: ↑ 35 @nacin
14 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?

#37 @harrym
14 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?

#38 @harrym
14 years ago

PS: My patch works just fine.

http://core.trac.wordpress.org/attachment/ticket/14043/patch.diff

#39 follow-up: ↓ 43 @Denis-de-Bernardy
14 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...

#40 @miqrogroove
14 years ago

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

#41 follow-up: ↓ 42 @Denis-de-Bernardy
14 years ago

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

http://wordpress.org/tags/wordress

#42 in reply to: ↑ 41 @michaelh
14 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.

#43 in reply to: ↑ 39 ; follow-up: ↓ 45 @johnbillion
14 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.

#44 @sirzooro
14 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 ( ), 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.

#45 in reply to: ↑ 43 @Denis-de-Bernardy
14 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.

#46 @ozh
14 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" />

#47 @jestro
14 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.

#48 @greenshady
14 years ago

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

#49 @Utkarsh
14 years ago

Cc admin@… added

+1 for reverting

#50 @aesqe
14 years ago

Cc aesqe@… added

+1 for reverting, this is nonsense

#51 @nathanrice
14 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

#52 @husobj
14 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

#53 @wet
14 years ago

Cc r.wetzlmayr@… added

#54 @ryanhellyer
14 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.

#55 @nacin
14 years ago

Priority changed from normal to lowest

#56 @strider72
14 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.

#57 @nkuttler
14 years ago

Cc office@… added

+1 Revert

Yeah, I have far too much time.

#58 follow-up: ↓ 65 @johnjamesjacoby
14 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.

#59 @mrmist
14 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.

#60 @carlhancock
14 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.

@greenshady
14 years ago

Attachment remove-capital-Wordpress.diff added

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

#61 follow-up: ↓ 62 @jorbin
14 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>

@markjaquith
14 years ago

Attachment 13971-more-judicious.diff added

@markjaquith
14 years ago

Attachment 13971-more-judicious.002.diff added

#62 in reply to: ↑ 61 @tfotherby
14 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.

#63 @toscho
14 years ago

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

#64 @dougal
14 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

#65 in reply to: ↑ 58 @dougal
14 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.

@dougal
14 years ago

Attachment 13971-cdata-content.diff added

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

#66 @dougal
14 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.

#67 follow-ups: ↓ 71 ↓ 73 @filosofo
14 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?

#68 @markjaquith
14 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.

#69 @markjaquith
14 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

#70 @markjaquith
14 years ago

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

#71 in reply to: ↑ 67 @dougal
14 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").

#72 @F J Kaiser
14 years ago

Cc 24-7@… added

#73 in reply to: ↑ 67 @dangayle
14 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.

#74 @chrisbliss18
14 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.

#75 @chrisbliss18
14 years ago