WordPress code quality
WordPress calls itself a “state-of-the-art semantic personal
publishing platform” — but the engine that lies beneath this shiny,
smooth-looking CSS-styled surface is not that nice.
I find the coding standard in the current (version 1.5.1.1) code to be below what I would expect from a piece of software as popular as WordPress:
Global variables are used all over the place! Global variables should be used sparsely, if at all, for they often make the code more difficult to understand. Other people agree that Global Variables are Bad.
From looking through the code I’ve found a
$wpdbvariable which is used as a global handle to the database. That’s fair enough — such a handle is needed, and lots of different pieces of the code need access to it. But still it could be handled better if one consistently used$GLOBALS['wpdb']instead ofglobal $wpdbfollowed by a later use of just$wpdb— by using the$GLOBALSarray one precisely describes that this variable is just that: global.There are also lots of other global variables in the code, and they are often used in a much more subtle way than the
$wpdbvariable. A simple count of the (unique) variables declared global in thewp-includesdirectory gives no less than 108 variables!Lack of comments! The core files such as
functions.phpcontains tons of functions, but no comments. Take a random function likemysql2date()with a signature offunction mysql2date($dateformatstring, $mysqlstring, $translate = true)
is hard to understand without reading the code. The source has no doc comments which describe the arguments or the result type.
The online documentation website, the Codex, is still very incomplete when it comes to information about the internals, and I would much prefer to have the documentation right there where it’s needed: in the code.
Duplicated code! Why does the code in
post.phpnot use thewp_insert_post()function declared infunctions-post.php? Instead it seems to duplicate the logic inwp_insert_post(), something which will sooner or later lead to problems.Incredibly long lines! It is clear that there has been made no attempt to break the code into lines at a reasonable site (that is, less than 80 characters per line).
Those long lines makes the code annoying to read unless I make my terminal or Emacs huge and it makes diffs cryptic when one has to compare two 200 character lines to figure out a change. For someone who would like to look into the code those things make a real difference and should not be neglected because it is “just cosmetics”.
Mixed XHTML and PHP code. The themes in WordPress use no page template system what so ever, they just output the raw XHTML to the user — making it easy to create invalid XHTML output.
To defend this choice, then I must say that I’ve never been impressed by template systems like Smarty which claims to separate the application code from the presentation. To do this they give you a template language in which you can program your pages — if you look more closely at it, then this template language ends up being simply a reimplementation of the original language. So instead of
if ($foo || $bar) ...you write{if $foo or $bar} .... Has this bought you anything, except requiring you to learn another language with its possible quirks and limitations?If that was what the WordPress developers asked themselves, then I can understand why they simply went with normal PHP code mixed with XHTML. But it can be done better than that: PhpWiki uses a cool system where all the XHTML code is generated using a set of classes and functions. Using such a high-level interface automatically makes the produced XHTML code compliant and it makes the source so much cleaner. With some proper caching the performance shouldn’t be affected, but the long term quality of WordPress would improve.
I hope that the WordPress developers take steps to fix and improve some of the things I’ve described above. Apparently, there are others who agree with me about the quality of the WordPress code. Despite my complains, I’ll keep using it, for even though I can find lots of things to complain about, I still think it’s the best software for what it does.
Carthik:
You file some bug reports, with patches, if you seek to help rectify the problems. Discussions are active at the mailing lists too.
23 May 2005, 6:56 amMartin Geisler:
You’re right. But the points I talk about above are not just things you fix with a one line patch, they are related to the coding style as a whole.
I’m aware of the Coding Style document available, but it doesn’t address one of my more important complaints: “Comment your code!” Having no comments in vast parts of the core is really bad style, and instead of having some third party write the comments now, afterwards, then it would have been much easier for everybody if the original developers (who know what each function does) would have written the comments with the code.
23 May 2005, 7:40 amrandom:
I think your point about global $wpdb is dead wrong. $GLOBALS is hideous and confusing, and from memory it’s not possible to use array members in quoted strings (as is done with, e.g., “SELECT * FROM $wpdb->posts”). Your argument on globals in general would be more persuasive if you audited the code to find globals which could actually be removed without loss of functionality or efficiency. I don’t think you’d find many.
Yes, more comments are needed. More documentation in general is needed. I should probably write some, now that I think of it.
Duplicated code might be legacy stuff; I’m pretty sure the XML-RPC stuff that uses wp_insert_post() isn’t nearly as old as post.php. There might be a good reason, but I can’t think of one. File a bug.
From my point of view, most of the long lines make the code more readable — not splitting up something that will result in one <a> tag over three lines, for example. Spreading it out is confusing. That’s code style, not code quality.
Anyone can write a templating system to generate WordPress code if they really want one; I don’t think it should be part of the core. There are pre-packaged themes available for users who don’t want to touch XHTML, and this way is much more flexible for those of us who know what we’re doing.
23 May 2005, 11:09 amrandom:
Also: dude, can you please use wpautop/Markdown/Textile/whatever on comments? Or at least warn that HTML is required.
I quite like it when my paragraphs stay as paragraphs.
23 May 2005, 11:11 amDenis de Bernardy:
Martin, we’re in 2005! You shouldn’t be using a code editor that doesn’t automatically wrap code. :)
23 May 2005, 12:57 pmMartin Geisler:
:-) You mean that your editor wraps your code (on whitespace I assume) and indents it dynamically?
I use [Emacs][] (if that wasn’t obvious from my attitude against long lines…) and it can indent my code properly. But long lines are still a thing which the developer has to wrap. And for me that makes the most sense — when viewing the changes (diffs) in [SVN][] short lines are good too.
23 May 2005, 1:12 pmMartin Geisler:
Believe me, I’m just as annoyed by this as you are — I am using Markdown in both my posts and in the comments, but some filter apparently removes the paragraphs in comments.
23 May 2005, 1:14 pmMartin Geisler:
I don’t think one should decide on the use of global variables based on efficiency issues — have you benchmarked PHP to see which of
'SELECT * FROM ' . $GLOBALS['wpdb']->postsandglobal $wpdb; "SELECT * FROM $wpdb->posts"is faster? (I haven’t, but I don’t think the difference will be big, there are lots of other things going on that are going to take more time.)You’re of course right about creating a ticket for the duplicate code issue: #1401 has been submitted.
23 May 2005, 1:33 pmDenis de Bernardy:
You should download the Markdown fix plugin, and spread the word that it exists.
23 May 2005, 3:23 pmDenis de Bernardy:
Try Visual Studio .Net…
23 May 2005, 3:24 pmMartin Geisler:
Aha — I had found your fix, but I missed the fine print saying that it is still needed with the latest version of [Markdown][]. Thanks!
(A small test, this should become a separate paragraph.)
23 May 2005, 4:19 pmMartin Geisler:
It works now! Thanks Denis for pointing me to your fix!
23 May 2005, 4:20 pmAsymptomatic » Blog Archive » In Defense…:
[...] g about something in general terms which you don’t seem to have specific knowledge. Martin Geisler wrote an incendiary post about the WordPress codebase, and while I will adm [...]
24 May 2005, 3:19 amSencer:
Hi Martin,
I can understand very well what you are trying to say. Most of it results from the fact, that Wordpress grew out of b2, which had the same problems. But a few years back and with a lot smaller code base that was (a little) less of a problem. I don’t think it’s possible to change the minds of the many people that are comfortable with the code, because they have gotten used to it. Refactoring that mess is a major, major task.
A rewrite would likely be faster (but of course has its’ own problems). However that would probably not fair well with users, because it could break many plugins, one of the major advantages of WP wrt to other blogsoftware. (There is a lightpress project which basically tries to do just that, my first impressions have been quite positive). I am afraid this is a take it or leave situation, I left it (b2 that is) and went to Textpattern, which also has little to no documentation in the code, but has a lot less dependencies, less global variables, and generally more readable code (IMHO).
29 May 2005, 12:13 pmMartin Geisler:
I think you’re right about WordPress needing some refactoring and rewriting. When I brought my complains to the mailinglist I was told by Matt that the code base was very mature because of their old roots in b2.
Having old roots might make the code seem mature, but for me mature code also has to be well documented, something which the WordPress code cannot claim to be.
I have not yet tried LightPress, but maybe I will. Since it runs on top of WordPress I imagine that switching will be easy. Thanks for the tip.
29 May 2005, 3:27 pmLightPress » WordPress is fast, MySQL is slow? FUD at work:
[...] ce of technology and a very fast database, the same cannot be said for WP’s code (see also this), db design and queries. For simple things (INSERTS and SELECTS) MySQL often beats th [...]
2 June 2005, 12:38 pmJoseph Scott’s Blog » You Don’t Have To Be Pretty To Be Successful:
[...] hundreds of defined functions. I’m certainly not the only one to write about this, Martin Geisler posted a list recently. Martin mentions things like excessive use of globa [...]
6 June 2005, 7:44 pmWeb Development Frameworks at Endlessly Curious:
[...] the months, I’ve noticed that it is not the prettiest of code in place and again I’m not alone in noticing [...]
13 November 2008, 10:42 amPhp ...php4 php5 php6.. Php.... - SinhViênIT.Net ||Diễn Đàn Sinh Viên CNTT:
[...] PHP6? Wordpress đâu phải có chất lượng mã (code) tuyệt vời mà ngược lại. Martin Geisler Online Blog Archive WordPress code quality Nhưng chất lượng mã của Wordpress dở ẹc, việc Wordpress dùng PHP5 hay không, [...]
6 March 2009, 10:19 amLenz:
Hi Martin,
gladly i found someone who shares my opinion. Never saw such a messed up code like Wordpress.
Opening any file feels like 1995. This is not “State of the Art”.This is no art at all.
I am truly disappointed. Wordpress is soo shiny, easy to use ans user friendly but from a programmers point of view
it is just a piece of crap.
How can the config file be part of the call-cain?
How can one mix HTML, CSS, Javascript and PHP in one file in the year 2009?
How can you programm a wide spread web app with the “one site one file” paradigm these days.
They truely need some design patterns!
FrontController, Model View Controller, Active Record and Decorator Pattern would be a good start.
True - you don´t have to be pretty to be famous.
But you have to have values to be worth something. (Hope this expression works in english ;) )
Lenz
15 March 2009, 2:53 pmRaiulBaztepo:
Hello!
29 March 2009, 12:30 amVery Interesting post! Thank you for such interesting resource!
PS: Sorry for my bad english, I’v just started to learn this language ;)
See you!
Your, Raiul Baztepo
Jason Judge:
Four years on, and the code is still a right old mess.
I’ve just taken a look at the admin scripts today for the first time, as my WP site was hacked. I nearly fainted - it looks like something written ten years ago by an absolute beginner.
The main complaint I have, is that they don’t write code with safety in mind. By that, I mean code that will be resilient to the next developer coming along and changing it. Just enforcing the use of {curly braces} within if {…} else {…} statements would go a long, long way to avoiding stupid bugs.
Then there is code and HTML mixed in the admin scripts - very hard to read and follow.
Lastly (from my fairly quick perusal) - references to _POST all over the place. Instead of a single entry point to pick up use data and validate it at the same time, scripts reference _POST freely everywhere, and validate it using preg_replace() too. There is no one place where the code can say “give me variable foo and make sure it is an integer”. That is leaving the door wide open to stupid validation errors and hacks.
And that, appears to be what has happened to my site.
It is time the code base was dicarded and rewritten with fewer entry points, less duplication, everything (and I mean ALL code) wrapped up in objects and functions, rather than being global in-line, and a better system for handling user input.
I daren’t look at how the database access is handled…
- Jason
5 September 2009, 2:30 pm