Compare Joomla versus WordPress
Joomla v 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 needed 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 CMS
A : Well, we don't think you can, because they are for different jobs. You don't compare a plane and a boat, so why do the same here?
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. Look at how you get several different menu types
with Joomla out of the box; how many ways to categorise and organise content; how easy it is to change the templates; and
the vast number of jobs you can do with it. They are different animals.
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.
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 pagecode, URLs and metadata, when managed correctly - say no more. However, getting any complex dynamic app with numerous extensions to validate 100%, for every page, is a painful and time-consuming business - and probably unnecessary in any case - so a few fail points are 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
accessibility due to the tables in the layout scheme; and of course
you will need to do those things for correct SEO 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.
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 dev work is every sysadmin and
SEO's stock-in-trade, so it's nothing new. Joomla cannot offer full W3CAG and Section508 support at present, though work is being done here; and that is why it does not score 100% for SEO. In theory they are separate issues; in practice there is some crossover.
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. And the result still is no way near perfect.
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.
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 WP?
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 (at the
moment), 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 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.
A Joomla - WordPress bridgeAn 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. Next in line would be a WordPress plugin for the CMS. There are several of this type, though none that claim to simply integrate one into the other.
J v WP - the tech spec
Both are PHP - MySQL applications, so they run on a standard LAMP server (Linux / Apache). They can also run on a Microsoft 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). Both are 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 better templating, menus and overall control of content and of the site - CMS-MS would probably be a better proposition than WordPress. For a simple text-based site, WP has a lot going for it.
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.
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 is not the best choice for this CMS]
dedicated server needed? no
additional server apps needed: no
zip size: < 3MB; decompressed < 7MB
# of plugins available (estimate): 3,000
ecommerce option: yes - several
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]
dedicated server needed? no
additional server apps needed: no
zip size: 1MB
# of plugins available (estimate): 1,700
ecommerce option: yes
|
Joomla V Wordpress 
