[wp-hackers] WP issues
foolistbar at googlemail.com
Thu May 31 18:55:33 GMT 2007
As I promised I'd write ages ago, here's a list of issues with
WordPress (though I accidentally sent this from my main email address
and it got caught in the moderation queue yesterday, so here it is
from the proper address (which, as it is subscribed, should read all
1. People have been asking for an XML serialiser to be used for all
the XML WordPress produces for years. This doesn't exist. This allows
invalid bytes to get into XML data. Try parsing <http://photomatt.net/
comments/feed/atom/> with a compliant XML parser. You'll get a fatal
error. This is the exact sort of issue that an XML serialiser would
2. Having waited years for an Atom 1.0 feed to be offered:
a) We eventually get one that allows malformed XML to be inserted
(see 1. above).
b) Uses RFC 822 dates (what part of section 3.3 of RFC 4287[RFC4287]
c) Uses @content for <link> (where did that come from? There's no
@content in the entire spec! Please see @href, section 188.8.131.52
d) Claims that the blog title is a MIME type, and when the feed is
meant to link to itself it links to the RSS 2.0 feed (what's unclear
in section 184.108.40.206 of RFC 4287[RFC4287]?).
Those four issues are just from a quick glance at the above mentioned
feed. Seeming so many of these things are CLEARLY wrong, it looks as
if the person who implemented it had NEVER read the Atom 1.0 spec,
3. Why was no Atom 1.0 feed offered?
a) "Aggregators I tried with the existing patch didn't
work."[TICKET1526] — We already offer multiple feeds to make sure
the UA can parse one (though in the above case, all of Photo Matt's
comment feeds are currently broken, and any parser that parses it is
b) "There is no satisfactory patch available."[TICKET1526] —
Waiting doesn't seem to have made this much better than patches that
were around several years ago, see 2.
c) "We have no way currently to ensure XHTML validity."[TICKET1526]
— See 1.
4. When will the above (see 2) issues be resolved?
a) There was a bug I reported around six months ago in the Atom 0.3
feed[TICKET3377], which still hasn't been fixed in WordPress 2.0.x,
despite the fact it makes the feed totally unusable in some
aggregators (Firefox 2.0 included).
b) This bug had been in WordPress for several years, yet remained
unfixed, despite the fact that a visit to the feed validator
[FEEDVALIDATOR] would have clearly pointed it out.
c) Matt failed to read the report: "Since our feeds currently work
everywhere, I'm not inclined to change this."[TICKET3377] (the bug
report explicitly cites Firefox 2.0 as breaking). Is it really too
much to ask to actually read a bug report before closing as wontfix?
5. WordPress has no guarantee that the XHTML it outputs is well-
formed OR valid.
a) Us, as implementers, are allowed to parse XHTML (even when served
as text/html) as XML, so WordPress will fail horribly.
b) There is no method to switch WordPress to output HTML (so we
don't expose users to fatal errors), and this can't be done at a
theme level as in places empty tags are closed within WordPress's
source. We can't change this without using an XML parser on
WordPress's output, but as there is no guarantee it's well-formed,
this doesn't help.
6. WordPress claims that it has "a focus on aesthetics, web
standards, and usability."[WORDPRESS]
a) If you focus on web standards, why is that very page served as
text/html while having an XHTML 1.1 DOCTYPE? This SHOULD NOT[RFC2119]
be done under advice from the old HTML WG[XHTMLMIME]. Can you please
cite your reasons in this "particular behavior is acceptable or even
useful"[RFC2119] (from the normative definition of SHOULD NOT).
b) WordPress by default uses a DOCTYPE that exists for transiting to
standards. If you have a focus on web standards, why is this
transition still going on after many years?
c) WordPress uses XHTML served as text/html, which MAY be done. Why
does this (the blogosphere) "particular marketplace requires it or
because the vendor feels that it enhances the product"[RFC2119] (from
the normative definition of MAY)?
7. WordPress has on several occasions avoided changing libraries
(sometimes to the extent of just not updating them) on grounds on
a) We're moving from script.aculo.us to JQuery, but keeping JQuery
around for plugins/themes that need it. Why can we not have multiple
versions of other libraries (or different libraries that do the same
b) Better yet, why don't we just have an abstraction layer, so the
library is never called directly (and therefore can be swapped
without breaking anything)?
8. There are other bugs that do in many places cause large issues,
including but not limited to:
a) IRIs as comment links get stripped (e.g., James Holderness,
<http://www.詹姆斯.com/>, posted a comment on my blog. The IRI was
rewritten to <http://www..com/>.).
b) <blockquote> elements cannot be nested within one another
[TICKET1170]. This is marked as closed, although I just recreated it
on both 2.2 and 2.3. This bug has been opened for over _TWO YEARS
WITH PATCHES AVAILABLE_!
9. There have been several occasions on which Matt has overruled
consensus, sometimes giving a reason like "I misunderstood" (does
that mean _EVERYONE_ misunderstood, or just you, Matt?).
10. Matt has claimed that the development process isn't broken
because everything gets replied to. I'll continue waiting, then
[HACKERS12601]. Oh, and see if anyone replies to this.
11. WordPress tries to improve the quality of releases by moving onto
120 day releases[HACKERS8907], yet proceeds to break it with the
first release on the cycle[CHANGESET5110] (or does tagging not count
as "crazy wild fun development"?).
In summary, I'd advice those working on WordPress to read the follow
specifications (including all references):
a) XML 1.0[XML]
b) RFC 4287 (The Atom Syndication Format)[RFC4287]
c) XHTML 1.0[XHTML1]
d) XHTML 1.1[XHTML11]
e) RFC 2119 (Key words for use in RFCs to Indicate Requirement
Hixie has a post[HIXIE1140242962] that explains how to read
specifications. For those who think this post is all far too serious,
here's something (slightly) less serious:
"This specification should be read like all other specifications.
First, it should be read cover-to-cover, multiple times. Then, it
should be read backwards at least once. Then it should be read by
picking random sections from the contents list and following all the
All the best,
More information about the wp-hackers