[wp-hackers] Wordpress as a CMS

Mike Schinkel mikeschinkel at newclarity.net
Tue Dec 22 01:56:52 UTC 2009

On Dec 21, 2009, at 3:49 PM, Otto wrote:
> Exactly how much metadata are you planning on storing here?

I assume you are replying to my email although you did not reference it in specific?

> Because
> the performance of the index isn't related to the number of rows in
> the table, it's related to the log of the number of the rows in the
> table.

Agreed. The discussion was prefaced on the need for *large* datasets.

> That is, we're indexing on the post-id, not just on the key. Unless
> you're storing massive amounts of data on every single post, the
> performance would not notably degrade.

In the normal case, agreed.

Remember I said that in most cases I think post meta are the best solution, just not in all.  

> Your example shows an unusual case, where you are selecting based on
> metadata. However, this is an extremely unlikely case for the vast
> majority of cases, where either a specific post is pulled or a series
> of posts are pulled based on date, tag, category, etc. You almost
> never use metadata to select which posts to display.

I disagree that it is an unusual case.  In the nominal case where everything is viewed through the prism of "blog" I agree.  However when using WordPress as a CMS for real world applications having the need to query on more than one criteria is not at all uncommon and having multiple level relationships, which are uglier with metadata, is even more common.

> If you are using metadata to select posts, then obviously your example
> holds, but I'd also say that you're doing it wrong and should be using
> custom taxonomies instead. In your example, you use city, type, price.
> Presumably every post would have one of these, in which case you
> should have three taxonomies for them in order to categorize them into
> the right spaces accordingly.

Again, in a blog world, yes.  Not always in a CMS.  We'll have to agree to disagree there.  

The problem with taxonomies is they bring along a binary value, yes or no; i.e. is city Atlanta?  They don't bring along Atlanta's population, mayor's name, square miles, list of counties, etc. That required a more relational model. 

BTW, how are you going to get "price" represented in a taxonomy?  Or a "date?" Or other effectively attributes where potential values are effectively infinite?

> The current downside is that wp_query doesn't offer a way to combine
> multiple custom taxonomies, but I'm sure something could be added to
> make it work.

When that happens, when taxonomies can carry a value with each association and when the admin UI supports such combinations then I'll be more likely to agree that taxonomies are a panacea.

On Dec 21, 2009, at 5:38 PM, Peter Westwood wrote:
> In my personal opinion if I was designing a site which needed this kind of functionality I probably would not start with the WordPress platform to develop it.

I understand that's a position many people take.  I take the position that so much of what I need it already provided by WordPress that it's crazy not to use it.

> I would however start with the BackPress framework because of all the cool WordPress like functionality it provides like User Managment, DB abstraction, object caching etc and I can have whatever urls I want and optimise the database structure to make the queries zippy.

I googled "BackPress" and found very little substantial.  

I did find this http://www.ohloh.net/p/backpress but this "Decreasing year-over-year development activity" would scare me away from it.  I'd be far more apt to use CakePHP or similar if I had to abandon WordPress as a CMS framework.

> I like to use the right tools for the job rather than fight against the one that doesn't do what I want how I want - I find it works better that way

The "right tool for the job" is an illusive holy grail. Every tool has tradeoffs; the tradeoffs that I value are different than the ones you value.  I value that simplicity of WordPress architecture and the vast support it has from 3rd party themes and plugins, 1000s of articles on how to use it, and how nicely it does 90% of what I need (it's that 10% I'm trying to get past.  But a year ago is was only 85% of what I need so it's getting better.)

> If you have any BackPress questions then please let me know off list and I can point you in the right direction.

Thanks for the offer.  I'd be interested if it were something a lot of people were using and actively writing about.  If I am somehow misunderstanding its role then I would be very interested in learning more about it.

On Dec 21, 2009, at 6:55 PM, Matt Mullenweg wrote:
> Every large scale website I've seen dealing with this complexity of data does multiple queries + caching, which simplifies these scenarios vastly. I'm anti-join.

FWIW I'm anti-caching in the nominal case; i.e. caching should be for optimizing performance when good performance can't be otherwise had but not as an upfront architecture choice.

On Dec 21, 2009, at 7:17 PM, Vinicius Massuchetto wrote:
> I got impressed how WP Super Cache can deal with that, and in the end
> the website had more than 2.000 visits a day with no overload at all.

2000 visits a day is one visit ever 43.2 seconds.  I *hope* WordPress meta can handle that.

How about 2000 visits a minute?  That's much harder.

ANYWAY, I'm not trying to perpetuate this debate. It is what it is, I was just explaining to the person who advocated why custom tables were not going to happen (Matt and others are against it) and then explain my view of the benefits of custom tables to someone asked why it mattered.

I'm continuing to work on PostTypeVoodoo as a I have time. It will be a tool to provide a UI for adding post types and for routing URLs.  It may also support added custom table definitions but will, for simplicity, only support custom fields.  Once it's gotten a minimum feature set I'll release.


More information about the wp-hackers mailing list