Compare Joomla v WordPressJoomla vs Wordpress is a popular question so we had to set up a page for it. Partly, this was because there is no valid technical resource available for this question, mainly just new user's observations; and also because what tech data there is also happens to be sketchy or plain wrong, and we wanted to set the record straight. There is a brief run-down of the technical requirements for each - server types, codebase and so on - at the foot of the page. So, here's the big question:
Q : Compare Joomla versus WordPress for CMSA : This is a valid question because both are PHP - MySQL-based webapps that run off a database, and perform similar functions. But their aspirations are different: one is a full-on CMS, the other is a 'quick publishing tool' that is designed to get your content online ASAP. A micro-cms, if you like.
WordPress is a website engine built on the premise that installing it, running it, and publishing basic content with it should be as quick and simple as possible. Joomla is a different animal, it's for managing and publishing a lot of different content types, in different ways, while looking good doing it.
An easy way to compare fundamental differences is the way in Joomla you can have ten different menus on any page, in any position you like, of any style you like, looking how you like, several of which you can create from scratch, with any menu name you like - with just a few clicks (and maybe some gfx work if you want them fancy). This is CMS functionality as against a blog. You can do a vast number of jobs with a comprehensive CMS, and it is designed for that purpose.A better CMS to compare with WordPress would be CMS-MadeSimple, which has many of the same aims. Even so, as a CMS (i.e. a tool to handle different content types easily, in different ways, with the possibility of assuming widely different online roles, and be used by different people), then CMS-MS still wins out.As a simple publishing tool for one main type of content, to be used by one person, with few additional capabilities required - then WP wins every time. Also, WordPress targets the whole blog scene much more efficiently, with all that implies: the search engine response, blog searchbots, ping / trackback / tag capability and so on. A CMS operates in a different sphere, and therefore does its job better in that respect. Horses for courses and all that.
Installed CMS sizeAnother comparison you could make is the actual size of the application. A CMS can take up some serious webspace - OpenCMS installs at over 600MB on the server, and Plone takes up 250MB (both as bare new installs). Joomla installs at about 30MB and a small working site is usually about 100MB.
WordPress installs at around 10MB on the server.
SEO for Joomla and WordPressAs far as SEO goes, each will do the job. Out of the box they are both fairly useless, but as frameworks that is irrelevant. No modern dynamic website engine does each and every job perfectly out of the box - that isn't the point; but you need the ability to upgrade and extend for best search optimising. Each has this and of course you can easily extend Joomla or WP so that they achieve near-perfection here. The Joomla SEO score is 95 out of 100 (when implemented correctly), and this is a very high score. This helps us put clients right at the top of the search results in the toughest markets. Of course, we have seen SEO personnel denigrate it and state it performs poorly; but you could say the same for each and every application - and you probably would if your knowledge was limited. We prove our statements with results, so there's not really much to argue about. You cannot blame a CMS for the shortcomings in ability of the implementers and/or SEO personnel, so if the results seen are not good - find new people.
Joomla provides 100% perfect URLs and metadata when managed correctly, and pagecode that is good enough for the job. However, getting any complex dynamic app with numerous extensions to validate 100%, for every page, is a painful and time-consuming business - and may not be necessary for a given use - so a few fail points may be acceptable.Out of the box, most dynamic website applications produce multiple duplicate URLs, and both Joomla and WordPress are no exception. This situation is of course a nightmare and has to be fixed. Plugins sort it out immediately. End of problem.The only improvement Joomla needs in the SEO area currently is to get rid of the table-based layouts; the half-and-half divs and tables are better than nothing, but there's still work to do. Joomla's page code validates 100%, though it has a couple of minus points on SEO and accessibility due to the tables in the layout scheme; and of course you will need to do those things for correct SEO for CMS that aren't done by default on installation. Search optimising is normally a process that must be applied to websites of any type in order for them to comply with the required standards, and dynamic sites are no different. Joomla cannot offer full W3CAG and Section508 support at present, and that is why it does not score 100% for SEO. In theory they are separate issues; in practice there is much commonality between accessibility compliance, legal compliance, and SEO best-practice compliance.
Note very carefully that adding poorly-coded templates and modules will wreck the code validation, so this has to be watched for. A frequent task is hacking the files for such additions and fixing the code validation errors; however, this is not problematical if you know even simple coding. Repairing faulty development work is every sysadmin and SEO staffer's stock-in-trade, so it's nothing new.
WordPress scores well on SEO because, like Joomla, all parameters are adjustable via plugins. Out of the box - as most dynamic apps are - it's horrible; but when you have it set up correctly it will put you at #1 if your site deserves it.
WordPress as a fully-loaded CMSThere are numerous problems here. Trying to load up WordPress to do the job of bigger and more capable applications doesn't work well. When the page count in different sections doing different jobs starts to climb - with a checkout system, several content sections, and a blog as well - then management and SEO problems start to appear. There may well be plugins to handle the URLs in different sections; to take care of the metadata for big page numbers; to ensure there are no duplicate URLs or 'dynamic URL loops' that go on forever - but there are sites out there with problems in all these and more. It is so much easier with a real CMS, because it is designed in the first place to handle all these kinds of things. If you think that expanding WP to look like a fully-loaded Drupal site will be OK, then you will be disappointed. It can never work as well and that's all there is to it. Stick to a few hundred pages in one type of content section; or a few pages in different sections of varying content types, and you should be OK. Overcook it and you will be spending a lot of time managing it that would be unnecessary with the correct application.
The single thing we notice more than anything else about people who try to run WordPress as a CMS is that they have 3 times as much work to do compared to if they had a proper CMS in the first place. And the result is still not as good.
MovableType
This webapp is a better proposition for a transition app that falls between a basic publishing tool and a CMS. It expands well to form a basic CMS / complex blog - whichever you want to call it.
Micro CMSThere is a very good argument for creating a new type description for blog-cms crossovers, called the Micro CMS class. As the superblogs get more capable, and as more people start building dynamic websites and need simpler tools, these applications will become even more popular. We think WordPress and especially Movable Type are good candidates for this description.
Joomla for a blogAnother interesting set of questions here is: how good is Joomla at blogging? Which is best as a blog app? On a Joomla site, would you use a Joomla plugin blog or a WordPress parallel install (or a bridge) instead? Imagine a situation where you need to add a blog to a Joomla site. How would you do it? Which way would you go - use a J plugin, or co-install / bridge
We've done it both ways, and there were advantages to each. There are a lot of questions to ask here first, mainly about what your priorities are, and the answers will easily affect the decision. Firstly, your blog URL needs to be as follows:
www.your-site.com/blog/filename.etc
It should not for instance be blog.yoursite.com, for many reasons. Of course htaccess rewrites can fix this - they can fix anything - but starting out right is preferable.
If you want maximum marketing performance from your blog, and would like to keep registered commenters out of your main site for security reasons - then using WP as the blog app, linked-in to the CMS, is the best way. This way you will have two membership lists; and WP can be used as a full-feature blogging tool, for which it is peerless. A WordPress install as a standalone blog cannot be beaten for its main purpose.
If you want easy management of the resulting efforts, above all else, then a J-plugin will be the best option. On balance we actually prefer the separate full WordPress installation because it does the job better, assuming that you are mainly blogging for the marketing / SEO / commercial benefit. If not, then the integrated plugin route would be easier. We wouldn't claim that managing the two discrete apps resulting from separate installations is painless, but the only real drawback (which may of course be an advantage to some) is the separate membership lists.
An integral Joomla blog will give you complete control over templating; make the process as painless as possible; integrate the blog seamlessly in all departments so that it looks and acts smoothly; will have SEF URLs as well if you use the right URL solution (there are 10 or more SEF URL plugins for Joomla); now includes all the add-ons like tags and RPC pings; and will probably look more professional. As long as the resulting URLs are in the format your-site/blog/file.etc, and you are happy to have an integrated site membership list (blog commenters, if registration is needed, will be website members), then this is a fine solution.
Joomla ACL (control of user access rights) is not good enough at present*, so the core application does not give you the option to compartmentalise various member groups. This can be fixed via plugins (of course!), but the result is (a) not equivalent to a full ACL implementation, and (b) requires more work, listing members who can do this or can't do that. The simple way to keep the blog and CMS members separate is to install two discrete applications. This compartmentalises each very well, and if there is an exploit of one it cannot affect the other. Both are very robust apps in any case, due to the fact each has a massive user base and therefore experiences frequent attacks. With sufficient community support, exploits are patched rapidly and the resulting app is robust and resilient. Now, exploits tend to be rare and not of a serious nature, since so much has been done to fix the problems that all server-side webapps have in this area. With the vast communities each application has, progress has been very solid here - and actually compares well with similar commercial products. * Update: at Q2 2011, the new 1.6 version (currently at 1.6.3) with core ACL is now a usable proposition. Templates and plugins are still in short supply though.
Can WordPress and Joomla share the same database ?There are three ways this can be done:- A co-install, using the same database, using different DB prefixes.
- A bridge, which is a co-install but with a middleware application to join them, and in this configuration they can use the same DB, but as above, with prefixes.
- A WordPress plugin for Joomla, where the blog app is modified to plug in to the CMS. This uses the same DB and no user input is needed, unlike the above situations, as the applications manage the DB issues.
The simplest method is the first, a simple co-install. Joomla is the main webapp and is installed to the webroot. This means it is installed 'loose' into the web directory, not into a folder (aka a sub-directory). When installing it, you use a 'DB prefix' which means to have the Joomla tables prefixed with jo_ for example. Then, only Joomla can see those tables, even if there are others in the same DB. Then, WordPress is installed in a directory (the server name for a foilder). During the install you select to use a DB prefix of wp_ for example. Then only WP can see those tables. You set up the main (webroot) htaccess file for Joomla. The WP directory has its own htaccess file. In this way, each is independent of the other. The main web application is the CMS, Joomla. WordPress is used as the blog tool and linked to in any of several ways. Each webapp is independent and does not conflict with the other. However, this method, using a common database, is not satisfactory for large or heavily-loaded sites as the single DB is loaded excessively. Large sites need several databases in order to function smoothly.
A Joomla - WordPress bridge
An explanation of co-installation and bridging: a co-install is separate installation of the two applications on the same webspace. They can be linked-in as appropriate - with links from and to various pages in the two apps - but the membership lists stay separate. The result is two discrete applications. Bridging refers to a more complete integration, and the core requirement is to have one membership list, plus the login session is shared. Next in line would be a WordPress plugin for the CMS. There are several of this type, with various levels of success in the area of full integration of one into the other. J v WP - the tech specBoth are PHP - MySQL applications, so they run on a standard webserver (LAMPP - Linux / Apache). They can also run on a Windows IIS server as long as it is a correctly-run one, with PHP and MySQL installed on it (some don't have this as they are run by resellers etc). Joomla and WordPress are both free open-source apps so there is no cost difference. Plugins are 90% or better free, though some of the most capable ones are commercial - but very cheap in comparison with other applications. Both need a MySQL database, so for a full installation of both Joomla and WordPress as separate and discrete applications, you'll need 2 DBs. This is not a problem on normal hosts, where 2 or 3 databases as a minimum on the cheapest account is the norm. If your host does not provide several free databases, they don't really qualify as web hosts, since this is a core requirement nowadays. Move.
In cases where moving hosts is not an option, and you only have one database, it is still possible to install both Joomla and WordPress; they can share a database. You need to give each a prefix in the database tables so that they can share the DB. This is set up on installation. For example, you could have Joomla use the prefix jo_ and WordPress use wp_ and this is a common method. It is not an acceptable solution when each has 10,000 pages - but in this scenario we are probably looking at 1,000-page sites as a maximum in any case.
Joomla v WordPress - the last word
You cannot compare a blog app and a CMS as they are like an electric drill and a jigsaw - you can only compare a Smith drill versus a Jones drill. If you want to get online fast, and need the best streamlined publishing tool there is - use WordPress.
If you have several different tasks in mind - and slick presentation is one of them - use a CMS. And use a comparable CMS at least, should you feel the urge to go around comparing WP with fairly dissimilar apps: CMS-MadeSimple is a closer match. In that regard, if you needed full control of templating and menus, CMS-MS would probably be a better proposition than WordPress.
Using either, an expert can do a lot. A fully-loaded WordPress site doesn't look like a WP site at all, and has extended capability. If you're familiar with the app and it does what you need in this line - then fine. If you want to go the whole way, though, it has to be a CMS.
Realistically, there is little difference between the core processes of a PHP / MySQL blog application or CMS. They are of course the same thing - a bunch of PHP scripts that interact with a database. However, the difference is their aspirations - what the developers intended their function to be in the first place. Just as it is difficult to turn a small and simple CMS into a complex enterprise-level application, it's difficult to turn a Notepad-for-the-web application into its Word equivalent. Sure, it can be done, but there's a lot of growing to do on the way. And it would have been easier to start with a big enough framework in the first place.
The site owners we know who use WordPress as an extended webapp in CMS mode have three times the work to do compared to Joomla owners, and the results are not as good.
WP is a quick publishing tool and a micro-CMS. Joomla is a multimedia publishing tool and a full CMS. Which is best for you depends entirely on what you need it for. The straight answer is probably that more people will find WP is the best fit, as they are not running the sort of online business that can benefit fully from a complete CMS.
Updates
WordPress is making massive strides down the road to acceptability as a micro-CMS. The zip installer size is now up to 2MB in size, and there are around 5,000 plugins - probably the same as Joomla, and this is a tremendous achievement.
Joomla - basic tech spec
application type: multimedia publishing tool WCMS
cost: free
license: OSS (GNU - GPL)
installer includes: core files, 1 visual editor
installation type: remote via web, or on local machine
codebase: PHP, MySQL
database type: MySQL
server type needed: LAMP, IIS
[a Microsoft IIS server will need PHP and MySQL, but can never run at 100% as an htaccess file is needed for some functions]
dedicated server needed? no
additional server apps needed: no
zip size: 6MB
# of plugins available: ~5,000
shopping cart option: yes - several including an ecommerce CMS version
WordPress - basic tech spec
application type: blog publishing tool
cost: free
license: OSS (GNU - GPL)
installer includes: core files including editor
installation type: remote via web, or on local machine
codebase: PHP, MySQL
database type: MySQL
server type needed: LAMP, IIS
[a Microsoft IIS server will need PHP and MySQL, and cannot work 100% as an htaccess file is needed, as for all PHP-MySQL webapps]
dedicated server needed? no
additional server apps needed: no
zip size: 3MB
# of plugins available: ~5,000
shopping cart option: yes
|
Joomla v WordPress
