This is going to be a tough question to ask without violating the "Questions with too many possible answers or that would require an extremely long answer" rule, but let me give it a try...

I have a variety of websites focusing on a variety of topics, from animals to politics. I'd like to combine them into a single mini-encyclopedia. However, I don't want to delete the existing sites; rather, an article about the aardvark at www.geozoo.org/Life/Aardvark would also appear in the new encyclopedia at www.geobop.com/Aardvark.

At the same time, I'd like to upgrade to a popular CMS, like Drupal or WordPress. (I created my current CMS myself.) Rather than choose between Drupal and WordPress, I'm thinking of using one for the main encyclopedia and the other for the satellite websites. There are two advantages:

  1. Using two different CMS's will help me differentiate the sites, and
  2. a special feature not available on one CMS might be available on the other CMS.

I'll have to find some forum where I can chat about this, but I wondered if someone could give me a short answer - is my idea a good one, is it a lost cause, or is somewhere in between?

One bridge I'll have to cross regards my series of database tables that hold all my content. I assume I'll have to modify them to work with Drupal and WordPress both, and that could be a steep learning curve.

Anyway, I'd just like to know if I'm on the right track or if I'm pursuing a dead end.

  • Interesting idea, I think it would be quite hard to implement like that, though. Yours, Drupal's and Wordpress's db structures will all be very different and there's not much on the SQL side you'll be able to do to convince all 3 apps to work with the same tables (for Drupal & Wordpress at least). That sort of change would usually have to happen at the app layer and that would mean a lot of customisation of probably 2 of the CMSs. What about creating a feed on the master site and have the satellite sites consume it? That would be cleaner and a lot less work – Clive Feb 16 '14 at 22:35

I would advise reconsidering your proposed solution and making sure any benefits are worth the potential extra effort/hassle, because I don't really see any pros for doing it and there is a very large con of complexity (for no real gain).

In terms of your current reasoning for wanting to do this:

Advantage 1: Using two different CMS's will help me differentiate the sites.

Why not just use different themes for different sites to differentiate them? You could have different themes for admin, or front end, or both, depending on what you aim to achieve.
The themes could be totally different, or they could just be the same theme in different colours, or something in between.

Also, wouldn't it be easier if the editing/admin experience is the same for all sites instead of being different?
This also goes for any user interaction with the site from non-admins. Consistency is an excellent thing.

Advantage 2: A special feature not available on one CMS might be available on the other CMS.

Both platforms are very mature and can handle most things. If you want to do something really different you're probably going to have to write code to do it regardless of the platform. If you have two different platforms and you want to do something custom on both that means you have to write both a drupal module and a wordpress plugin (or modify existing modules/plugins for both platforms), so you're making more work for yourself.

It also sounds like the special features you talk of are things you might think of in future.
If you are choosing platforms try to think of all the features you want first (and features that maybe you might want in future), then choose the platform that is best for implementing those features.
Obviously you might think of things in future that you didn't originally think of but there isn't much you can do about that so the platform you consider the most flexible, and the platform you prefer to do custom code for wins points in this regard if you think that complex new functionality might be required in future (remember here that a large amount of commonly used functionality is available on both platforms).

Now there are the disadvantages, which include but are probably not limited to (I don't know exactly what your plan is for these sites to work together or interact with each other but these things are still likely relevant):

  • Possibly doubling effort when you have to write custom code (as mentioned above).
  • Adding effort when doing maintenance, like module/plugin updates.
  • Added complexity, which could make it harder to develop the new features you come up with in future, could make it harder to track down problems when they occur, could make it harder to use the sites (or understand how they work together) in general.
  • System requirement mismatches. These two platforms require basically the same things but sometimes to do something on a given platform you need a specific version of PHP, or MySQL, jQuery versions etc. Getting two platforms sorted out with specific library versions will be harder than one (if they have to match, maybe they don't).

Basically I think it is best to achieve what you want in the simplest way possible. Sometimes adding complexity is necessary for the requirements, or you may be able to create something that much better and it will be worth the effort/hassle but if not, and you are adding complexity and gaining nothing of value in return (or the potential value doesn't outweigh the potential troubles), then you are losing out.


I've seen this done on a Drupal 6/wp-2.9 project; most of the functionality was built to allow the same authentication tree on both sites. Both sites had different HTTP roots but read from the same database; all the Wordpress tables were prefixed with wp.

After looking at the code and seeing how many things needed to be maintained and tested (core functionality in WP; D6 was overridden, not overwritten :)) every time a security patch came out (e.g. new user, update password, reset password) I'd have to say it is not worth it. It looks like the same amount of work to set up totally separate sites on different sub-domains, the maintenance and QA of the sites after code/core is updated can become problematic to say the least!

Another option is to go with Drupal 7 completely and use something like the Taxonomy Access Control module to block access to different areas of the site based on the roles/users.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.