Hey everyone,
I’m curious to see the insight of others who have dealt with similar situations -
I have a client with a news site - currently running on the latest of Wordpress 3.
Things are starting to grow, and this news site is going to take on various local areas - giving them their own section each with their own local news, of course.
Along with local news for each, eventually local events calendars, local classifieds, local reviews, etc.
What are the thoughts on sticking with Wordpress vs going Drupal 7, which is said to be more powerful?
Or, thoughts on a way to use Wordpress Multisite for this.
Bare in mind, that all local news sections will still have the same world news, sports, etc.
Any ideas would be greatly appreciated, thank you!
I would go with the more powerful/flexible Drupal solution but I would do a little R&D first and decide what approach you need to pursue. There are several approaches that you can look at.
I’m not sure if Multi-site really fits the bill for your needs because you have one site with multiple areas. Drupal Multi-site is for running a single Drupal installation across multiple websites. For example, you have many different businesses, each with its own website and you want to centralize the CMS so that maintenance and updates are easier to manage. You set up a Drupal multi-site and each website gets it’s own database and /sites/ folder but the core is central. Getting multi-site to put each site in a sub-domain is possible but requires some doing.
I think what better describes what you are trying to achieve is mini-sites and that can be accomplished with Drupal Organic Groups also known as Drupal OG. I would set up a Drupal OG installation, use the OG Menu module and then look at the information for OG subdomains.
** That link to the subdomain module is still in beta so use with care… Read up on it and find out what the status is and what they are still working on. I’ve used beta or dev modules in production sites but only after I found out what the status was and determined that they were stable enough to last until they were finalized.
*** Also, you may be able to use the subdomain module and Drupal Taxonomy (without OG) and just create Taxonomy terms for each area. Then the subdomain module rewrites the URL to prefix it with whatever the term is… ie: You create terms for each area (westhaven, scarborough, delta) and assign the tags to the appropriate pieces of content. The subdomain module rewrites the URLS as follows: http://westhaven.example.com/sports, http://scarborough.example.com/calendar, http://delta.example.com/blog
That is the conclusion I was starting to come to over the past couple days of research. So I’m glad to hear that I’m headed in a good direction!
That was a question I had as I was looking into Drupal. It seemed that the Multi-site feature was geared more towards completely different sites.
This was the first response of a someone on the Drupal support IRC channel. I didn’t get into much detail with him because I didn’t have time, unfortunately. But OG’s were his first reaction. Good to see that confirmed!
This is interesting. And definitely another possibility. Although, would it be easier to keep content as a whole in its separate corner if I use something like the groups?
Here’s a little potential monkey wrench that I didn’t throw in before.
There will most definitely be areas in different states around the US. So it would be ideal to classify it by state and then by town - that way you could view news by state and then by town. Could I organize the groups into categories or taxonomies of groups?
Hi Tim,
I think it’s going to take a little research to figure out whether you want to go with a pure taxonomy based site or a taxonomy + OG direction. It’s hard to say what’s going to work out best until you sort of prototype it out. I’ve done both and I don’t have a clear favorite. That said, pure taxonomy is a lot easier to wrap your head around so it might be the best approach to try first and then if it’s not going to work then you can add OG to the mix and see how it improves things.
Figuring out how to manage the URLS for subdomains is going to be tricky but hopefully the subdomain module will do all the heavy lifting. When I’ve done URL manipulating with regular domains I’ve used tokens (token module) with a module called pathauto to rewrite the URLS based on a pattern. So the URL is example.com/some-section/some-page or example.com/some-main-section/some-subsection/some-page. Each section or subsection is represented as a token and look something like:
[node:field_taxonomy_section]/[node:title]
More complicated ones look like this (includes taxonomy and an OG token):
You’ll also want to use the entity module which contains entity tokens.
Going with a pure taxonomy site, you can use taxonomy tags to represent state, town but when using taxonomy + OG, it’s not so simple because it’s difficult to access taxonomy tokens for parent groups of group content pages. That being the case it might be easier to have groups within groups, using groups to represent states and then town groups to represent each town. It could get a little complicated by the time you’re done
Sounds like some great advice. I think there will be a bit of prototyping happening here.
I’m glad you mentioned what you have on mapping subdomains - I wasn’t as focused on that as I should be. Subsequently, things like that that have a tendency to bite you in the butt when you take them for granted and you think you’re on to a working system or prototype!
Sounds like fun to me, bring it on!
Thank you for all the info and advice Andrew, I’ve got some more planning ahead of me - and then some playing.
-Tim
If it’s not broken then maybe save yourself some work and stick with your current setup. Wordpress is turning into a proper little CMS with tons of plugins to meet your needs. As long as it’s properly optimized then it should have no problems meeting your needs. One of my wordpress member/news sites has 5k page views/day on a shared host with no problems.
Drupal and Joomla are also good options and have everything you need. If you’re up for it check out their code and pick whatever one looks more suited to your needs…
Netviewit, I’m glad to hear someone on the Wordpress side of things. I work with Wordpress on a daily basis - so I know it in an out. Which means I also know how easy it can be to extend.
I wasn’t sure if I could accomplish everything I needed with it though. This isn’t just a blog or a town news site, there’s more to it than that as you can see above. Which is why I was excited to see the input of Andrew above. He was able to not only give comments on the ability of Drupal, but also showed how I could accomplish it… talk about above and beyond.
With that said, I am leaning back towards Wordpress. I think it can be made to do everything that will be needed… and the bottom line is that if it grew out of where I could hack it to with WP then odds are that Drupal probably wouldn’t be able to be stretched or hacked much further either.
One big issue also had to do with permissions and access to portions of the admin. The person managing the NY news shouldn’t be able to edit the PA, and so on and so forth. It looks like the Role Scoper plugin may solve this though.
I wouldn’t knock WP but I think the reason one would move to Drupal is because it was designed for Enterprise sized applications as a content/application management platform right from the get-go. The programming API is amazing once you get to know it. Once you get used to the way things are abstracted and which functions get you around, it’s a bit like using a PHP application framework, except it also handles users, content, display, editing, user interface, menus, etc…
One of the greatest complaints I hear from WP people is with the permissions/roles part of WP. Drupal’s permissions and roles take a little experience to master but right out of the box you can create unlimited roles with cascading permissions and then add something like the “content access” module to create several levels of private content.
The other reason a great deal of high traffic sites choose Drupal is because it scales. Websites that deal with traffic need to scale. Some platforms are sluggish with low traffic but really shine when they get some traffic going, a tuned up Drupal site will be snappy at low traffic and can scale to meet the demand of the Sony, Warner, MTV (UK), Fastcompany, Yahoo Research, The Grammy’s, The Emmy’s, US Whitehouse, dozens of universities and many, many other high demand websites.
So… The other day I was so focused on the area of mini-sites I forgot to suggest some really great approaches specific to News/Media and aggregating news. Check these out:
There’s one more that I just can’t remember at the moment.
Cheers,
Andrew
EDIT: You could also look at taking something like Drupal Commons and make it into a news website… It has OG as part of the base installation. I haven’t looked to deeply but it’s pretty well thought out so it might make a good start: http://commons.acquia.com/
Hey Tim,
I stumbled on another module that might come in handy if you try the Drupal route: It’s called the domain access module and I may give it a try myself for a small site that will have 4 distinct mini-sites: http://drupal.org/project/domain
Andrew, you’re killing me… Right when I start to think “ah, I think I can get away fine with developing WP for this” you come along and make Drupal sound even better!
At this point, it comes down to which I can get moving in the right direction fastest and on a tight-ish budget.
This is exactly what my biggest hold back was. It would be important for the different areas to have different administrators/editors. Although, I found a WP plugin to take care of this - so that swung me right back towards WP.
With cache plugins, I’m not super concerned about traffic… they essentially all become equals because both a cached Wordpress and cached Drupal are serving static content. So they should be basically the same, right? Not sure how many holes are in my thought process there.
With custom post types now integrated into WP, I’m less concerned about scalability as related to that. Plus, there are plugins like Pods to make even more use of that.
Openpublish looks really neat - I did see that one once before. It is definitely a point for Drupal in my internal WP vs Drupal struggle. “Managing news” I hadn’t heard of though, it’s interesting. Seems like you could make almost mini sites to track trending topics off of it. Not sure how that would work with a news site that has it’s own content too though, since it’s an installation profile. It seems like that is more for tracking what is going on, right?
I really like the idea of Drupal, especially because I haven’t really had a chance to do a good project on it. However, I’m wondering, how much further can I push or hack Drupal for a news site than I can hack the latest of Wordpress? I’m thinking that sooner or later this is going get really stretched and end up on a framework like django or something anyways.
How far exactly can you push Drupal? Maybe we’d never have to move off of it if we start with it. But I can promise you this is going to grow into something HUGE.
What are some good examples of big sites, especially news (I know the The Onion used to be Drupal based)? But if we’re talking about this site geting “The Onion” big, then they had to move off Drupal eventually as well. I’m kind of rambling here, but I think you can see where I’m trying to go with this. I guess overall that’s the biggest question.
As always, your input is tremendously helpful Andrew.
You’re clearly a Drupal pro.
I’m surprised we haven’t seen anyone in here yet that has done anything big with WordPress.
Well I think with your background, it will be initially faster to move ahead using WP but I’m not sure it is as flexible a solution in the long run. The way I look at is that the guys who built The Examiner, The Economist, Popular Science, Sony, Warner Bros, Yahoo Research, Whitehouse.gov, etc… had the resources to choose any platform they wanted but they chose Drupal. They must have compelling reasons for making their choice.
Well, here’s where Drupal really shines because at it’s core is the user management system and it’s solid. It’s so powerful and extensible in some cases I’ve used it to manage thousands of user profiles and in others I’ve used user profiles to act as a content type for distributor lists where the distributor can log in and modify their own listing, locations, etc… It’s not a module added to the system, it is an integral part of the core system.
Yup, I think it would take a lot of action to take out a website. I built a site for a flight club with no special caching or optimizing, running on generic shared hosting and I saw it manage traffic spanning a couple of thousand visitor sessions without skipping a beat. At any given moment it was managing 1500 - 2000 individuals. With that in mind I’m pretty sure a managed server or cloud based hosting situation will take anything you throw at it, especially if you set up caching and load balancing.
Well that’s the thing… I think it must be able to scale to a very high point, other wise it wouldn’t be able to handle the traffic of the high traffic sites it runs. I can’t imagine how much traffic Whitehouse.gov, Warner, Sony, The Examiner, The Economist or MTV UK get but it must be massive and yet it seems to manage quite well. There are some tricks to managing all that traffic like “Varnish” and Pressflow but it seems to me that the platform has proven to handle the scalability question quite well.
Yeah, The Onion is a bit of a sad story. It was a Drupal 4 site built back in the day (2005ish) when Drupal best practices were somewhat non-existent and the team that built the site hacked the crap out of it to make it work. The result was that as Drupal evolved through versions 5 & 6, The Onion’s version was too modified to update cleanly. Also, I think The Onion tech team were happier writing code than learning the best practices of a CMS framework so they chose Django… It probably worked best for what they needed to do.
I had limited exposure to D4 and moved from D4 to D5 almost as soon as I started working in Drupal. Both D4 and D5 were IMO easier to write code for but this also made it easier to paint yourself into corners. As Drupal has evolved the API has become more complex, meaning that it’s more complicated to code but provides more flexibility and deeper hooks into the core of the CMS so that your code can effect and be effected by actions and events closer to the core of the CMS. It’s also a heck of a lot more secure and snappy.
Thanks, I hated Drupal when I got dragged into my first Drupal site but then I became addicted, scrapped my own CMS and made it my mission to become a Drupal Ninja… I’m not there yet but I’m still working at it
The title of your thread screams Drupal multi site
We host many organizations with multiple locations using multi site. Some even have a location in every major city across the country running under one Drupal multi site installation!
