My Recommendation For WordPress 3.0
Never thought I’d say this… But my recommendation for people thinking about upgrading from a single-user WordPress 2.9 installation to WordPress 3.0: Don’t do it… yet.
WordPress 3.0 is such a major update, that for 95% of the single-user blogs out there, I would recommend putting it off and not upgrading at all. Not until the issues are worked out.
See, everybody is talking about the features of 3.0, and those are indeed many and varied. But not many people are talking about the problems of 3.0. And while it is only in beta, it’s not too early to consider some of the design choices here and think about them in a larger scope.
Firstly, understand that a lot of the new features require theme support. Meaning that your existing theme, while it will work, won’t give you the new menuing system, it won’t have the comment form enhancement, the new editor styling tricks won’t work, etc…
So if you’re going to upgrade to 3.0 without modifying your theme as well, you’re not going to get the full experience.
The new Twenty Ten theme, while it is neat and shows off what can be done, is very, very complicated (and IMO, it also does a lot of things very badly). It’s somewhat difficult for even an experienced theme editor and developer to understand, so expecting a normal blogger to read this as an example and then change their own theme as needed is somewhat nutty. So if you want these new features, you’ll probably need professional assistance to get it all up and working.
Custom Post Types
They’re neat, they’re cool, and they’re insanely difficult to use properly. What’s going to happen here is that people will use them badly at first. Incredibly badly. Some of the examples I’ve seen thrown around are surprising just for the sheer crazy. Yes, you can make a “Podcast” post type, but do you really want to? Does it really make sense in the context of what you’re doing? The answer is probably not, actually.
And using them changes so much internally to the system that things start behaving in ways you totally don’t expect (or see). For example, custom post types don’t show up in feeds by default. That might make your podcasting a little bit, shall we say, broken?
Now, custom post types have to be enabled by plugins and such, so those plugins might indeed take care of this sort of thing properly. But frankly, I wouldn’t want to bet on it. People are going to have all sorts of weird problems with this until they work out that they really didn’t need custom post types after all.
IMO, only a very limited subset of people need this, or think they do, and those people are very likely already using them in some manner.
Any plugin that deals with posts being published is likely to be affected by custom post types. And this won’t be limited to your custom posts.
I’ve already had to edit 4 different plugins I use (2 of them are mine, admittedly) because of the new menu system. It stores the menu items in it as posts with custom post types of “nav-menu-item”. So before I fixed it, making a new menu item would cause the name of that menu item to appear on my Twitter feed. Simple Twitter Connect was seeing a new post get created, and it dutifully published that fact. It simply didn’t expect a “post” to be a “menu item”.
I’ve currently hardcoded the plugins to limit them to seeing actual posts and pages, but that seems a poor solution to me. What if somebody wants to make that “podcast” post type? How is a plugin supposed to know what is really a post and what is not? Overloading the wp_posts table for storage of “not-posts” in this way is confusing and strange and it’s going to break a lot of plugins.
So at the very least, don’t upgrade until your plugins explicitly support 3.0.
The new menu system is clever, but ultimately very limited. I tried it, but I eventually opted to not use it at all.
The problem is that it’s wholly static. Every menu item is a name and a URL, basically. There’s nothing there to make dynamic menus from your content. Like my WordPress Plugins dropdown at the top of the page there. That’s generated by a call to wp_list_pages. Can’t do that with the menu system. And generating a dropdown menu of a given internal list seems, to me, to be a strangely missing piece of the whole thing.
You can make that same menu manually, but if you add a new page, you have to go and manually add it to the menu as well. And that’s all well and good for people who want to micro-manage their site. I’m sure they’ll love it. But I can’t say that I do.
Now, I have been having this argument on the wp-hackers list, so it’s entirely possible that the final release will address more than a few of my above objections. So plugins might be created to fix this issue. Hell, I might create a few of them myself. But in the end, I still find that the underlying design is fundamentally flawed. The system stores menu items as metadata attached to fake posts. In my opinion, that’s just nine kinds of crazy. They should have leveraged the existing widgets system instead, and perhaps have made a new table to hold widget and menu item data together (thus solving the widget data problem and having a place to put menu-items all in one shot). Not everything should be a post.
Okay, yeah, Multi-Site is damn cool, for those of us that run more than one site. But it’s got issues too. Mainly, it’s just complicated.
It’s complicated in that there’s several types of choices to be done. You have to know server configuration. You have to understand DNS and static IP addressing. Knowledge of Apache and VHOSTing helps. And if you’re using multiple domains, which seems like a rather common setup, then you’re into mu-plugin territory, which is wholly new to anybody familiar only with WordPress and not WordPress MU.
Setting up Multi-Site for my two domains required the following steps:
1. Move WordPress to the root of my domain (it really doesn’t work in a subdirectory. Just trust me on this).
2. Enable multisite by editing wp-config.
3. Enable it in the interface, making choices that I didn’t understand. The difference between a subdomain and a subdirectory installation is not immediately apparent, and later turns out to be wholly irrelevant when you use the Domain Mapping plugin anyway. Answer for everybody else: Subdirectory is simpler and requires less configuration, subdomain only works if you have more server control than the average cheap hosting account gives you (static IP, wildcard DNS, VHOST, etc).
4. Copy and paste a whole bunch of stuff that WP spits out into my wp-config and htaccess files.
5. Install the Domain Mapping plugin (manually install, you can’t do this through the happy plugin install interface, because it requires putting files into various directories).
6. Configure the mapping. This is confusing at first, because after you get it working and give it the server IP, you have to actually go to each site’s individual wp-admin in order to map it to a domain. Not hard, but very unclear. Oh, and before you map the domain, make sure that the domain is actually pointing to your server IP, because the mapping takes effect instantly, with no way to undo it. I had to manually edit my database to undo it after I screwed this up the first time.
After all that, there’s still a few bugs. Minor stuff though. The links on dashboard on the main site aren’t quite right. My main site shows individual posts in the /blog directory, with no real way to remove it (it’s hardcoded and deep in the heart of things there’s probably a good reason for it, but it’s still annoying). There’s some other limitations which are too boring to go into.
BTW, if you’re already running MU, then go nuts. This upgrade is perfect for you. It’ll get you onto the main line and that is more important than anything I’m talking about here.
Note that I’m not sure that this is fixable. Multi-Site is complicated by its very nature. Integration of Domain Mapping into the core would help make this a lot simpler and would have the side benefit of eliminating the unnecessary subdomain/subdirectory choice. But ultimately, you do have to have some server-side config to make this sort of thing work, and that’s never going to change.
Not everything is bad
Don’t get me wrong, there’s lots and lots of good stuff here. The Shortlinks API is great. The plugin and theme updaters have been enhanced and moved around proper. A lot of the new theme stuff like the header trickery and the automatic-feed-links and such are very cool.
I like the direction WordPress is heading. I just think that this particular stop on the tracks is not a great one. Too much still unfinished and only halfway thought-out, IMO.
And again, I realize that this is beta code, and I’m not criticizing any of the developers or talented individuals working on it. I get that WP 3.0 is unfinished as of this writing. I’m just trying to look at this from a perspective of an end-user. What’s in this upgrade for the end-user? Ultimately, not very much.
So while 3.0 is a very, very good step in the right direction, it’s a step that that end-users might want to skip over for now. If you’re a WordPress hacker, then go nuts. You’ll be fine with 3.0. But if not, then you might want to hold up a while and wait for the next release instead.
Note that this won’t stop me from upgrading, nor from posting tips/tricks for 3.0 users. Just saying. 🙂
[…] Otto to dutifully inform me 😀 Interesting article by the man himself on the upcoming 3.0 release: http://ottopress.com/2010/my-recomme…s-3-0/#respond Personal blog | Twitter Menu plugin | CSS Generator | Premium Support | New plugin: Code […]
I hadn’t realised there was issues with the new menu system until you mentioned it.
I was planning to be involved with the menu development early on, but it appeared that Scribu was leaps and bounds ahead of me in getting something up and running so I bailed out as it looked like him and others were much more suited to the development of it. Then I heard the Woo menu system was being used, which seemed odd since Scribu’s system appeared to be working fine. But it looks like there were issues with that system which aren’t going to be easy to fix 🙁
Well, it’s not so much that the menuing has issues.. It works, and it does what it pretty much was designed to do. I just don’t like the design very much.
And yeah, I don’t quite get why they went with another system when the widget system was already there. It’s being used for the dashboard, it’s being used for the widgets section, it doesn’t seem like it’d be too difficult to make it do menus as well. I dunno.
The first iteration of Menus was based on widgets, but it didn’t fit so well. Also, we didn’t want to use the options table as storage as we do with widgets. We ended up leveraging the new custom post type bits to implement menus; it was an easy fit code-wise and allowed us to dogfood custom types.
There will be an option to automatically add new pages to the menus before 3.0 ships. We want to preserve a blogging style set-and-forget as much as we can and not turn to the CMS style of having to twiddle things all the time. That said, the most common use case is to put a few pages in the menus and touch them never more. Various ways of auto-generating menus are in consideration but might not make it in 3.0. 3.0 will have Menus 1.0; we’ll keep working on improvements for 3.1 and beyond.
Moving the widgets out of the options table would have been a better solution then. Using post-types as storage is a really strange and annoying way to store menus. Menus are not posts. And finding out that creating a menu caused my Twitter plugin to send a Tweet about the fact that I’d created a new menu was rather disconcerting.
Custom post types is a travesty of a feature if it’s going to be used for general storage. Posts should be *POSTS*. Or Pages. Or anything holding some form of actual human-readable content. Using it as a placeholder for what is essentially metadata is a terrible design decision. This needs to be rethought and reworked ASAP. If it’s still in 3.0, then I’m going to have to continue to recommend people stay with 2.9.2 because of plugin breakage and accidental spamming.
Plugin compatibility with new post types and states has been a problem in several releases. The trash status is an example. 3.0 addresses this with the type and status registration, but plugins won’t be able to benefit from this until they are coded for 3.0.
The posts table has been about more than posts for awhile, but point taken. It has definitely been an area of debate.
Could you clarify this “registration” mechanism? Currently I’ve had to hardcode my plugins to look for “post” or “page” before publishing them. Is there some other way to tell what’s a really legitimate “post” instead of some kind of funky non-post metadata?
I mean, I think it’s more than a little bit stupid to have to have special code to check whether something that you get from the “post_publish” hook is really an actual post. But it could be ameliorated if there’s a way for plugins to tell whether custom types are real posts or fake posts like nav-menu-item.
Yep, multi-site *is* complicated and gets you to look at things differently. 😀 It helps to understand the why things are like that though – it was written to set up a site like wordpress.com, where other users are signing up for blogs.
Now in core, with the current userbase, I’m fairly certain the biggest use-case is managing multiple blogs by one owner. Huge difference there.
While 3.0 was mainly to just get it in there, I’m sure in 3.1 there will be plenty of tweakage.
great review. I already have upgraded from wpmu 2.9.2 to the 3.0 beta1 on a test site and it works surprisingly smooth I must say
Hi, thanks for the insight, really useful to know. I have ugpraded my local site to the 3 beta without any problem. All the plugins I’m using seem to work fine. No problems at all. I had already been thinking about leaving live site upgrades until 3.1 appears. Bearing in mind your comments and the fact that my modest theme is not crying out for the new features offered by 3, I’ll probably wait just a little while before upgrading.
I’m using WP 3.0 and have installed in a subfolder not in root. index is in root. Had to change some files to get it working.
Main difference between WP and WP MU is that MU never had support for site url as WP does. In MU home and site is the same. Which causes some problems.
When you add site support to 3.0 subdomain installations work.
Much thanks for voicing your thoughts, observations and cautions!
There is always two sides to a coin. You have revealed the ugly side of the Woo menu system. Yikes! Thanks for popping the hood and inspecting that menu engine. I probably won’t be taking advantage of a static menu system — egads! For most of my menu implementations, I am using the built-in parent-child relationships for pages (not posts).
I am indeed looking forward to building catalogs with custom post types. For my users, having the right terminology within the menus will make a huge difference. No more answering nor explaining questions like “Why does it say ‘posts’ when we have ‘policies’?
You have always been very wise when it comes to your advice on WordPress, so I will take your advice, and wait til they work out the kinks for my single-user blogs. However, for the multi-user ones, I should upgrade? Why?
If you’re running MU already, then it’s worth upgrading simply to get on the main-line of the code instead of on the side-line where MU has been for so long.
[…] get an understanding of what’s going on.Over on Otto’s blog, he discusses the idea of holding off upgrading to 3.0 when it comes out. Given the hysteria on the support forum whenever a new version […]
The new menu systems dosn’t seem to support a home page link. I don’t hear many people talking about this but the menu system is useless to me if I can’t add a home page to the menu from within the menu builder. All word arounds lead to a home tab that isn’t smart enough to know its active.
[…] to use the Twenty Ten theme already on wordpress.com. At least I in my blog could use it. That new Theme is using a lot of new wordpress 3.0 features so it needs the propper […]
[…] then consider waiting before adopting WordPress 3.0 on your blog. […]
Thanks for sharing your story!
I used to build sites using custom PHP/MySQL and see absolutely no reason to throw all information in the same few tables. Just tear it up in separate tables so it stays clean. Besides, for custom data types there are tools around such as pods cms. Not ideal, but it does the job.
To me it’s good enough if the WordPress core focus stays on posts, pages and comments (the blog-stuff) and keeps the plugin architecture in optima forma (which I found really great) so the community can do the excotic stuff.
Sorry if I post in the wrong section. I am looking for cheap wordpress 3.0 hosting, any advice? I see http://www.asphostportal.com supports wordpress 3.0. Or should I go with HostGator?
Agree totally on CPT (custom post type), extremely difficult to use.