Goodbye Movable Type, Hello WordPress
A few months ago, I silently moved Mike Industries from the aging Movable Type platform to the quicker-developing WordPress platform. I didn’t even plan to change platforms, but after more than a week of trying unsuccessfully to move from Movable Type 3.0 to Movable Type 4.0, this blog was in such a state of disarray under the covers that I began to wonder if switching to WordPress would be quicker altogether.
You see, Movable Type is a platform designed to be static, and only through hackerations with .htaccess files and “bootstrap loaders” can you simulate a truly dynamic publishing system. Part of my move to version 4.0 was designed to use these new dynamic abilities, but in the end, it mucked up so much of my (admittedly custom) setup that I just wanted out completely.
WordPress, in contrast to Movable Type, is designed from the ground up to be dynamic, and through smart caching, it can be made to scale like a static site. This is much the same as how we designed Newsvine to be. As a designer and developer, it just feels a lot cleaner.
So after many years with Movable Type, more than a week of MT 4.0 upgrade attempts, and much assistance from MT’s good shepherd Anil Dash, I called the whole thing off and plotted a WordPress migration instead. Less than two days later, Mike Industries was live on WordPress with only a handful of edge-case issues to resolve (mostly related to inline javascript and php, mime-types, and other custom things I do around here).
Three months in, and now on the newly released WordPress 2.5 (great job on the interface, Happy Cog!), I couldn’t be happier to have made the switch. WordPress certainly isn’t perfect, and if I was starting from scratch, I might have chosen ExpressionEngine instead, but it sure is nice to be on a platform where if I don’t like something, I can just write a few lines of PHP or download a plug-in to address my needs.
Speaking of plug-ins, I’ve already written one of my own that I will release in a few days, but these are the ones I’ve had to install so far (shocking that some of these are even necessary, but oh well):
- Raw HTML – Best plug-in ever. Allows you to wrap PHP/HTML/JS/etc codeblocks in special comments which prevent WordPress from reformatting or encoding them (shocking this is necessary, but a very welcome plug-in)
- Domain Mirror – So that I can use subdomains like “mobile.mikeindustries.com”
- Mint Bird Feeder – So that I can use run my feed through Mint redirects
- Periods in Titles – So that I can use periods in my URLs
- Ping/Track/Comment Count – So I can separate comments from trackbacks from pings
- Subscribe to Comments – So users can receive e-mail notifications when there are new comments
- TextControl – To control how WordPress encodes and adds linebreaks
- WP-Cache – To reduce load on the database and increase scalability
So anyway, that’s about it for now. If you’re on a publishing platform that you don’t love but you’ve got too much inertia to convert to another, take it from me: spend the few days necessary and get it done… it’s not that hard… and I’ve got custom stuff all over the place.
It’s interesting to read which plugins you have had to use. I hope you have good luck with wordpress.
>>”WordPress certainly isn’t perfect, and if I was starting from scratch, I might have chosen Expression Engine instead….”
This is what I’ve ended-up doing for my forthcoming redesign actually Mike.
Having said that, WordPress 2.5 looks fantastic – Happy Cog and Automattic have done some great work with it, and I would certainly recommend it for a blogging CMS.
Huh… and I thought you were on wordpress all along…
I don’t like WordPress even a little, but this is nice-looking in spite of that. Good work.
Please turn off the graphical smilies. Just in case.
Great job on making all this invisible up front Mike. It’s interesting that Movable Type is static, while WordPress is dynamic. Movable implies anything but static, as press implies anything but dynamic by my reckoning.
The new footer says 27 queries. Why that many?
The ones I can understand:
* Get Article
* Get Comments
* Get current Reading
* Get Recent Entries
But then I still have 23 to spare…
Andrew: Oh hell yeah… no graphical smilies around here.
PanMan: Good question. What’s the easiest way to figure that out? :)
Pardon me while I jump in here to defend MT from misconceptions for those who don’t know the flip side of this coin.
MT isn’t an aging platform anymore than WordPress is. MT 4.x is a stable, recent branch that has inspired (if not outright forced) a recent overhaul of WP. But they both continue to release new versions, deprecating old ones, same as with any software or publishing platform. Perhaps your install was aging, but that’s not the platform’s fault. Having problems getting it to do what you want may have been, though, but it’s not like WP doesn’t have a rough upgrade path for some.
If you really want a dynamic site then moving away from MT is certainly going to make you happier, but I wonder what kinds of problems you found so troubling that you moved to an inferior platform to get away from them.
That you have to use caching in order to make WP scale like MT says a lot about its shortcomings, but also its target demographic. I’m sure examples of very high traffic sites running WP can be found, but I’m equally certain that far more examples of MT sites that don’t need resource expensive caching schemes at identical traffic levels are out there. I mean technically speaking as far as server load is concerned, you’re going to exhaust Apache’s ability to serve pages long, long before you run into any limitations inherent to the static publishing model.
I just don’t understand how people can think sacrificing that kind of performance is worth it unless you’re talking about a small site, in which case you could build on top of something as horrendous and bloated as a PHP forum and still get away with it. At that point it’s really just arguing about flavor.
I don’t mean this as a personal attack on you Mike, given your status with Newsvine, but NV is consistently one of the slowest and kludgiest sites I visit, if not the most. It’s been that way since I signed up and people I’ve spoken with agree (though obviously not unanimously), so I don’t think it’s just me. NV is something I use as an example of how badly dynamic sites scale and how unnecessary they generally are, second only (generically) to WordPress.
Glaringly — and this is something you’ll probably run into at some point here at DH — is how a database failure of any level can wipe your site right off the Internet for the duration. This simply doesn’t happen with the static publishing model. Sure, you lose the ability to accept comments and publish new posts, but otherwise your entire site remains intact. Users won’t be turned off by non-existent content, search engines won’t record a 404 that can take a long time to refresh.
This site serves about 1 million views per month and I guarantee that you’d never end up with this happening to you with MT or any other static platform. You’re well aware of this, I know you are because of what you do, and yet you choose to live and die by that sword anyway. That just seems crazy to me.
And I would point out as an example of how ridiculous it is to build a dynamic site around mostly non-transient data; look at your footer: “27 queries. 0.388 seconds.”
One page view hit the database *27* times to build this page, and it took over a third of a second to do it not including the processing time spent by Apache itself. A second page load while writing this comment came back with a page build time of 0.426 seconds and another at .5 seconds flat) — nearly half a second. While I realize that is going to depend heavily on web server and database server load (especially with shared hosting at DH) it’s incomparable to a static site that doesn’t need to build pages, or query a database at all.
I understand that people hate the amount of time to takes to republish an entire MT site, but the performance advantage is unquestionable. For every page view, you’re eating apparently between .3 and .4 seconds. The last time I republished my blog, it took about 229 seconds real-time (43 seconds cpu-time) for 600+ posts and about 180 comments. For CPU time, you’ll exceed what it takes to statically publish 600 posts within 110 page views, and with the popularity of this site based on just a guess, I assume you blow past that every couple of hours if not faster.
I’d love to see what kind of resources you’re using right now from running WP. I know DH allows you to turn on logging for that in the panel; might you be willing to do that so I can see just how bad it really is?
This isn’t even addressing memory usage, where the last I heard WP uses in excess of 100MB to answer a single request, before dying off. That’s actually getting pretty darn close to what DH allows before they still killing off processes (I’ve got a lot of experience with that, sadly, due to fast cgi.)
An interface, I might add, that is heavily inspired by MT 4. Indeed, virtually every new major feature in 2.5 is catch-up from MT that I’ve had available and have been using for something like 8 months now. Glad you’re happy with the switch, though. All things considered, CMS’ are like a Linux distro or anything else; as long as it gets the job done..
Well since you can just as easily change a few lines of PERL to get results in MT, and since MT has plenty of plugins, I’m not seeing how any of that is actually a benefit. Sounds like par for the course with just about any CMS, unless I’m missing something?
(note: You know I love you sir, so be gentle with me.)
PanMan – there are other things going on, such as reading user permissions (if a user is logged in) and reading plugin prefs, which are stored in the db.
Mike – wordpress uses ezsql (or used to at least!), so you could probably just edit the class and put a simple logger in place.
Welcome to the wordpress world Mike. I too made the change, though in my case it was 3 years ago and I too was fed up with mongrelized nasty backend hackery and also switched from Movable Type.
Interesting list of plugins, a few of those I didn’t even know about (periods in titles) I would say that if you haven’t heard of it there is a great theme called “iWPhone” that might help make your mobile usage a little easier.
Also if you haven’t yet added a iphone/touch webclip icon there’s a plugin called “iphone webclip manager” I just released today on my blog. There’s also a few of us Pacific Northwest folks that just wrote a 5 must have plugins post.
Didn’t intend for this to be quite the huge comment it turned into but again welcome.
Welcome to WordPress! I made the Movable Type –> WordPress switch years ago (before WordPress 1.0 even) and never regretted it one moment.
I set up WordPress for a client (www.cdpom.com/news) with very little customization and an article page generates 14 queries in 15 queries in about 0.3 seconds.
If you’re on a dedicated server you can set up query logging on MySQL for a short time and then have a look at the file to see what’s going on.
PS: Note the sIFR on that site – I’m very grateful for your work on this Mike!
Sorry, typo in above comment. Should read “14 queries in” only.
“I can just write a few lines of PHP or download a plug-in to address my needs”
Congrats on the switch from MT, but I wouldn’t expect to just write ‘a few lines of PHP’ in WP. Even the developers seem to like to write a lot more code, duplicate things, mix things, make it all look like spaghetti code. Plugins are a little easier, but hacking away isn’t fun with WP (you can do it, it just isn’t fun).
I wish they would have had someone re-build the code alongside the great new interface.
Did you have a look at TextPattern?
What Nate says about use of PHP within WP is the reason why I chose it over WordPress. With TextPattern you have quite a few tags (eg: can you can use within your templates and content. Many of these allow for if / then type conditions so even a non-programmer can add clever logic to pages.
I guess that most bloggers are not interested in adding complexity to their site. But for those who want to extent their blog TextPattern is a gerat choice.
I had the same question about Textpattern. I have used WordPress and never have been quite as intrigued, but I see amazing work with people using it. This could come from using Textpattern for so long… and knowing it so well…
For a new site I am curious why WP over TxP ?
Interesting… I’m echoing David’s thoughts in that I thought you were running this on WordPress long ago. Just for quick and dirty side projects up until now, huh?
Paul: Holy crap that’s a long comment.
1. MT *is* an aging platform, and it *isn’t* developing as fast at WordPress is. One of my most disappointing moments with MT was when I downloaded version 4.0 for the first time and expected to see old parts I hate rewritten by new parts I love. They weren’t. The codebase looked more or less the same as it’s always been. Ability to write out files with .php extensions and refer to them in the CMS without the extensions? Nope, still can’t do that. Ability to have the search results pages be standard dynamic PHP pages like the rest of my pages? Nope, still can’t do that. Ability for the interface to move along and let me continue my work after deleting a comment, rather than keep me waiting through the rebuild? Nope, still can’t do that. In short, I had like only 5 problems I prayed MT4 would solve and it solved none of them. *None*. The pace of development at WordPress and the general shape things are in as compared to how they should be is just much better.
2. I wouldn’t consider WordPress’ caching scheme expensive at all… or even a shortcoming. You hit a page, the page goes into cache for X seconds, and every time it’s hit for the next X seconds, it comes from the cache. That’s how it *should* be, in my opinion. That “X queries. Y seconds.” line was only how long the uncached query took.
3. Regarding Newsvine, well hey, that’s what happens when you have a site with literally an unlimited number of pages (unlike a blog, or even a mega news site like MSNBC) that you have to try and cache constantly across only about six servers. A herculean task for anyone, let alone a company building an actual product at the same time as building the proprietary caching system. The site’s probably about 80% faster than it was six months ago due to continuing advancing in the way we cache.
4. I agree with you that having a site full of statically published files is better insulated against server failures. That, to me, is MT’s biggest advantage, but since 99% uptime is just fine with me, I don’t really care that much. If I’m down for a few minutes every month, so be it. This goes to your question of target audience. “It’s just my blog”. :)
5. I also wouldn’t argue with you about resource usage in WP vs. MT. I simply don’t care about that. It hasn’t posed any problems for me, and if it does, maybe I upgrade from my $15 a month plan. :)
6. Regarding hacking on PHP vs. hacking on Perl. I don’t know Perl. And I don’t like to hack on things I don’t know. Again, target audience. Also — and this is very important — I found that with MT, I was adding hacks into many, many files all over the place to get things the way I wanted them. This caused constant headaches when upgrading. With WP plug-ins, I just overwrite an existing function from a plug-in, and bam, my core codebase is still clean.
Hi Mike,
You definitely made a great choice. I think you will find exporting and backing up your data much easier as well. Welcome to WP!
Aww, that makes me feel guilty for not having updated TextControl in … 3 years?! Good lord!
I’m amazed it still works in WP2.5 — when I wrote this it must have been WP1.5.
—
As for the whole “wordpress can’t survive a large hit” thing — that’s absolutely untrue, as I can testify to surviving a 3000 hit digg’ing just a week or two ago. The only issue I had was Apache failing to serve requests — NOT wordpress’ fault (keep-alive was too high).
What is true is that a WP site is not setup for a “digg-like” survival without plugins. Plugins which add static file caching of pages which rebuild on actions just like MT. So if you’re expecting your site to be high traffic hit (all 1% of you), you’ll have to do your homework (read: install a single plugin.) For the other 99% of people, they can live with a .5 second delay on page rendering instead of constantly waiting through the 5 minute “watch the browser wheels spin” routine. Which of those two reactions do you think users would prefer? I certainly have my choice…
Ah ha, I see you left out that you are already up on the WP-Cache bandwagon.
;D
Mike, woohoo! You can’t tell how big the smile on my face is right now.
Paul, you’re obviously super-passionate about the way MT works, and many of the things you said would have been true a few years ago, but the state of the web (and WP) has advanced a lot.
1. Dynamic + caching is not expensive or archaic. I can’t think of a single modern website that rebuilds and pushes out static files like MT does, where WP’s model is the same used by Flickr, Digg, Facebook, Wikipedia, WordPress.com (600m PVs this month), Youtube… All of those save Youtube use PHP + MySQL as well, and WordPress.com runs on the same core platform Mike is running right here.
2. With WordPress, WP-Cache, and a cheap server you can serve 25.9 million pageviews a day. There’s a new one out called WP Super Cache which bypasses PHP altogether which means it serves even when the database is down, just like MT, and should be even faster. These don’t slow down publishing or commenting at all, and most people have told me that dropping the plugin in their install and clicking “activate” is easier for them than trying to navigate setting up fastcgi or complex rebuildqueue processes and cron jobs with MT, which also delays changes from showing up.
3. It’s fantastic you have a site at 1 million pageviews a day, most weblogs never reach that, but to put that in perspective it’s not even one request per second, it’s a pageview every 2.59 seconds. You can serve that from an iPhone. (Though it would get hot in your pocket. :)) Huge celebrity sites like Perez Hilton (formerly on MT) and People Magazine’s blogs run WP, I assume they’re also comfortable with the issues you mention.
4. Our interface was not a copy of MT4, most of it was designed before MT4 was released. Happy Cog would never plagiarize someone’s work. Our features our entirely driven by our users, not by competitors. MT is credited on our about page because it provided early inspiration around their 2.x days. I think the ideas flow both ways, for example if you look at the Pages feature in MT4 and the XML-RPC APIs around it you’ll see they start with “wp.” But going back and forth on feature checkboxes is boring and if you compete like that you end up with Lotus Notes, it’s far more interesting to look at stories like Mike’s, large publishers like CNN, NY Times, Fox, CNET, WSJ, or the changing makeup of the Technorati 100 over time.
You’re obviously happy with your setup and I’m not trying to get you to change. If it ain’t broke don’t fix it. Just wanted to clear up a few of the more common misconceptions people often have.
Jeff: Good point. I actually left WP-Cache out of the plug-ins list because it was already installed by default on Dreamhost. I’ll add it to the list right now.
27 queries. 31.112 seconds.
..
That was quite a long time to wait!
For what it’s worth, WP Super Cache is an improvement on the original WP-Cache.
As Adam says, when one consider things like user permissions, the recent entries listing, and so on, the queries just add up. That’s the penalty of a complex, dynamic application. A fair bit of work has gone into improving WP’s performance over the last couple of release cycles.
Plus, of course, you’re running it on Dreamhost. I have a few sites running on there myself, and while it has several excellent qualities (the price, mainly, but their support isn’t bad either and the control panel is nice and comprehensive) it’s not exactly a performance powerhouse. My personal site runs on a VPS, and generating a similar page (comments, recent entries, around the same number of queries) takes around 0.15 seconds.
Mike
You actually like the new admin interface of WordPress?
I wish they would have contracted Steve Smith of Ordered List who designed the *beautiful* Tiger WordPress admin interface … something like 3 years ago.
[…] a momentary refresher course of what my plugin installation looked like, I added a few more from Mike D’s list and I’m off and […]
Benedict: Thanks for the tip about Super Cache. I’ll try that out.
Chad: I was using the Tiger Admin theme before 2.5 came out and I liked it too. The problem was that the underlying code wasn’t very clean though so the interface couldn’t be all that it should have been. 2.5 is super nice, to my eyes at least.
Mike Since you liked the Tiger Admin Theme I’d also suggest you give Fluency Admin a try. It’s still only about 99% but it vastly improves the admin interface.
I’ll also chime in on Super WP-Cache being the better way to go. I’ve tested it on a client’s site that had fallen prey to the slashdot effect and it stayed up (slowly) running on a cheap dreamhost plan.
Also contrary to what was sadi earlier developing plugins can be done with just a few lines of php. The plugin framework just keeps getting better and better.
I’ve been enjoying WordPress for a bunch of client sites. Though I also like Textpattern… I find different projects sometimes work well with different apps.
You wanna talk scary “footer stats?” 27 is nothing. ;-) I once fixed an archive plugin that was using one query to get grouped listings of posts. And then a second query for EACH POST to count comments (if you enabled it). Yeah, hundreds of queries, growing larger for each post. Scary.
Welcome to the club Mike. Good luck keeping those queries down. ;-)
Let me try taking these one person at a time.
Hi Matt, it’s nice to run into you. I don’t have any kind of affinity for MT because it’s MT, but because I believe the static publishing model for 99% of cases (at 100% of online publishing cases) is superior. Let me in turn address your points.
Flickr is another site notorious for being slow and unreliable. Perhaps that’s due to poor coding skills, or perhaps that’s due to relying on an inappropriate publishing model because most of the pioneers for services like that simply didn’t know any better when they started out.
While I can’t speak for most of these sites, I have little doubt that they all sit behind load balanced caching servers like squid precisely because the dynamic model can’t handle the load. If anything, your examples prove my point. Whether it’s squid or a plug-in that caches recently generated pages in memory, it’s still turning to static publishing at some point to make up for the inability to keep up with demand.
There’s nothing wrong with scripting when and where it’s appropriate. On the backend, certainly. Dealing with user input, certainly. To serve a page that most likely will not change more than a few times per day (if that on 99% of the world’s WP installs) is not.
I don’t doubt that you can serve 25 million pageviews a day from a dedicated server if you throw enough hardware at the problem. I’m making two points about that.
1. The traffic level at which you have no choice but to do this is far lower for dynamic publishing than static.
2. Throwing bigger hardware at a fundamentally flawed design is not a solution, it’s a hack.
But since all I see on the page you provided are slides that amount to talking points, it’s hard to see the value in anything they claim. There’s no information on methodology, the actual test results, or even hardware specs. Obviously that’s the point of slides since that kind of information would be presented by the speaker (one would hope) but until you provide that, then I don’t see as how I can believe anything presented there.
You understand, I’m sure, that I’m expressing healthy skepticism, not being paranoid. I asked Mike if he would begin logging his resource usage (something our host Dreamhost provides for free) so I could provide a specific instance of what I consider to be an abuse of resources, but he declined — which is fine — but I’d like a little more from you if you’re going to point to something like this as if it’s some kind of evidence in favor of your argument.
Certainly, working with cron and fastcgi are for moderate-to-advanced users which simply means working with cron and fastcgi are for moderate-to-advanced users. It doesn’t signify a flaw or performance bottleneck; in fact this is really nothing but a marketing argument in the middle of a discussion on dynamic-vs-static publishing.
I don’t see the relevance here, nor do I think most users who turn on these plug-ins truly understand what they are doing and why.
Just to clarify:
1. DHD is not mine.
2. 1 million pageviews per day is 11.57 per second, not 1 every 2.59 seconds.
3. I said 1 million per month, not day, which is .37 requests every second, which is what I think you were trying to say since that fits with your 1/2.59 math.
Still, using Mike’s blog as an example, that’s nearly half a second of CPU time used every 2.6 seconds. Without the caching bandaid, that’s crushing.
I seriously doubt you can serve a request from an iPhone that needs close to — or more than — 100MB of memory. This kind of rhetoric is not helpful, nor is it accurate.
I wouldn’t make that assumption, I’ve seen a number of people who run XXX who are terribly unhappy with it, but for varying reasons cannot or will not do anything about it. Cost in hardware, in man-hours, in fighting bureaucratic barricades, on and on. I also wonder what these organizations might say if you told them they could double their ability to serve pages (if not more) if they moved to a static model, without spending money on doubling the hardware.
This falls back to what I was saying about solutions versus hacks. How much hardware do those places have to throw at WordPress in order to make it work under their load that they wouldn’t need under a different architecture?
I started using MT4 in July of last year, which means that interface was under development for months before that, well over a year in total probably. Are you saying the WP 2.5 interface has been under wraps for longer than that? If so, I concede the point. If not..
..there’s a difference between arguing plagiarism (which doesn’t apply to designs and wasn’t something I even mentioned) and inspiration from a superior design. You may not think one descends from the other, but the first reviews I’ve seen of the 2.5 interface point this out right away.
That’s unfortunate, as I would hope you’d be driven by both of them since that would give you not just what your current base wants, but what your competitor’s users want as well — requisite in acquiring them and their “business.”
This was never about comparing feature sets. I realize it’s beneficial to you to expand the debate so you can avoid actually talking about these specific performance issues, but I’m not at all interested in that. This for me is about static-vs-dynamic publishing, not XML-RPC, or comment feeds, or OpenID, or any of that junk.
Those are toys, this is about the publishing core.
I can just as easily list big sites using static models, but how long until we get down to the meat of it and look at how much hardware you have to throw at dynamic sites that you don’t need with static sites that use a dynamic backend? That’s what matters here.
I’m unhappy with MT, it’s just not fast enough when when rebuilding the entire site. I managed to peal off 66% of the build time by juggling my templates and that’s very good, but not good enough. I can build tools in a lot of different languages so I know damn well there’s plenty of speed to be found in this platform and I’m angry it hasn’t been found yet.
There are memory leaks that cause the persistent process to be continually killed under fcgi that are only just now getting fixed and are only available as a patch. That’s a painful problem under a shared hosting environment, but it doesn’t even compare to what WordPress will do to a machine without caching, but active caching in memory?
It’s practically a prerequisite to run WP these days, lest you want to be forced to go dedicated.
I know most people like to turn these things into WP-user vs. MT-user, but that’s not interesting to me. The caching is nifty, but it’s a solution for a problem that exists only because of the dynamic model.
Moving on..
Hey Mike,
MT4 is under active development to increase performance, introduce new features, and enhance the UI, same as WP is. The 2.5 WP UI update is a clear indicator of how MT is driving the market forward again. The open source branch is open to submission anytime you feel like contributing your own changes, something perhaps not available under 3.0 but is now ready. I mention this because many people aren’t aware of the open source branch.
Have you considered improving these parts of the code you’re not satisfied with? Have you contacted Sixapart or anyone in the MT community requesting changes be made? Is that scenario going to play out any differently with WP if you don’t submit code or ask the community to address problems you’re having?
Since the entire point of MT is static publishing, I’m not surprised they aren’t spending a lot of time building something into their platform that would make it slower. I get that dynamic is what you want, and I’m not saying you or anyone else should be forced to use something you don’t want to. This is simply me saying people typically move to WP for reasons that amount to little more than flavor over substance and that MT (like Java) continues to get an unfair reputation for things that simply aren’t true.
Not sure what you mean, can you clarify?
‘LaunchBackgroundTasks 1‘ in mt-config.cgi. Been there since at least 3.x if not longer. Launches the active task into background allowing the interface to continue without waiting. Also available with the Schwartz publishing framework if you turn it on (requires a very simple cron job, the former doesn’t.) The queue is being retooled in the 4.x open source branch so it’ll be interesting to see where they go with that, but otherwise this is a pretty stark example of what I’m talking about.
You’ve had the solution just 1 config setting away all this time and yet you blame 6A for not “fixing” it.
I can’t address all five without knowing what they are, but at least one of those ‘problems’ never existed. One question on the 6A forums about this would have resulted in you finding out about this config setting. It’s like I said, you can’t expect someone to fix a problem if you aren’t willing to let them know it exists. Praying, if you will, isn’t going to get anything magically fixed in WP either.
Assuming it was actually cached. I hit that page three times over the course of the writing my first comment and that number changed every single time, indicating it was either being cached and dropped often, or my hits were bringing it into the cache in the first place. When I loaded the page for *this* comment, the number was over half a second. As for caching not being expensive, I suppose that depends on where that data is being stored. Memory? For any large site, that’s obviously the most precious resource on the entire machine. I call that expensive, not in monetary terms, but in finite resource terms.
Terms that don’t exist at all with static publishing. That memory either on disk, database, or RAM is going to be free to do other things that will keep the site happy on any set of given hardware for much longer.
This isn’t an argument against caching in general, but these plug-ins are a direct response to WP (dynamic publishing) not being capable of serving high loads on its own. How is that anything but a hack to make up for a deficiency when other platforms clearly don’t need caching at all?
You know your system better than I do, but I can’t imagine going from dynamic with caching to static publishing wouldn’t result in a lower load and a less complex system. You and other sites/people/projects have to spend time tuning, retuning, and inventing new caching systems all in service of making up for a backend that can’t handle the load on its own. It’s like the ASRG (Anti-Spam Research Group) efforts to add an anti-spam layer onto a 20+ year old mailing system that was never designed for it. You can do it with enough effort and expense but at some point you’re getting awfully close to resorting to using a nuclear bomb to force a square peg into a round hole instead of just using a round peg in the first place.
The problem is that people think in percentages where 99% sounds great, but fail to consider what 99% actually means. I don’t know what kind of traffic you get, but let me use DHD as an example again. That site receives roughly 30-40k pageviews per day, and went down for a solid hour (as you can see in my screenshot from my comment above) because of a database failure of some sort. Even if that is the only downtime such that it could be considered a 99% site, that’s still a loss of 1500 views. For something larger like flickr which has regular failures or an extended failure in a file server cluster, we could be talking about tens of thousands of views lost.
99% sounds good except to those 1500 people that came to your site looking for something to read and wound up going someplace else after finding an obscure error message. Perhaps that doesn’t matter on a small site with a hobbyist mentality, but that’s not the way it has to be.
There was a failure at Dreamhost last year of the database server I’m assigned to where many WP and PHPBB users were just wiped right off the Internet for over 6 hours. My site couldn’t be updated remotely (with a local install I could have posted locally and simply ftp/rsync’ed the new files over which I believe the Schwartz framework supports with rsync) and remained available to users. That means a heck of a lot to people who are running more than “just their blog” and it’s not something WP can readily address.
That is unless WP supports something like SQLite, in which case at least there’s that (I’m very fond of SQLite, btw.)
I’m sure a lot of people say that, but I’d ask Matt if he really wants his user base to say it because I’d find it extremely unsettling. “If WP gets any more bloated such that it’s not viable on shared hosting, I’ll just pay money to make the problem go away.” I’d venture to guess the answer is no, but from what I understand that’s precisely what’s going to happen. A friend of mine that works at DH tells me they are really unhappy behind the scenes with the resources WP uses and while I’m sure they’ll continue supporting it for now, it speaks volumes about its shortcomings and its delicate position in the share hosting business.
I’ve even seen Dreamhost turn on static publishing for their status blog during outages that generated heavy customer traffic.
Think about that.
Certainly something to consider. What kind of hacks are we talking about? The only thing I’ve ever had to change within MT itself was accomplished with a simple plug-in I wrote in about 5 minutes.
Jeff,
3000 pageviews is minuscule, even for WordPress. Though social bookmarking sites send traffic in clumps which can cause things to slow down, I’m generally talking about sustained levels of high traffic. 3000 views for instance over the course of an hour isn’t quite one per second. A “large hit” would be substantially larger, and in fact 3000 doesn’t sound anything close to what you’d get if you hit the front page of Digg. I’m not saying you didn’t get the traffic, but that in all likelihood you barely scratched the surface of what sites like that can throw.
This isn’t a question of setup, but of design. WP cannot handle high levels of traffic without being transformed from fully dynamic into a dynamic-static hybrid, which in my mind reveals a fundamental flaw in its design. The best compromise is a fully dynamic backend where there is a critical need for real-time data aggregation and responsiveness but very low traffic, with a fully static frontend (and designed as such that it doesn’t require a circus to accomplish) that requires very little to no “live” data but very high levels of traffic.
Active memory caching which still accrues PHP overhead to manage is still far more work to go through than Apache will ever encounter simply reading static HTML off the disk.
Unless you get into such high traffic that you’re using Squid or some other load balancing cache that sticks it all in memory anyway, but at that point your infrastructure is going to be able to support doing the entire thing in BASIC if your really wanted to.
I rebuild my entire site less than once per month, so “constantly” is hardly accurate. The last rebuild ran for about 249 seconds for 600 posts and 180 comments (plus archive and category pages) and most of that was due to an overloaded MySQL server. If you measure it in actual CPU time, the number is 43.8 seconds. If we assume 250 pageviews per day and WP eats .5 seconds to build each one, then we’re talking 3875 seconds (just over 1 hour) per month in comparison.
And the thing is my number doesn’t change with the level of traffic, while the WP site does. I can see the caching becoming more efficient as the load increases, but ultimately the caching is still going to slow the entire process down compared to static publishing, and that’s kind of the point.
Now this doesn’t count the CPU usage for the MT backend (post and management incursion) because I don’t have that information sitting in front of me but I’d be happy to look it up and throw it in for comparison if anyone is curious. This “watch the browser wheels spin” stuff is pure myth unless you edit your template every single day, and at 5 minutes (which is done entirely in the background on any respectably managed site) it’s still 1/15th the time WP users spend waiting for the page to build over any given period of time.
Depends on which user. If you’re talking about the CMS administrator, since all of the important MT stuff is done in the background, I’d say the experience is generally the same. If you’re talking about site readers, then you’re asking which would they prefer: A page that takes .5 seconds to build before they can see it, or a page that takes .000 seconds?
I know what my choice is.
Martin,
In all fairness, that’s entirely the result of an overloaded shared server or a problem within the Dreamhost network. It happens all the time in shared hosting environments. Unfortunately for dynamic sites when there is a processing shortage, PHP has to fight with Apache for resources so they both slow down, or — in the case of network issues — sit and wait for MySQL usage to relax. This doesn’t happen on static sites.
I’ve had instances where my shared server was running with a 5-minute load average over 100 and still had my pages delivered like it was 0.00. In those cases the MT backend will puke just like WP will, but only the backend. Pages still serve up fast and reliably.
I’d like to see that happen with a WP site.
“This for me is about static-vs-dynamic publishing, not XML-RPC, or comment feeds, or OpenID, or any of that junk.
Those are toys, this is about the publishing core.”
I hope you didn’t actually intend to denigrate the hard work that’s gone into XML-RPC fostering a greater ability to utilize different disparate hardware or OpenID which helps to simplify and secure account management as mere toys. The shortsighted statement you’ve made makes me question the veracity of every claim you make. Especially when you take the position of an proponent of MT at the same time you yourself decry it’s issues.
Failure to recognize and shortchange the changing nature and flexibility of new tools for the digital medium while complaining about the old tools is very shortsighted and frankly undermines the hard work (much of which is not paid work) by the thousands of volunteer developers who have brought easy to use flexible software to the masses.
Just my two cents.
Hi Paul. Responding to that comment and all one million things in it that I disagree with would take me at least an hour, which I unfortunately don’t have right now, but I can sum up exactly why I disagree diametrically with you by mentioning only two of your points:
I don’t get it. That’s kind of like saying “umbrellas are nifty, but they only exist because of rain”. Caching is the very reason why dynamic publishing is becoming more popular than static publishing these days. If you want to argue that it’s smarter to run static publishing than it is to run uncached dynamic publishing, then we don’t even need to have this argument. I would never run an uncached version of WordPress on Dreamhost or any other host for that matter. But it’s a false dichotomy you’re creating by trying to cast server-side caching as some sort of ragged band-aid. The question isn’t “static vs. dynamic”. The question is “static plus optimization vs. dynamic plus optimization”. That’s what matters in the real-world.
If this is actually true, then Movable Type is a much, much worse piece of software than anyone imagined. If “the entire point” of a piece of software is a detail related to its implementation, then it is of little use at all to me. Fortunately, I don’t believe your statement to be true, and instead, I believe that the entire point of Movable Type is to provide a personal publishing system that is best for the author and the end user by whatever means necessary. That could mean static publishing, dynamic publishing, or some combination of both. The fact of the matter is that SixApart *is* spending a lot of time increasing MT’s dynamic publishing abilites. They aren’t doing it because it’s the wrong thing to do. They are doing it because it is increasingly the *right* thing to do, in a lot of circumstances.
And just some miscellaneous extras because I couldn’t resist —
1. I do not know Flickr to be slow and unreliable. I actually know it to be one of the shining successes in how to scale early and vigorously.
2. I didn’t decline any request from you to log resource usage.
3. You bring up the fact that MT is now (practically by necessity) open source, but I don’t see nearly the effort by the community to improve the software as I see with WordPress. You can’t just fling open the open source doors and hope to have a thriving community improving code for you. My guess is that contributors to WordPress will continue to grow while the MT core will continue to stagnate for lack of widespread interest. Just a guess. I could be wrong.
4. Yes, I have improved parts of MT, and yes I have been in contact with staff.
5. LaunchBackgroundTasks does *not* solve the problem of waiting for rebuilds when you delete comments. At least it didn’t when I tried it… and this was confirmed by Anil. Don’t assume I’m an idiot, please. :)
6. The reason you were probably hitting uncached pages here is that you hit a URL with a comment named anchor on the end of it. My version is configured this way so when you post a comment, you get a fresh copy. Hitting the front page or any individual page normally will not produce what you described.
7. I don’t think you heard me about Newsvine. Please re-read the sentence about “infinite number of pages” and tell me how you write out infinity static files. K.
That’s all for now…
Here’s a guy running Apache + PHP on his iPhone.
Paul: Ok. I just found my CPU reports. They’ve been enabled the whole time. You said —
Yesterday, I used 221.84 seconds of CPU time at Dreamhost to serve 4,853 pageviews. I don’t know whether that’s good or bad, but it seems fine to me. I don’t care if static publishing could shave a few seconds off of that. It’s four minutes of CPU time to serve a typical weekend day’s worth of traffic. Even when my traffic spikes to 10x that because of linkage, who cares? 40 minutes? Probably less actually because most people would be hitting a cached page.
Mike,
In fairness then, I came to this page with no comment anchor and so should be (supposedly) cached. 29 queries (two more than last time), and 0.749 seconds. I don’t see a difference at this time of night even though the server load ought to be at its lowest in my experience with DH. If anything, the CPU time required to build this page keeps getting worse every time I see it.
I think my observations of actual usage is fair considering I what I’ve got to go by, but would be more so with the actual data.
Alright, you ignored it outright. Not sure how that’s better, but I suppose it is more accurate.
..and..
We don’t know each other so I don’t know if you’re that, or an outright genius. Perhaps somewhere in between, or even a little of both. Who knows.
I’d love nothing more than to assume you’re the smartest person in the world, but when you make claims like #7, it’s hard to assume good things because it’s complete and utter obfuscational nonsense. Newsvine is a blog network in the functional sense that draws posts, comments, and other misc data from a database just like any other CMS, and presents it as HTML with some sort of scripting engine — in your case it’s what, ASP? — as a series of pages with unnested comments. It’s not magical or special or different than a lot of what is already out there (and right here on this site), so if you want me to treat you with respect, how about respecting my intelligence a little by not feeding me this “we have infinite pages” stuff.
I may not be a software engineer and I may not have ever seen your code, but I know better than that.
You have a finite number of articles, comments, users, votes, and other information at any given moment in time just like you’ve got in your WP database, which can be boiled down to a finite number of statically-published files and presented in a finite number of ways. Worst case scenario you’ll have to use server-side includes or AJAX (more extensively than you are now but overall a lower load than all the constant scrip interpretation going on) to pull in some of the more transient data.
I’ve considered doing precisely that for my sidebar which would mean only republishing 1 file instead of 600, but so far haven’t really found the burning need. Those who do have plenty of options open.
Perhaps there is some wisdom in taking very rarely requested pages and only serving them dynamically, but for anything that gets hit more than a few times a day, it’s going backwards.
Beyond that, you’ll have to do better to convince me that using a dynamic-backend and truly static frontend is somehow impossible for NV, or at least undesirable for a reason that is a bit more substantive than opinion (of which obviously I’m presenting aplenty, but not all.) Please don’t take offense at that — I’m not ordering you to convince me of this, or that, or do anything. This is just my way of saying that I went back, re-read it, and it’s still nonsense, and everything above isn’t helping the cause.
As for the rest, I’ll try to hit it tomorrow/Tuesday if I can. Thanks for the talk-back, it’s always enlightening.
Shocking. It’s like you’ve never even used the site. And yet since you’ve left hundreds of comments on it, we both know you have. Let me repeat once again: there are an unlimited number of pages on Newsvine. Newsvine dot com slash *anything* resolves to a page, if anything has ever been tagged as such. Let’s try some examples, shall we?
newsvine.com/christian-rock
newsvine.com/root-beer-kegger
newsvine.com/humuhumunukUnukuapuaa
I could go on and on but it would take me — guess what — an infinite amount of time! It’s not just Newsvine that is this way. It’s also Delicious. It’s also Flickr. And it’s also any other well-written site which provides extensive tagging capabilities.
As Chris said above, it’s very hard to believe in the veracity of any of your claims when you get this sort of thing wrong.
On the bright side, you did officially set the record for longest comment ever in 5 years of running this blog! I’m not being sarcastic at all when I say congratulations. Seriously. I think that’s really cool. And I still like you too!
Mike,
It certainly doesn’t jive with what WordPress is reporting about the time it takes to build the page, so I’m going to venture a guess that WP isn’t reporting CPU time, but total time from the moment the script beings processing to the moment (or slightly before) it terminates (which, Matt, is less than useless IMHO.) If for example it takes .1 second of CPU time to put the page together but WP has to wait .5 seconds to get data from MySQL (which I find extremely likely given how slow my own assigned database server is at Dreamhost) then it’s going to inflate the time.
That makes sense with what I see here and while it totally blows a lot of what I’m saying out of the water, it’s exactly why I wanted to see the data. I’m not above a mea culpa here — I was way off with what the real numbers were and you can’t get much more wrong than that.
But like I said, that’s why I wanted the data.
Now that you’ve explained what you meant, I understand but strongly disagree with how you’re describing it — naturally. You’re essentially catching non-existent pages with one existing dynamic page that makes it look like the thing somebody is looking for really exists when it doesn’t. That’s not a lot different than what anyone else does — any 404’s on my site are sent to a single custom 404 page that could just as easily be populated with the sidebar, the headlines, any logged-in user links, and an invitation to write something on the page that makes it look like there was already a page there. There’s nothing new or special about that, as you said, many sites do that.
It even wouldn’t take much to make Apache return something other than a 404 (if you use Apache, which I assume you do no.) like a 200.
That is something you can still easily do with a statically published site. I mean heck, MT still uses dynamic pages for some things like searching the site, but only where it’s appropriate and necessary to cull live data. It wouldn’t take much to have 404’s redirected to the search page and do basically the same thing, unless there is something more to it than that, it seems kind of strange to claim that this kind of behavior means that a site has an infinite number of pages and therefore such a site is incapable of being published statically.
Contrary to what it must sound like, I am not saying dynamic pages have no place in the world. I’m saying that ever since PHP became popular, the tendency has been to make everything dynamic first and throw out every principle of scalable web design known to man just because we can. I’ve not once heard a sound reason why post pages with comments should ever be published dynamically other than because a coder wanted it that way.
Oh, there have been some “reasons” and I readily acknowledge those, but sound ones? Haven’t seen ’em.
WP to me represents the worst in this trend of making things fully dynamic just because we can, at the cost of performance and the ability to fail safely. The two opposing arguments here are when you break them down, not about design methodology since one is clearly superior to the other, but one of User vs. Designer.
The designer will make it fast, fuel efficient, and reliable. The user will want it red, comfortable, and reliable. If you have to cross the line between the two, as a personal preference, I’m always going to take the one that keeps me online while other people are left staring at database error pages and wondering why they have to pay twice as much as the next guy for hosting costs because when traffic gets serious, so does their resource usage.
Other than on the CPU usage (note: I didn’t start throwing out numbers until after it seemed like I wasn’t going to see any actual data on CPU usage and had to start guessing), just what have I gotten wrong here?
I’m sure I can dig up something I read not too long ago about how supposedly notoriously bad flickr was designed on the backend, what a nightmare it is to work on, and why Yahoo! refuses to spend a dime on what they think is probably a page-1 rewrite job.
Likewise, you hear the same stories about Twitter all the same because it is built entirely on rails.
I can’t speak on Delicious, I have absolutely zero operational knowledge of that site.
It has nothing to do with the language or the coder or sites that throw hundreds of thousands of dollars worth of hardware at CPU gobblers, and everything to do with recognizing that it’s just not necessary. That most people seem to think that Flickr is a stable site and an example of how dynamic sites can work is a real testament to how you can make anything look good with enough hardware.
Cool, it’s all in the spirit of hashing out differing points of view on technology.
Matt,
Thanks for dropping by my blog and letting me know I screwed up on saying Zdnet was using MT. I actually didn’t make that same mistake in this thread because I was actually thinking about it today, whereas you can see from my post over there that I wasn’t really talking about publishing platforms and technology and apparently just slipped. (e.g. I wasn’t thinking about that)
I appreciate the note, most people don’t even bother.
As for per your link, that guy didn’t run WP as far as I can tell from his post, did he? I don’t find it surprising that you can run Apache on an iPhone, along with some rudimentary scripts. WP, MT, and other larger applications are a different story — and by no means is WP alone in that, I doubt you could run MT on an iPhone either. Nor would you want to, which is why I find it such a bizarre point to try to make.
I’d also note this person went to some lengths messing around with this stuff to stay within the memory limits of the phone, which is right along the lines of what I’m saying, and he ran into problems and limitations anyway.
Do you have any data on how much memory a typical installation of WP uses per process to serve a request? I’d be far more interested in seeing that than some guy hacking on his phone for fun. That’s another concern I’ve not seen addressed, you’re going to incur that memory footprint times however many concurrent requests you’re dealing with, no?
I apologize for continuing to eat up comment space here Mike, but before I start backing away from this thread to do other things, I’d like to explain a few things so that people understand that I’m not here as an MT fanboy looking to ruin the party.
I started blogging a couple of years ago on Blogspot. My primary complaint against them was only having the single template with which to make an entire site and the subsequent inability to “preview” actual blog posts from those templates. If you previewed the main template, all you’d see is what you’d get on your main page, not when somebody was viewing a post. I was well aware of the existence of WordPress at that time and it was the first software I experimented with. I still have it installed on my workstation as a matter of fact.
I was pleased with what I saw but the lack of static publishing out of the box was hard for me to accept. I wasn’t setting out to launch a personal blog where you could run just about anything you wanted, I intended to build something over the course of several years that could compete with the big players in my “niche” of TV & film news. I needed something that would work as well under tens of thousands of views per day as it would under a couple of hundred. At the time, I couldn’t find any plug-ins that would let me publish statically with WP (for my own fault or because there weren’t any), so I looked for alternatives.
Had I found such a plug-in or had that functionality been built into the core application, there’s every chance in the world that I’d be running WP today. I’m not kidding. It’s an attractive application that just went the wrong direction early on.
MT provided me with what I wanted in terms of scalability, so I settled with it and will have been using it for a year come this July. I have no particular love affair with MT. It doesn’t publish pages fast enough for my tastes and I’d like nothing more than to see improvements in several areas. I joined 6A’s Pronet group and a couple of their mailing lists with the intention of doing whatever I could to push things forward, but the time never materialized. I tried to benchmark publishing through the Schwartz framework with various template constructs to find out where the bottlenecks around and while it did help me find some bad mojo in *my* design, it wasn’t nearly comprehensive enough to find bottlenecks in the application code — not without some serious time and effort.
I do believe in the value of the static publishing model though, for more than just blogs. I started writing my own CMS after leaving Blogspot but before getting acquainted with MT, and it was PHP-driven on the backend but published static HTML much in the same way. I have prototype forums built like that as well. Once I found out that I was basically writing a PHP port of MT though, I dropped my project and did what anybody would do — used an existing wheel.
I care little for brand loyalty and fanboy rants and I want to make sure that Matt, Mike, and anyone reading this thread understands that I’m interested in performance and enterprise-esque feature sets for a range of scenarios instead of just what I’ve got to deal with right now. MT’s seemingly unparalleled ability to administer an entire network of blogs from a single interface is important to me even if I’ll never use it. Its ability to separate functions atomically (admin interface on one server, publishing workers on another (or several), comment handling on another, HTML and file serving on another (or several with rsync)) out of the box underscores the difference in target audience, but nevertheless means that if and when I want to get serious, the package is already two steps ahead of me.
So really if WP had the ability to publish statically back then, I’d be sitting on the other side of the fence, but it doesn’t mean I’d stop bitching about this stuff. I’d still want the things missing from WP and I’d still be singing the songs of static publishing.
I hope that clears things up a little bit.
Holy guacamole, that IS a comments section, looks more like a forum thread, while the post is about switching MT to WP.
Anyway, welcome Mike to WordPress.
Cheers to Matt for dropping by and dipping in the discussion. This has been a lively read. :)
This has been an interesting read. I have had to come back to it a couple of times to read through everything that was said and I am sure I have still missed some interesting points that have already been made.
From my point of view, the dynamic nature of WordPress is what makes it as capable as it is and as useful and transparent as it has proved to be. I am in the cable business and we run a relatively robust VOD platform that is very well used (about 150,000 subscribers). However, in spite of the robustness of the platform and the care that we put into making sure everything is working smoothly, at times the platform falters due to unforseen circumstances or human errors. During those downtimes customers complain. They complain that they cannot watch the movies they have purchased, they complain that they are not getting what they paid for and they complain that we need to give them a discount or give them some more time to watch their purchased movies. However they never complain about the dynamic nature of the product or wish that they could watch their VOD movies on OTA braodcasts over which they have no control. This example might be a similie on a tangent but dynamic content, in spite of the inherent risks and extra loads involved, is a better way to provide content to an end user. I am not sure how dynamic content is inferior to static content and this part of the discussion is just strange.
As for the excessive loads that WordPress is purported to put on the servers, my experience tells me that misconfigured and unconfigured hosts and servers are more to blame than anything else. On a decent $100 server (dual processor, gig of ram, properly configured LAMP, without any specialized software, without static file caching, MySQL server on the same box as the web server) WordPress is capable of serving anywhere between 200,000 to 400,000 uniques a day and still be quite responsive. More often than not shared hosts are overloaded, MySQL is not properly setup and/or Apache modules are installed/misconfigured that add to the load. In addition to the this weak link, errant plugins are often the culprit. Misuse or overuse of MySQL connections, ill planned or executed SQL queries, unnecessary writes, locks for updates or table scans, errant joins, missing indices and even static file accesses are common and add to the load times. I know of at least a couple of extremely popular plugins that optimize tables on every access in order to keep the tables from crashing.
My blogs (without wp-cache or any other caching plugins) have weathered Diggs and Stumbles regularly without so much as a huff. I will also say that they do become unresposnive at times with the smallest of loads due to my errors in configuration and/or untested or bad code that I put into production without proper testing. It is not the dynamic nature of WordPress or the core code but me, myself and I to blame.
[…] CEO of the very cool Newvine, switched from Movable Type to WordPress three months ago, and spent some time listing his reasons for doing so. Consider this the antidote for any WordPress community members who were feeling a little bruised […]
I have update the Plugin Text Control for WordPress 2.1 and now for WP 2.5. When you like this plugin, the download is under this link.
I have ask the author and i have not bekome a answer. So is it not possible to upload to the SVN.
With best regards
Frank
[…] Mike Davidson – Goodbye Movable Type, Hello WordPress […]
Mike said: “Ability to write out files with .php extensions and refer to them in the CMS without the extensions?”
Hah, that was the last straw for me in MT4. I upgraded from MT3 and couldn’t get my hack MT-regex method of storing .php files in the filespace but serving and linking them as extentionless to work. Later I realized that the regex plugin probably should have worked, I was just doing something wrong, but at that point it was too late: I’d realized that I shouldn’t have to do something that hacky to get something so simple as cruftless, futureproof URLs. Prominent coders/bloggers have been hacking this crap in since 2003, it should have gone core by now!
So I upgraded to WP2.33 and then 2.5, and it is absolutely an upgrade in every sense of the word.
BTW, I share you feelings that the development community around WP is much more lively than MT. A few years ago there was a huge, constantly growing group of plugins for MT. Now many of those plugins have never been updated, and new ones are few and far between. Same thing with themes. But the WordPress plugin and theme communities feel like MT circa 2004… there’s just a lot of exciting things going on.
[…] Mike Davidson […]
Just felt the need to jump in and clarify that cruft free permalinks are possible in MT4 by default (I’m fairly certain they were possible by default in MT 3.3 too but I can’t remember). They just happen to look (and be published) slightly differently.
Examples can be found at movalog.com, learningmovabletype.org, movabletype.org and a host of other new MT4 sites. You simply choose the option from a list!
Arvind: Unless something has changed since 4.0, permalinks on MT are the same as they’ve always been. You either publish as “.php” and refer to them in the CMS and the web browser as “.php” or you publish as extensionless and refer to them in the CMS and the web browser as extensionless. What Matt, I, and countless others want to do instead is what we consider the right thing to do: publish as “.php” files and refer to them in the CMS and the web browser as extensionless. This has never been possible without the ugly MT-regex hack that Matt mentioned. If we’re wrong, please let me know.
Back when I used MT2 (before your “good shepherd” made a remark on his blog that caused me to ditch Six Apart forever), it was easy to get cruft-free URLs.
They had a little field where you could put words or variables to indicate the path and filename for your files. I don’t remember the syntax, but it was something like
/archives/%year%/%day%/etc
So if you wanted this entry to have a cruft-free URL, you would have it published to
/archive/2008/03/mike-industries-now-powered-by-wordpress/index.php
and then manually construct your permalink to be like
/archive/%year%/%day%/%title%/
. That has a trailing slash that your current setup doesn’t have, but that article that went around way back in the day that got everyone to use cruft-free URLs advocated the trailing slash.
Lanny – Yeah, that’s one way to do it. For some reason I rejected it back in the day… might have been a good technical reason, might just have been a weird aesthetic dislike of /index.php format.
Like I said, cruft was just the last straw. Most of my reasons for switching were similar to Mike’s… the speed of WP is awesome, I don’t need a static blog (I’m never going to get dugg or slashdotted), I think dynamic with cache is a much better solution than static (at least for my situation…), and the development community for WP is just more vibrant.
I can speak to why I didn’t like it: I don’t like the trailing slash because to me, it implies a directory or a section and not a document. Having all of these folders on my server which were actually just containers for index.php files just didn’t sit right with me. This is all debatable, of course.
I use, recommend, and love WordPress. A long long time ago I tried MT but just didn’t like it, mostly because of Perl and installation hassles. To each their own.
As my blog traffic went up WP started slowing down (I’m on a cheapo Dreamhost shared server) . I installed the WP-Cache plugin and the slowdowns cleared up right quick. The WP team should really make WP-Cache core. I keep hearing about caching being built into 2.5 but I like being able to verify it with the plugin.
Beyond caching, every website should set long expire headers for CSS, images, and JS, and reference fewer files per page (one CSS, one JS) to cut the number of HTTP requests. After a readers’ first page view your site will be BLAZING fast. You should also use Apache gzipping — in Apache 2 it’s called mod_deflate — for all non binary files.
Mikeindustries.com for example doesn’t gzip anything and doesn’t set expire headers. I bet if you did everything Yslow told you to do your average page load render time would be cut in half.
To test all this stuff get the Firebug and Yslow plugins for Firefox, and learn the nuts and bolts at http://developer.yahoo.com/performance/rules.html
Been meaning to write this up in a blog post. If you can’t wait, below is the stuff you need to put in your .htaccess file to make it work (assuming you use Apache 2, earlier Apache is different. Also, double check your mime types in case your server is configured differently).
# Below uses mod_deflate to ensure compression text files. Never compress binary files.
SetOutputFilter DEFLATE
# compress content with type html, text, js, and css
AddOutputFilterByType DEFLATE text/html text/plain text/css text/javascript application/javascript application/x-javascript
# properly handle requests coming from behind proxies
Header append Vary User-Agent
# Properly handle old browsers that do not support compression
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Explicitly exclude binary files from compression just in case
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|pdf|swf|ico|zip)$ no-gzip
# Set long expire headers for better browser caching
ExpiresActive On
ExpiresByType text/css “access plus 30 days”
ExpiresByType text/javascript “access plus 7 days”
ExpiresByType application/x-javascript “access plus 7 days”
ExpiresByType application/javascript “access plus 7 days”
ExpiresByType image/x-icon “access plus 7 days”
ExpiresByType image/vnd.microsoft.icon “access plus 7 days”
ExpiresByType image/png “access plus 30 days”
ExpiresByType image/gif “access plus 30 days”
ExpiresByType image/jpeg “access plus 30 days”
ExpiresByType image/jpg “access plus 30 days”
ExpiresByType application/x-shockwave-flash “access plus 30 days”
There’s no caching built in to 2.5 AFAIK, but you’re right, there should be.
Nathan: Thanks for the checkup. I need to fix that shit right up. Must have been an artifact from moving. I know at one point, I was sending down gzipped files with expires headers. Great tip about YSlow too… very nice tool.
As promised above, I finally wrote a post about optimizing WordPress (and regular sites) for speed and Digg survivability.
The post includes a sample htaccess file so you don’t have to figure out all that Apache gzip and expire header stuff in the dark.
I like your post Nathan, but I’m not sure there’s much use in compressing output. For most sites with moderate traffic levels, in most instances — and with the kind of bandwidth people get these days (I’m sitting at around 5.2 TB per month myself) — when you consider the impact of broadband in general, you’re just not going to see any increase in page loading from compressing something like your style sheet, and you aren’t saving but a minuscule amount of bandwidth in the big picture.
Even large objects like the page source should be well within the burst rate of most connections.
When you do get hit from Digg, Slashdot, or god forbid Drudge (which can make the former two look like trickles) I think the real result here will be increased CPU usage by Apache for having to stop and compress the files for every single request individually, which will actually slow things down. Perhaps not much, but we’re talking incremental gains in performance against incremental costs, right?
I’m not sure there’s a lot to gain from changing the expiration timeouts on non-transient or semi-transient objects either. 30 days is going to be long after those objects have been pushed out of the browser cache, even with abnormally large cache settings. I like the idea, but is there any experimental data that shows concrete advantages from doing this? I’d love to see it if there are.
Interesting stuff, nonetheless.
Paul,
We’re not trying to save on hosting bandwidth costs, we’re trying to speed up page loads for our readers. Saving HTTP requests, ~7KB for CSS, ~40KB for HTML, and maybe ~80KB for the average JS library makes a big difference, even for broadband readers.
It is possible that all that gzipping might slow Apache down in a real traffic spike, but IIRC Apache has been seriously optimized to handle gzipping gracefully. You could always manually pre-zip your JS and CSS files just in case.
There is a lot to gain from setting expire headers. Even if your files don’t last 30 days in someone’s cache, for your loyal readers the files will probably last at least a few days, and expire headers certainly speed up subsequent page views in the same browsing session.
If you want to see data proving that this stuff is useful I suggest giving Firebug and YSlow a try on your site before and after doing optimizations. There are all sorts of neat things in those plugins for benchmarking.
Will do, thanks.
Holy crap.
This entire discussion is running like nine feet above my head and I still like reading it… it’s a good example of why I like the internet.
Here’s another: I’m going to jump right in and rudely ask the smart people in this thread for some free expertise… and I bet some of them will help me out, just because they’re nice!
I run a tiny site for my students’ basketball teams and we use WordPress because it’s what I know. Anyway, the site is S L O W and I can’t figure out why. I know that turning on caching didn’t seem to help much and I hated it because it added a step every time I tweaked the css and wanted to see the results.
Could someone take a gander (www.ramslive.com) and help me figure out why its so slow?
Holy mackarel!
Seth, I second that!
This was a very interesting read, and I learned a lot!
One thing I noticed that while this seems like a heated discussion, it all stays within the realms of civilized. I like that!
I’m currently playing around with both MT and WP on two blogs, and just posted some thoughts about them yesterday:
(excerpt from my blog at albor.de, which runs with WP)
—
So far, I have to say, that for my taste, MT beats WP by a mile and a half. The MT backend looks and feels more professional, and the CGI coding that works in the background seems to be faster. Template and blog design shenanigans are a doodle.
WP still has this high school software feel to it – everything is too big and clunky, and those minty colours everywhere. I don’t particularly like mint. Or purple, mauve. ‘Never trust a woman who wears mauve, whatever her age may be, or a woman over thirty-five who is fond of pink ribbons..’, as good ol’ Oscarle said. Too many clicks needed to do things. The backend seems cleaner on the first look, but it’s just more nested, really. Like pink ribbons. Oh my, I’m in trouble now.
But WP is free and a good effort, and a lot of people have put in a lot of work in, so I’ll get me hat now. It’s not that I don’t like it.
—
I just like to add to that that the WP admin interface has shifted a lot of the stuff that was previously in the header down to the footer, or not?
Too bad that there are no graphical smilies here, would make it nicer, don’t you think :O
Thanks for posting about the Domain Mirror plug-in. I was looking for something like this over the weekend, but couldn’t think of the proper search terms to use :-).
[…] Mike Davidson, CEO of Newsvine, recently moved his blog from Moveable Type to WordPress. He shares his thoughts: A few months ago, I silently moved Mike Industries from the aging Movable Type platform to the […]
Hi Mike,
I have loved WordPress for a while and there are lots of great things about it.
I quit reading about 50 comments ago (about the third mega comment perhaps).
When in a whiskey bar, best not to order a wine (or in this case whine). Better to go where they like wine and get one.
This page took almost a full second apparently, but it’s all the windy guys fault no doubt :-) Welcome to a great little program.
P.S. I tried expression engine for a bit. In addition to costing out of the box for full featured use, I found it much more difficult to use, and that was long before widgets and such that make WP great.
Welcome to WordPress World Mike ;)
Nice list, I recently setup a WP blog and had a small delay before pages loading, adding the WP-Cache plugin solved the problem and the pages load without that annoying delay. I may end up using some of the others, but for now thanks for the tips.
[…] изцÑло Ð½Ð¾Ð²Ð¸Ñ WP Admin Ð¸Ð½Ñ‚ÐµÑ€Ñ„ÐµÐ¹Ñ Ð¸ новата верÑÐ¸Ñ Ð½Ð° WP — Mike Davidson, например. Ðз Ñъм от “умерените” ентуÑиаÑти. […]
[…] has run on way too long, so that will have to wait for another day. Until then, here’s an interesting discussion on the […]
[…] are a lot of enthusiasts, which like the new WP Admin interface and the new WP version, including Mike Davidson. I am one of those ‘moderate’ enthusiasts. I love WordPress, I use it for more than a […]
your dreamhost page is now broken
https://mikeindustries.com/blog/dreamhost-web-hosting
[…] Goodbye Movable Type, Hello WordPress […]
I’ve used WordPress in a number of cases for client work, and alway found that building a site with it left a bad taste in my mouth. It’s not that it doesn’t do the job – cos it does. It’s more an apparent lack of elegance.
I’m not saying WP is bad, not at all. Lots of people love it, and I am sure there are reasons that is the case.
But for me, its highly unlikely I’d ever replace the Textpattern installation I use to run my site with wordpress.
That said, I am happy it’s working out for you. :)
mustapha: Hey, I just took the Dreamhost page down and I’m not publicly recommending them anymore. I still use them, but I don’t feel comfortable making a public recommendation anymore. I may do a writeup why.
I can’t believe I read all those comments. Anyone buy me a beer? WP 2.5, BTW.
[…] switched on Apr 6 ⁄⁄ ⁄⁄ WordPress, in contrast to Movable Type, is designed from the ground up to be dynamic, and through sm… Published in Themes | Tags: wordpress | Browse the Archives That’s all. Want more info? […]
I can believe I read all the comments.
What I can’t believe is that I’ve reconsidered switching from Movable Type to WordPress; because if I can in any way protract what appears to be MT’s declension, I’ll be able to find an edgy, well-informed Clash of the Boffins like this one. Lord, when you nerds get mad, you get mad.
Put some of that passion into coding, will you? I know you will!
[…] Mike Davidson – Goodbye Movable Type, Hello WordPress – Another neat WordPress logo. Tags: logo wordpress « Payment Systems As A Strategic Advantage […]
Hi Mike,
“. . and if I was starting from scratch, I might have chosen ExpressionEngine instead . .”
Please enjoy your new WordPress site.
When you’re ready to make the move to EE, just let us know. We’ll take good care of you.
[…] a spiffy new dashboard, courtesy of the fine folks at Happy Cog. Mike Davidson even jumped on the WordPress bandwagon. Motivated to tie the upgrade with a redesign, and the fact that I am actually getting real sleep […]
[…] Which one to choose? There’s only one way to find out; Fiiiiiiiiiight […]
Mike – Have you documented (or can you recommend other documentation) on your transition from MT to WP? Looking to take a similar journey – hoping to avoid the potholes. :)
What I can’t believe is that I’ve reconsidered switching from Movable Type to WordPress; because if I can in any way protract what appears to be MT’s declension, I’ll be able to find an edgy, well-informed Clash of the Boffins like this one. Lord, when you nerds get mad, you get mad.
I am still running my site on MT331 and have decided not to move it to MT4 but to Expression engine – which I have made a start on. The import facility is great and I have transferred over all six blogs used to run my site, including all comments and keywords. EE2 is due out this year and I think it really will turn heads. EE was a steep learning curve but so very powerful.
Dan: Sadly no. I should have though… :(
your dreamhost page is now broken..
As a movable type consultant I’m on the side of Movable Type, though Word Press seems easier to use. From a consultant stand point you could do much more interesting stuff with Movable Type than with Word Press and another plus is that Word Press has a good number of well known security issues (see wikipedia and google).
Your article is very good and informative, but I wished I would have been here for you before you’ve switched over to word press :)
Amazing post and comments. We’ve got to have witnessed 5 of the top ten longest-ever comments there.
Seriously though, as a slightly informed bystander, from reading the stuff, it set me off twiddling my blog which has got rid of annoying problems and speeded it up a bit… So thanks Mike, Paul and all the lesser comment-length mortals!
It’s WP 2.7 I use.
your dreamhost page is now broken..
[…] Modernize and completely rewrite the code that was brought over when I switched from Movable Type to WordPress a year ago. […]
I just now ran across this post… yeah, Mike, the Long Tail.
For what it’s worth, I switched to WP from MT sometime during the development of MT 3, years ago now. It seemed like every iteration of MT, I’d have a half dozen things to “fix” in the core code to make the blog work the way I wanted it to. After a while, I just got sick of fixing stuff I shouldn’t have had to fix. Well, that and the spam comment problem became insufferable on MT right about then.
I haven’t looked back since, and have no regrets about switching. And I don’t have spam comment problems anymore. Now days, when I fiddle with code, it’s fun, not work… as it should be.
I run a tiny site for my Businessand we use WordPress because it’s what I know. Anyway, the site is S L O W and I can’t figure out why. I know that turning on caching didn’t seem to help much and I hated it because it added a step every time I tweaked the css and wanted to see the results/result.
See You..