As soon as I started talking about redesigning boagworld, everybody asked me what content management system I was intending to use. To be honest it wasn’t a subject I had put a lot of thought into. I had used WordPress for years and didn’t see the value in changing. Nevertheless I felt I should ask around.
It’s difficult to change CMS.
Every web designer/developer seems to have a strong opinion about which content management system is the best. Rarely do they agree. It quickly became clear that content management systems are a point of contention.
This is probably because people become invested in their CMS. They have taken time to learn how it works and imported large amounts of content into it. Changing would not only be a steep learning curve, but also a hassle.
Not that I am any different. Although people suggestedDrupal, Expression Engine and various other solutions, I couldn’t really face switching from WordPress. What I would gain from switching CMS just didn’t seem worth the trouble. The return on investment didn’t seem worth it. That said, I did have some concerns.
Some concerns over WordPress.
To be sure I was making the right decision I needed to deal with my lingering concerns. These included:
- Many people suggested performance as a drawback of using WordPress. I had also experienced some issues myself in the past and that couldn’t be allowed to reoccur.
- Ryan Taylor had done a load of work with custom post types and taxonomies which I knew little about. They appeared powerful but had also created some issues, so I wanted to make sure that they were the best approach going forward (not that I don’t trust Ryan!).
- Legacy content was an issue that concerned me too. Boagworld has been around since 2005 and so has accumulated a lot of posts coded in slightly different ways. I had standardise these overtime without it requiring a huge amounts of effort.
- Best practice in regards to plugins was a somewhat unknown factor to me. Ryan used to tease me for being the ‘plugin king’ because I used what he considered an excessive number of plugins. I wanted to know whether this was true and whether I was using plugins because WordPress was hard to configure without delving deep into the code.
- Finally, I had concerns about the future of the site. The current boagworld website wasn’t coded particularly well and built upon by a number of people. This new version had to stand the test of time and not break when WordPress updated.
In short, I needed to talk to an expert. Fortunately I had met Ian Stewart (who is one of the people responsible for WordPress.com) atFuture of Web Design. I decided to give him a call. What follows is a transcript of that call.
Ian Stewart: Paul, hello.
Paul Boag: Hello, Ian. How are you?
Ian: Awesome, how are you?
Paul: Very good, very good. Thank you for letting me pick your brains. It is much appreciated.
Ian: It’s not a problem. My pleasure.
Paul: So the kids got off to school alright?
Ian: Yes, mostly alright. Probably late.
Paul: Yeah, they often end up late. So, I heard your talk at Future of Web Design, which was so timely because I had in the back of my head that I was going to be redesigning the Boagworld website, and Boagworld is built on WordPress. So, I thought, “I’ll give this guy a ring, and I’ll pretend that I’m interviewing him, but actually what I’m doing is just mining his brain for useful information.” So I hope that’s alright.
Ian: No, that’s perfect.
Paul: Excellent. Ok, so it was a brilliant talk and incredibly helpful from what I heard of it, but I do have some specific questions, which are kind of partly related to Boagworld, and then some general, kind of WordPress-y stuff that’s relevant, as well.
Paul: One of the things that I wanted to kick off with is you mentioned something called the Toolbox theme.
Paul: Can you just kind of go over that again, just so that I can get my head around that and work out whether I think it’s probably going to be a good starting point for Boagworld, but I wanted to make sure what it was and how it worked.
Ian: Okay. Alright, so Toolbox started out as a project for us at WordPress.com. So, I work for Automatic, and we run WordPress.com, and I look after all the themes there. So, we’re launching a lot of themes, somewhere around like 50 – 60 a year, is the goal.
Ian: Yeah, and so we have a vested interest in making sure that they’re bug free, and that they’re well coded. So, what we did is make a theme that we can use to start out making themes.
Paul: Oh, okay.
Ian: Right? So, it serves two purposes. Like a tool box that you would reach in and pull out a tool, we’ll copy/paste stuff out of there, into maybe an older theme because we know that this code snippet in there works correctly. And the other thing we do is just start making new themes with it.
Paul: Oh, okay.
Ian: Yeah. Sort of fork it. The open source term is fork it.
Ian: And turn it into something else. And so that’s what we’ve been doing.
Paul: So that would be very appropriate then, as a starting point for me to begin development with Boagworld.
Ian: Yeah, and one thing that we try to do with it that’s really cool is, it’s all semantic HTML5.
Paul: Oh, is it? Oh, good.
Ian: Yeah. So, that’s super fun. It was a fun project to do, and so all of the new themes that we launch on WordPress.com are all semantic HTML5. Yeah, so every post is an article. Your comments are lists of articles. There’s nav elements in there, widgets are asides, and so forth.
Paul: Oh, brilliant. That kind of saves a lot of work then, for me starting out, and speeds things up a lot. Brilliant. That’s what I like to hear and I’m sure that will help other people as well, but I don’t really care about that, I just want to make my life easier. (Laughs.)
Paul: Okay, the other thing I wanted to ask you about was custom post types, which you kind of touched on, but you didn’t go into that much detail, really. The existing Boagworld site, when I built it, custom post types didn’t exist.
Paul: And then I know of Ryan Taylor, who worked at Headscape. He made some updates to the site and introduced custom post types, and now he has gone off into the world of freelancing. And I’m left with a site that uses custom post types and it’s like, “Crap.” I mean, I could ring up Ryan, but I don’t want to admit weakness that I don’t know what I’m doing. So, I thought I’ll ask you. Tell me a bit about custom post types. How do they work? How do you go about using them? When is a good time to use them, and that kind of thing.
Ian: Okay. So, the best way to think of custom post types is, you know what a blog is, right? Like, WordPress and its posts, right?
Paul: Yeah, yeah, I worked that out.
Ian: And, but there’s also pages, right?
Paul: Okay, yeah.
Ian: So, if you cracked open WordPress itself and dug deep into the code, you would discover that there is no difference, really, between posts and pages. Except one is a custom post type, and that’s what a page is. So, when I think of a custom post type, I think of any sort of content for your WordPress site, your blog, which is out of that post order. So, the posts are in reverse chronological order and it shows up in your feed, but the pages don’t.
Ian: So, if you ever need content that’s outside of your regular posts, and isn’t really a page, and it’s not a post either, a custom post type is probably the solution.
Paul: So the way that we seem to be using them is as seasons and episodes.
Ian: Oh, okay.
Paul: There seems to be some kind of hierarchy that he’s created between the episode set within the season. So, instead of having those just as normal posts, because obviously our bloggers are on the site a lot as well, he separated those out. So, is that the kind of thing?
Ian: Yeah, that’s a really cool use of custom post types, because you don’t want it to be part of your blog, and you don’t want it to be really flat, like a page. You want it to have some sort of continuity between seasons, so you can navigate back and forth between those, and that’s a perfect example of why you would want to use custom post types on your blog.
Paul: So how do you go about creating the relationship between custom post types? I mean, he seems to have got some kind of hierarchy going on between seasons and episodes, and I’m quite interested about how that works.
Ian: Okay, so what you can do; to make a custom post type there are functions in WordPress that let you just add them with a simple plug-in or with a theme, but you can also add your own taxonomy to them for organizing them. So a taxonomy is like a category or a tag your taxonomies . You can make your own just for organizing them. So you can tag them in certain ways, and not pollute your regular tags. So if you have a tag cloud on your blog, you might not want to see your posts or your season tags mixed up there. You create your own, just for that custom post type.
Paul: Ah, okay. Can you recommend any resources for kind of digging into that? Because obviously I’m going to have to get my head around this. Where is the best place to start?
Ian: Yes. The best place to start, just to generally read about it, is the WordPress Codex.
Paul: Right, yeah.
Ian: If you go to codex.wordpress.org. But, going back to my FOWD talk, I made a theme that uses custom post types, and custom taxonomies as well, and I tried to make it really dead simple. So, on ThemeShaper.com the featured post right now is powering your design with WordPress. Themeshaper.com is our blog for WordPress.com themes, the theme team that I’m a part of there.
Paul: Oh, okay.
Ian: It’s a blog about stuff we’re working on, and I turned my Future of Web Design talk into a post there, and if you grab the theme from that post and take a look at the functions file, there are some dead simple examples of how to implement custom post types that are not too complicated. They’re easy to get your head around. As well as in the post too, I explain what’s going on there.
Paul: So Theme Shipper.
Ian: Theme Shaper.
Ian: As in, “Shaping Themes.”
Paul: You strange Americans with their weird accents.
Ian: Strange Canadians.
Paul: Oh, sorry, oops!
Paul: I knew that! That’s the ultimate sin! We talked about that, didn’t we? When I was at FOWD I said that the first time I was introduced to Daniel Burka I presumed he was American. It’s the ultimate sin, isn’t it? It’s like calling British people European.
Ian: Yes. We both get the saying, “God save the queen.”
Paul: Exactly. Certainly, I feel more of a kinship with you. All because of that. Okay, that’s brilliant. I’ll check that out. That’s really good.
So, the other problem that I have, which is a silly little problem, is one with legacy content, right? So, what I mean by that is that I’ve got, like, hundreds and hundreds of blog posts, I think 800 plus, that I’ve been writing since 2005. And there are all kinds of things in there that maybe I want to strip out because I don’t use it anymore, like a break out box for example. Or, I might want to change all of my H3 headings into H2 headings in order to kind of fit in with HTML5 or whatever. Is there a kind of mechanism to do that? My instant reaction when it’s anything to do with WordPress is, “Oh, I bet there’s a plug-in for that.” But I sometimes wonder whether that’s really the best way of doing that, if you want to makes those kinds of universal changes across the site.
Ian: Right. Well, you couldn’t make a plug-in that sort of, while it was running, had those changes happening. That wouldn’t be the best way, right? Because you’d always have to be depending on that plug-in. The best thing to do is to change the content. There’s a really great plug-in. It’s something like WordPress search and replace that will search through your posts and let you change, say, all of your H2 tags to H3, or what have you. Or if you know you have specific HTML in there, like a div with a class to make a break up box, you can just go in and search and replace, and change all those class names, or change that to an aside element if you want. That sort of thing.
Paul: Okay. Yeah, that’s exactly what I need. That’s wonderful. I thought it would be something simple. But, I always have mixed feelings about the plug-ins. I’m a little bit afraid of them. Because, you never know entirely where they’ve come from, or who’s coded them, whether they’re safe. You never know whether they’re going to have a performance impact on your server. I don’t know how far you go with plug-ins. Whether you need to be careful about them or not. Have you got any advice from that point of view?
Ian: Yeah. What I would do is, I would rely on what WordPress.org is providing for plug-in information. So if you go to WordPress.org and look at a plug-in there, you can see a rating. You can see, if you scroll down to the bottom of any plug-in page, you can see what people are saying on the WordPress support forums. And you can get kind of a sense of what the plug-in developer is like. You know, if it’s a one off plug-in and the developer never answers or supports requests, that would be a bad plug-in.
Ian: But if you check out the author and you can see a profile of the author and see if they’re contributing to WordPress, if they’re doing a lot of stuff, if they’re answering support requests, that would be a plug-in I would use.
Paul: Yeah. So, I mean, I just happen to be looking at that search and replace one that you mentioned a minute ago.
Paul: And it’s rated four and a half and does have 98 ratings for it. I’ve gone through to the author and there’s a stack load of plug-ins that he’s done. He uploaded something as recently as June 19th, which I think is a couple of days ago from when we’re recording this.
Paul: And so yeah, I see what you mean. Yeah, I guess a lot of the time, what I’ve done is I’ve installed plug-ins directly at the WordPress interface, where you don’t get quite this level of detail that you get from looking at WordPress.org.
Paul: So yeah, it’s also got a compatibility area I noticed, as well, which has got a lot of detail on, so.
Ian: So, if it’s a plug-in you’re going to depend on, especially for a production site, just do a couple minutes of research and just check it out.
Paul: Should you kind of be limiting the number of plug-ins you use? I mean, you can easily go ten, 20 plug-ins, you know?
Ian: Yes, I’ve heard of someone with 500 plug-ins and I would say that might be too much. Maybe 400 and less.
Paul: Okay, 400 and less.
Ian: No, I think the average is anywhere from no plug-ins, or maybe just a kismets, to maybe 30 plug-ins. And I think 30 is pushing it.
Paul: Okay. So, in the teens you’ll be okay, kind of thing.
Paul: Presuming they’re good plug-ins.
Ian: Yeah. Yep.
Paul: Okay, that’s interesting. Because I mean, that kind of comes on to performance issues and stuff like that.
Ian: Right, yeah.
Paul: Now, when I dropped you an e-mail earlier you said performance isn’t necessarily your strongest area, but is there any general advice? Because I mean, you do hear whispers, don’t you, about WordPress? You know, it’s got performance problems.
It’s one of these things, isn’t it? When it comes to things like content management systems, everybody’s got an opinion. Everybody’s got their preferred thing and I was talking to somebody else who said, “Oh, you shouldn’t be building it in WordPress, you should be building it in ExpressionEngine.” And I’m going, “I’m sure that’s great, but I’ve got all this legacy content in WordPress, and is it really worth the hassle, and blah, blah, blah.”
So, I just thought I’d ask you about performance with WordPress. Is there an issue there?
Ian: I don’t think there is.
Paul: Says the man who works for WordPress.com.
Ian: Yes, that’s right. I’ve heard the evil whisper campaign of which you speak, but no. I haven’t heard of any serious performance issues. I mean, WordPress.com itself is one WordPress installation.
Ian: Yeah, with over 20 million blogs on it.
Paul: No way!
Ian: Yeah. So, you can certainly scale it up. It’s the best case example of scaling up WordPress. Taking one installation up to 20 million plus sites on it.
Paul: That’s just insane.
Ian: It is insane. But, for Boagworld, I’d probably recommend a caching plug-in. Like WP Super Cache, which turns all of your pages into static HTML.
Paul: That’s what we’ve been doing currently, and I haven’t really had any problems with that.
Paul: So, it’s always worth asking.
Ian: It can certainly scale up to very high levels.
Paul: So, one last thing I wanted to ask about. You really have dealt with everything. It’s really good, I’m excited to get going and digging into this. But the last area I was thinking about was kind of future proofing the site a little bit and thinking ahead.
Because I mean, the danger is, is there anything you need to be aware of when designing your theme or when you’re selecting what plug-ins you use as to WordPress suddenly makes some upgrade or does something, and it’s going to break something? That’s a little bit of my fear. Because I know, for example, is it 3.2’s coming out soon?
Paul: And that looks like, as every major release of WordPress is, it’s going to make some changes. Do I need to worry about that? That kind of thing.
Ian: Yep, well there isn’t anything in WordPress that should break your site. That would be very unlikely. It’s been years, I think when tags were first introduced was the first time I really had to change something.
Ian: Back like five years ago. For future proofing, the only thing I would recommend would be not relying on plug-ins that add stuff to your content.
Ian: So, like if you’re using a plug-in that had a short code. What’s that, sort of like a bulletin board sort of code, and you started using that in a lot of your posts, and then you stopped using that plug-in, you would have all these weird codes in your content. That would be the only thing for plug-ins I would worry about.
Paul: Okay, cool. So what is coming up? I saw that there’s 3.2 coming out soon, but I’m quite curious as to what it’s going to contain.
Ian: Yeah, 3.2’s got a couple of cool things in it. For developers, the PHP version has been upped to PHP5.
Paul: Oh, okay.
Ian: So, everyone’s developing on that now. There’s a new default theme, 2011, which is responsive, which is really cool. Responsive and HTML5, it’s full of buzz words.
Paul: Good, good.
Ian: Yep, and there’s distraction free writing.
Paul: Ooh, that I like.
Ian: Yes, so when you’re writing a post you can click an icon and everything on the screen disappears. So all you see is a blank screen, no interface, just you typing.
Paul: Because when I write blog posts I use a piece of software called Byword, which is a basic word processor that supports Markdown and things like that.
Ian: Oh, okay.
Paul: It does exactly that, kind of fills the screen and hides everything else away, so having that built into WordPress would be superb.
Ian: Yes, there’s also Markdown plug-ins for WordPress too, I believe.
Ian: You can combine those.
Paul: Isn’t that an example of something that you wouldn’t want to use, based on the advice you gave a minute ago, because if that plug-in is removed, then suddenly all that Markdown is going to show.
Ian: It depends on how the Markdown plug-in is working.
Ian: If it’s converting it to HTML after you save the posts, that would be a good Markdown plug-in.
Ian: But if it’s not, then that might be kind of bad. We always depend on that, right? Otherwise you’d be stuck with search and replacing, and a lot of Markdown.
Paul: Yes. I need to look into that because I’m not sure what mine does at the moment. Fortunately I haven’t been using it for that long, so if it is bad then I can still fix it.
Ian: Of course, a plug-in that’s doing that wouldn’t be very complicated. It would probably always work.
Paul: Okay, thank you very much, Ian. That was really useful.
Ian: You’re welcome.
Paul: I’m sure other people will find it useful as well. So yeah, I might come back to you at some point in the future if I need to pick your brain more, if I may.
Ian: Good, good. You’re always welcome.
Paul: Alright, thanks very much, Ian. And I apologize for calling you American, the ultimate sin.
Ian: As a very good Canadian, I forgive you.
Paul: Speak to you soon.
Paul: Bye, bye.
As you can tell from the reference to WordPress 3.2’s release this conversation took place a while ago. Since then I have beaverd away on building the site. The advice that Ian gave has proved invaluable especially in regards to selecting ‘quality’ plugins. The article he wrote on ‘powering your design with wordpress’ was also a great starting point. The plugins he recommended (Search & replace and W3 Total Cache) were excellent.
I am in love with Toolbox.
However, the real treasure was the Toolbox theme he mentioned. I have built the new site entirely upon Toolbox and it has saved me hours of work. Although it is not all coded as I would have chosen, it is well written, makes use of HTML5 tags and generally pretty semantic. I highly recommend it.
Overall working with WordPress has been a pleasure and things have definitely improved since the last time I coded with it. That said, I am not suggesting it is for everybody. Each site and developer is different.
Developer first, CMS second.
The choice of CMS is about functionality required, and the skills of your developer. If you have found a good developer who has extensive experience in Expression Engine you are better off using that. There is more value in having a good coder than in having a particular CMS. After all most content management systems offer similar functionality.
That said, and with a deep sense of trepidation, I would love to hear your opinions of the different CMS options available. What CMS do you use and why did you select it? Let me know in the comments.