As much as I like the concept of WP "pages", which should enable the use of WP as a lightweight CMS with built-in blogging, I do not think it is currently usable for anything more than very small personal sites. The problem is (again) in the liberal use that WP does of MySQL resources, and in the bad design of its DB layout.
I just finished inserting a couple of hundred pages in the db to move a site which is currently using a custom CMS to WP+LP, and imagine my surprise when trying to access "Manage Pages" in the WP admin console PHP exited with a
memory_limit
error. I raised
memory_limit
to 24M, restarted Apache, and......waited 25 seconds for the page to load!
What happens is that WP is retrieving every field for every page in the DB even though it just needs the title, date, id, etc. (thus the memory error), then it retrieves the same fields again with a single query for each page. I have 173 pages in my DB (some with 50-100k of content), thus 180 queries to show the "Manage Pages" admin view. Ugh!
The problem is in the way WP builds the permalink for each page (
get_page_uri
called from
get_page_link
), as building the permalink involves fetching parents. A simple solution would be to build a tree of all pages with the first query, and use it to build permalinks. Which is what we do in
Frontend->getPages()
and the
NestedPages
plugin. A better solution would be using SQL trees and making away with the ugly self-referencing foreign key to express child-parent relationships. I will leave tomorrow for a couple of weeks of vacation, when I get back I guess I will have to write an alternative
wp-admin/edit-pages.php
, or look for a different solution (maybe eZ publish or a custom CMS built on Django).
Have you ever looked at SemioLogic CMS? How do you think he is doing a CMS with WP?
I just started reading this site, and I am very interested in this project, as I too find Wordpress a really nice design, somewhat poorly implemented. Just one comment, though…
Self-referencing foreign keys are not ugly. They're the simplest way to model a hierarchical tree. Their problem is the slowness of queries against them. Before resorting to Celko-style nested sets, there are a few options. Some RBDMS offer shortcuts to efficiently traverse hierarchies modeled this way (Oracle as CONNECT BY, for example). You can also write your own functions to help speed this kind of queries: for example, you could have triggers updating each record with top_parent and tree_depth fields. While you're at it, you could also have triggers populating the Celko right and left fields. Of course, MySQL does not support triggers or functions, so you're kind of screwed here.
mgrice: I have no idea how Semiologic implements his CMS, but I know that WP pages do not scale for more than 10 or so pages.
Alexandre, yes I know other databases have shortcuts for nested sets, but WP is based on MySQL which is what most providers offer out of the box. Celko sets are a very clean way to quickly read nested trees. Another solution, as I wrote above, is to parse a flat SELECT (using only the relevant fields to save memory) from PHP, what we are doing in one of our plugins which is a couple orders of magnitude faster than what WP does with just a few lines of code.
ludo: I agree. I haven't looked at WP's code as long as you, but the little that I peaked striked me as not very conscious of db usage. I've never understood why a standard WP installation proudly displays that it needed more than 20 queries to output an index page. On a related note, this quote from the WP codex: "Reading is Cheap, Writing is Expensive" seems at best ill-informed to me. So I'm with you here, and very interested in the optimisation work you're doing, since my brother's site uses WP Pages extensively.
You're also right that WP and WP plugins need to run on top of MySQL, because of its huge installed base. Therefore my discussion of RDBMSes was somewhat beside the point. IMHO, Celko sets are efficient when selecting, but a pain when inserting and updating, and they're not instinctive to a human eye. Your solution is probably the best compromise. I'll look at your plugin more carefully before commenting any more. Thanks for the feedback!
Alex, my comments are not timely as I'm on vacation right now. Your input is *very much* appreciated, and it's exactly what we need to keep on improving LP. :)
I'm running a WP blog myself, and one factor (apart from the obvious trackback spam issue) which precipitated my move from MT 3.1 is that it uses far less resources than MT, and this is something other migrators have attested to. Which blog platform in your opinion is the most efficient in its database usage?
WP pages patch Fresh from two weeks of holidays in beautiful Lanzarote, I tried to tackle the WP pages problem I outlined in my previous post. The result is a 150 lines patch for wp-admin/edit-pages.php, which brings rendering time down from 18 seconds to less than 1…