Finding and Fixing Joomla! 1.5x Customization Problems

Understanding common errors

There are five main areas that cause the majority of problems for Joomla! sites. Understanding these areas and the common problems that occur with in each of them is a very important part of fixing them and thus, our site.

Even though there is a practically unlimited number of potential issues and problems that can occur, there are certain problems which occur much more regularly than others.

If we understand these main problems, we should be able to take care of many of the problems that will occur on our site without needing to resort to hiring people to fix them, or waiting for extension developers to provide support.

The five areas are:

  • PHP code
  • JavaScript code
  • CSS/HTML code
  • Web server
  • Database

We will now look at the two most common error sources, PHP and JavaScript.

PHP code

Because PHP code is executed on the server, we usually have some control over the conditions that it is subject to.

Most PHP errors originate from one of four sources:

  • Incorrect extension parameters
  • PHP code error
  • PHP version
  • Server settings

Incorrect extension parameters

It is often easy to misunderstand what the correct value for an extension parameter is, or if a particular parameter is required or not. These misunderstandings are behind a large number of PHP "errors" that developers experience when building a site.


In a well-coded extension, putting the wrong information into a parameter shouldn't result in an error, but will usually result in the extension producing strange or unexpected output, or even no output at all.

In a poorly coded extension, an incorrect parameter value will probably cause an error. These errors are often easy to spot, especially in modules, because our site will output everything it processed up until the point of the error, giving our page the appearance of being cut off.

Some very minor errors may even result in the whole page, except for the error causing extension, being output correctly, and error messages appearing in the page, where the extension with the error was supposed to appear.

A critical error, however, may cause the site to crash completely, and output only an error message. In extreme cases not even an error message will be output, and visitors will only see a white screen.

The messages should always appear in our PHP log though.

Fixing the problem

Incorrect extension parameters are the easiest problems to fix, and are often solved simply by going through the parameter screens for the extensions on the page with the errors, and making sure they all have correct values.

If they all look correct, then we may want to try changing some parameters to see if that fixes the issue. If this still doesn't work, then we have a genuine error.

PHP code error

Extension developers aren't perfect, and even the best ones can overlook or miss small issues in the code. This is especially true with large, complex extensions so please remember that even if an extension has PHP code error, it may not necessarily mean that the whole extension is poorly coded.


Similar to incorrect extension parameters, a PHP coding error will usually result in a cut-off page, or a white screen, sometimes with an error message displayed, sometimes without.

Whether an error message is displayed or not depends partly on the configuration of your server, and partly on how severe the error was. Some servers are configured to suppress error output of certain types of errors.

Regardless of the screen output, all PHP errors should be output to the PHP log. So, if we get a white screen, or even get a normal screen but strange output, checking our PHP log can often help us to find the problem.

PHP logs can reside in different places on differently configured servers, although it will almost always be in a directory called logs. We may also not have direct access to the log, again depending on our server host. We should ask our web hosting company's support staff for the location of our PHP log, if we can't easily find it.

Some common error messages and causes are:

Parse error: parse error, unexpected T_STRING in...

This is usually caused by a missing semi-colon at the end of a line, or a missing double quote (") or end bracket ()) after we opened one. For quotes and semicolons, the problem is usually the line above the one reported in the error. For missing brackets, the error will sometimes occur at the end of the script, even though the problem code is much earlier in the script.

Parse error: syntax error, unexpected $end in...

We are most likely missing a closing brace (}) somewhere. Make sure that each open brace ({) we have has been closed with a closing brace (}).

Parse error: syntax error, unexpected T_STRING, expecting ',' or ';' in...

There may be double quotes within double quotes. They either need to be escaped, using a forward slash before the inside quote, or changed to single quotes.

Fixing the problem

Fixing a PHP code error is possible but can be difficult depending on the extension.

Usually when there is a PHP code error, it will give a brief description of the error, and a line number. If nothing is being output at all, then we may need to turn error reporting up as described later.

We will then go to the line specified to examine it and the lines around it to try and find our problem. If we can't find an obvious error, then it might be better to take the error back to the developer and ask them for support.

PHP version

The current version of PHP is 5.x.x and version 6.x is expected soon, but because many older, but still popular, applications only run on PHP version 4.x.x. It is still very common to find many Web hosting companies still using PHP 4 on their servers. This problem is even more unfortunate due to the fact that PHP 4 isn't even supported anymore by the PHP developers.

In PHP 5, there are many new functions and features that don't exist in PHP 4. As a result, using these functions in an extension will cause it to error when run on a PHP 4 server.


Diagnosing if we have the wrong PHP version is not obvious, as it will usually result in an error about an unknown function when the extension tries to call a function that doesn't exist in the version of PHP installed on our server.

Sometimes, the error will not be that the function is unknown, but that the number of parameters we are sending it is incorrect if they were changed between PHP 4 and PHP 5.

Fixing the problem

The only real way to fix the problem is to upgrade our PHP version. Some web hosts offer PHP 4 or 5 as an option and it might be as simple as checking a box or clicking a button to turn on PHP 5.

In case if our host doesn't offer PHP 5 at all, the only solution is to use a different extension or change our web host. This may actually be a good idea anyway, because if our host is still using an unsupported PHP version with no option to upgrade, then what other unsupported, out of date software is running those servers?

Server settings

One of the most common problems encountered by site owners in regards to server settings is file permissions.

Many web hosting companies run Linux, which uses a three-part permission model, on their servers. Using this model, every file can have separate permissions set for:

  • The user who owns the particular file
  • Other users in the same user group as the owner
  • Everyone else (in a web site situation this is mainly the site visitors)

Each file also has three permissions that enable, or disable, certain actions on the file. These permissions are read, write, and execute.

Permissions are usually expressed in one of two ways, first as single characters in a file listing or as a three digit number.

For example, a file listing on a Linux server might look like this:

drwxr-x--- 2 auser agroup 4096 Dec 28 04:09 tmp
-rwxr-x--- 1 auser agroup 345 Sep 1 04:12 somefile.php
-rwxr--r-- 1 auser agroup 345 Sep 1 04:12 foo

The very first character to the left, a d or – in this case, indicates if this is a directory (the d) or a file (the -). The next nine characters indicate the permissions and who they apply to.

The first three belong to the file owner, next three to those in the same group as the owner, and the final three to everyone else.

The letters used are:

  • r—read permission
  • w—write permission
  • x—execute permission

A dash (-) indicates that this permission hasn't been given to those particular people.

So in our example above, tmp.php can be read, written to, or executed by the owner (a user). It can be read or executed (but not written to) by other users in the same group (agroup) as the owner, but the file cannot be used at all by people outside the however, can be read by people in the owners group, and also read by everyone else, but it cannot be executed by them.

As mentioned above, permissions are also often expressed as a three-digit number. Each of the digits represents the sum of the numbers that represent the permissions granted.

For example: r = 4, w = 2, and x = 1.

Adding these together gives us a number from 0-7, which can indicate the permission level. So a file with a permission level of 644 would translate as:

6 = 4 + 2 = rw
4 = r
4 = r

or -rw-r--r-- in the first notation that we looked at.

Most servers are set by default to one of the following:

644 -rw-r--r--
755 -rwxr-xr-x
775 -rwxrwxr-x

All of this looks fine so far. The problems start to creep in depending on how the server runs their PHP. PHP can either be set up to run as the same user who owns all the files (usually our FTP user or hosting account owner), or it can be set up to run as a different user, but in the same group as the owner. Or it can be set up to be a completely different user and group, as illustrated here:

Finding and Fixing Joomla! 1.5x Customization Problems

The ideal setup, from a convenience point of view, is the first one where PHP is executed as the same user who owns the files. This setup should have no problems with permissions.

But the ideal setup for a very security-conscious web host is the third one since the PHP engine can't be used to hack the web site files, or the server itself. A web server with this setup though used to have a difficult time running a Joomla! site. It was difficult because changing the server preferences requires that files be edited by the PHP user, uploading extensions means that folders and files need to be created by the PHP user, and so on.

If the PHP engine isn't even in the same group as the file owner, then it gets treated the same as any site visitor and can usually only read, and probably execute files, but not change them. This prevents us from editing preferences or uploading new extensions. However, if we changed the files so that the PHP engine could edit and execute them (permission 777, for example) then anyone who can see our site on the internet can potentially edit and execute our files by themselves, making our site very vulnerable to being hacked by even a novice hacker.

We should never give files or directories a permission of 777 (read, write, and execute to all three user types) because it is almost guaranteed that our site will be hacked eventually as a result. If, for some reason, we need to do it for testing, or because we need to in order to install extensions, then we should change it back as soon as possible.


To spot this problem is relatively simple. If we can't edit our web site configuration, or install any extensions at all, then nine times out of ten, server permissions will be the problem.

Fixing the problem

We can start by asking our web host if they allow PHP to be run as CGI, or install suEXEC (technical terms for running it as the same user who owns the files) and if so, how do we set it up.

If they don't allow this, then the next best situation is to enable the Joomla! FTP layer in our configuration. This will force Joomla! to log into our site as the FTP user, which is almost always the same user that uploaded the site files, and edit or install files.

We can enable the FTP layer by going to the Site | Global Configuration page and then clicking on the server item in the menu below the heading. We can then enter the required information for the FTP layer on this screen.

The FTP layer should only be used on Linux-based servers. More information about the FTP layer can be found in the official Joomla! documentation at

If for some reason the FTP layer doesn't work, we only have two other options. We could change our web hosting provider as one option. Or, whenever we want to install a new extension or change our configuration, we need to change the permissions on our folders, perform our tasks, and then change the permissions back to their original settings.

JavaScript code

Recently, the majority of errors on Joomla! sites seem to be related to JavaScript. This is probably because many, if not most, newer templates and extensions rely on JavaScript to operate. Because of this, many sites can have massive amounts of JavaScript being loaded on each page and if one piece of JavaScript fails, it can often bring down others. Then menus can stop working, images can stop moving, and so on.

Because JavaScript is executed on the visitor's machine and not on the web server, things that work fine in one browser on one type of operating system might not work at all on another browser or a different operating system. This can make diagnosing and fixing the errors difficult sometimes.

Joomla! site JavaScript errors are usually the result of one of three things:

  • Library conflicts
  • Too much JavaScript on one page
  • Multiple "once per page" scripts

Library conflicts

In order to make it easier to work with JavaScript, certain groups of developers have banded together to create JavaScript libraries, which are a collection of functions that do common tasks, such as moving things around or hiding and showing them, but make them easier to use.

Many different libraries are in use around the Internet, but in the Joomla! sphere, there are two main libraries used by extension and template developers. These are Mootools and jQuery. The Mootools library is even included in Joomla!, so it's difficult to escape from this one.

Even though Mootools and jQuery are the main libraries used, some extensions may use other libraries such as Prototype, YUI, Dojo, and so on.

When we install extensions that contain some shiny JavaScript features like sliding images or folding menus, we don't often consider the implications of that install.

For example, if your template loads a copy of Mootools, and then one of the extensions on our page also loads a copy of Mootools, then not only are we making the page unnecessarily slower, but also there is a good chance that any Mootools-related JavaScript will just fail altogether. This is especially likely on Internet Explorer, which has a fragile JavaScript engine.

The same thing can also happen if you load two different types of JavaScript library on the same page, such as a copy of Mootools and a copy of jQuery.

This is probably the most common JavaScript error I personally see, and in fact the most common error overall when working with my own Joomla! clients. Thankfully, it is usually the easiest to fix.


The easiest way to spot this problem is if a page loads fine in Firefox or Safari, but all the JavaScript stops working in Internet Explorer. If this happens, then it is usually because 2 copies of the same library have been loaded.

If we have the symptoms below, then it is likely that the extensions are loading different JavaScript libraries.

  • They work fine when loaded alone on a page
  • One or both of them stop when loaded on he same page
  • Happens in most or all browsers

If we have these symptoms, then we should right-click on our page and select the option that says View Page Source or something similar, as shown:

Finding and Fixing Joomla! 1.5x Customization Problems

A new window or tab should now open showing us all of the HTML source code for our page, similar to the following screenshot:

Finding and Fixing Joomla! 1.5x Customization Problems

Now, we want to check what JavaScripts are being loaded by our page. Well-written templates and extensions will usually have all their JavaScript loaded in the <head> section of our page. Unfortunately, however, not all extensions are well written, so we may find JavaScript being loaded anywhere on our page.

From here, we can either skim read the source looking to see which libraries are loaded, or use the browser's built-in search option to look for the word script. This is because every JavaScript file that is loaded will need to be within <script> tags.

Inside these script tags we are trying to find files with a name containing any of the following words:

  • mootools
  • jquery
  • yui
  • prototype
  • scriptalicious
  • dojo
  • extjs

This is not a complete list of available JavaScript frameworks, but these are some of the more popular ones available.

The filenames will sometimes have version numbers or other words in them, as seen below, but they should still be easy to recognize if we look for the aforementioned names.

Finding and Fixing Joomla! 1.5x Customization Problems

Often, an extension or template will load the JavaScript library file, and then load their own files that use the library after them. The name of these supplementary files may also contain the name of the library, for example mootools-adapter.js, so be careful when identifying the files.

If we find multiple copies of the same library loaded, or multiple libraries loaded, then we can be confident that this is the cause of the problem.

Fixing the problem

We can fix our problem in one of two ways, depending on whether we have the same library loaded twice, or two different libraries loaded.

Same library loaded twice

If the same library is being loaded twice, we just need to stop one copy of the library being loaded. This can be done in one of three ways.

The first, and easiest, way requires that the conflicting extensions, at least one of them anyway, has been well written and has a parameter option to control whether the library is loaded or not. This option is unfortunately still not available in many extensions, but the number that supports it is growing.

The second method is very quick and dirty, and while I don't recommend it, it will fix the problem for people who don't want to change any PHP code. Simply remove, or rename, the offending library file. When the browser tries to load it, it can't find it so it will just continue on.

The third method is to edit the PHP code of our extension in question and comment out, or delete, the code that loads the JavaScript file. The script will most likely be loaded in our view files for components, and in the main file for modules and plugins. The line of code which we will want to remove will look something like:


When deciding which extension's library to remove, we need to make sure that we choose whichever one is loaded second. This is because there will almost always be some other JavaScript code loaded by the first extension that requires the library to be in place for it to work. If we remove the first copy of the library and not the second, then the support code from the first extension will fail, but the code from the second one will likely execute correctly.

Finding and Fixing Joomla! 1.5x Customization Problems

Different libraries loaded

Dealing with different libraries is a little more difficult than multiple copies of the same library. Sometimes, unfortunately, the only solution is to choose one of the extensions to remove or replace because most JavaScript libraries simply won't work with each other.

One exception to this is jQuery, which can be put into compatibility mode. This usually requires only a small amount of JavaScript code to be added, and then jQuery will be able to work with most other libraries. More information can be found at:

If we are lucky, the extension and template developers using jQuery will have already put jQuery into compatibility mode for us, but this is not always the case.

For other libraries, there is a trick we can try that sometimes works. The trick is to try mixing up the order that the scripts are executed in, usually achieved by changing the order in which the extensions appear. More often than not this won't work, but with some simple scripts it can sometimes work.

Why this sometimes works is that after the first library is loaded, the supplementary scripts will usually be loaded. If the actions these scripts perform are done at load time, and are not repetitive, for example changing the color or loading RSS feed, then all of the scripts related to the first library finish executing before the second one is loaded. The problems creep in when the supplementary scripts of the first library are set to execute repeatedly or after the second library has loaded, for example, on click events for links or buttons or a slideshow. In this case, the supplementary scripts associated with the first library, and possibly those of the second library as well, will fail.

This trick is also more reliable in web browsers like Firefox, Safari, and Opera that have solid JavaScript engines. It most likely won't work in Internet Explorer, which, as mentioned above, has a fragile JavaScript engine.

If none of the above work, then the only thing we can do is remove, or replace, one of the extensions.

Too much JavaScript

This problem isn't very common, but if it occurs, it will usually be on Internet Explorer, especially IE6 and IE7, though it does occasionally strike other or all browsers.

If we put too many sliding panels, slideshows, shoutboxes, draggable areas, Ajax rotators, and so on into our site, the JavaScript engine will begin to get congested and slow down, get choppy and jumpy, and in some cases may even stop altogether.

This particular problem is difficult to diagnose as it may not affect people with more powerful computers, or more up to date browsers, as much it will affect people with less powerful computers or older browsers.


The best way to diagnose this situation is through common sense. Have you added more than 5-10 different extensions to the same page all with JavaScript powered moving parts? Does the page load correctly when any one of the extensions is missing, but not when every one of them is loaded (meaning it isn't a conflict between any two specific extensions)?

If we answered yes to those two questions, then there is a good chance that we have too much JavaScript being loaded, especially if the problem only occurs in Internet Explorer.

Fixing the problem

Unless we are a professional JavaScript developer and know how we can trim the different scripts down, the only solution here really is to reduce the amount of JavaScript we are loading by removing or replacing some of our extensions.

While for some of us this may not sound like a good solution. If we have gotten our site to the point where we have so much JavaScript being loaded that it's slowing down or stopping the site, then we are very likely to have assembled a Frankensite anyway. Our site is likely to have so many moving parts that we probably give our visitors motion sickness. Keeping our site simple is almost always the best option.

Multiple "once per page" scripts

Some JavaScript is designed to run only one time per page. For example, a menu with sliding panels or an Ajax RSS feed module. This code will often have been written to look for a specific CSS id in an HTML tag, such as the tag below.

<div id="slidingmenu"> HTML here...</div>

A CSS id should only appear once per page, but if we were to put our sliding menu module on the same page twice, we would end up with the following:

<div id="slidingmenu"> HTML here...</div>
...some other HTML...
<div id="slidingmenu">...HTML for second menu here...</div>

Then when the JavaScript that activates the sliding portions of the menu is executed the first time, because it is looking for an id, it only executes once, on the first instance of the id, which is fine. It is when the JavaScript from the second copy of our menu is executed it again finds the first instance of the id, which happens to be the same as the instance the first script found.

The result being that the first copy of the menu has the JavaScript executed on itself twice, and the second copy has nothing executed on it.


The easiest way to recognize this situation is when one copy of an extension works fine, but if it appears twice on a page, then only the first one, or neither of them, works.

If this occurs, check the source code of our page to see if the two extensions output identical ids on any of their parts.

Fixing the problem

This is a difficult issue to fix without diving into the code ourselves, so the easiest method is to take it to the developer of the extension and ask them politely to make a change to the code. They will need to put some sort of identifier into the code to make each instance of the extension unique. Using the module id or plugin id is usually the best option for this if the cause is a module or plugin.

If we can tell the developer clearly what the problem is and why, then there is a greater chance of them doing it for us.

Hacking the core

Even though the practice is dying out, there are still several extensions around that make changes to the core Joomla! files. This practice was much more common in Joomla! 1.0 than in 1.5, as 1.5 provides the ability to replace or override a lot of core functionally without having to make changes to the core code.

Most often, core hacks are used to provide enhancements or extra functionality to the user or access level systems within Joomla!, as these functions were very difficult to influence from outside the core until recently.

More commonly though, people are not hacking the core code, but making changes to the default templates included in Joomla!. Rather than acquiring a new template, they just make changes to one of the existing default ones.

Both of these practices, hacking the core and changing default templates can set site owners up for many difficulties. The most important one being that if we update our site to a newer version of Joomla!, then there is a good chance that we will replace any hacked or edited files with the ones that haven't been hacked. This means that all our work will be undone.

Many components that hack the core have a process for updating, usually involving updating to the latest version of their software, then un-hacking our site, updating Joomla!, and reapplying their hacks.

This also needs to be remembered for any extensions that we make custom changes to. When we update them, there is a good chance that it will undo any changes we made.

In this case, we should put a copy of our edited files aside, and then once we have updated the extension, we should make the changes to the files again, using the old files as a reference. It is best not to simply copy the old file up to our server there might have been changes to the file in the update, which we would undo if we just copied the old file up.

Solving the unsolvable

There will be times where no matter what we do, we can't solve an issue with an extension ourselves. In these cases, we will have to go elsewhere for support.

Self support

Most people's first impulse is to run to the developer and ask them a question, usually on their support forum. But often there are more efficient ways to solve our problem than just dumping it on someone else. We should try all, or at least most, of the below methods before we ask the developer ourselves.

The reason we should try ourselves is twofold, first because, as mentioned above, it can often be more efficient and take less time for us to get our answer. Second, it builds our independence and our own skills, making us less dependent on other people in the future.

Search the support forum

From my own observations, over 40% of questions that I see on support forums, have been asked before. If I am responding with an answer I simply find a link to that thread and post it, or I cut and paste the answer.

Failing to do even a basic search before submitting our support request simply wastes everyone's time and often, especially if it is a common question, the only answer we will get is a curt "search the forum that has already been asked before".

If we search the forum, then we can often cut out several hours, or even days, of wait time and get our answer now. At the very least, if our search returns nothing then we can be confident that it's a new problem and worth bringing up.

When searching, we should try to be creative with our search strings:

  • If there is an error message, put all or part of it in the post. The same goes for error codes.
  • Try shorter strings before longer ones.
  • Try different ways of wording the problem "will not delete", "can't remove", "cannot get rid of", and so on as people express things differently.

If we did search the forum but failed to find anything, then saying so in our support request will win you some goodwill with the developers because we showed some initiative instead of just expecting them to solve everything for us.

Search the Internet

As with searching the forum, searching the Internet can often give us our answer without needing to wait for it. For very popular extensions, PHP or JavaScript errors, or the Joomla! core itself this should probably be the first place we try, even before the developer's site.

Just like forum searching, mentioning that we have already searched the Internet can boost our chances of a positive support response.

Read the Manual/FAQ

Not all Joomla! extensions come with manuals, but if the one we are working on has a manual or FAQ page then we should probably check it out after we do our searches, but before we make a support request. Often, common problems are listed on these pages.

Ask a skilled friend

This option may not be available to all of us, but if we have a friend or associate who is a Joomla! expert, then they might have experienced the problem we are facing. We must be careful not to abuse this assistance however, as they may not want to remain our friend for long if all they spend their time doing is helping us on our site. We need to remember to be considerate of their time.

Support requests

If all of the above fail, it's time to head to the developer and submit a support request of some kind.

There are several different methods we can use for submitting our request, each with their own strengths and benefits. Which ones are available to us depends on the extension developer.


If available, a forum should be our first choice when submitting support requests. This is for one main reason, many more eyes on a single problem. Often, a question posted on a public forum won't be answered by the staff, but by other community members and customers.

Forums are also searchable, so if another person later has the same problem as us they can find our post and see the answer we received, fixing their problem faster than if they had to wait for an answer.

This search ability is also useful for us before we commit to using or purchasing an extension, as we can take a look to see how reliable the support is and how many bugs are in the software.

The downside to forums is that they aren't private, so we need to be careful posting information up there like passwords, our domain, or personal information. Also, in a large, busy forum there is a possibility that our request will get overlooked, especially if it is a poorly written one (as we will discuss next).


Tickets are usually the most reliable location for support requests, and are rarely overlooked. They are also usually private, so we can post sensitive information without much fear.

Tickets are useful in that they usually record a history of the issue, allowing us to track what happened and when.

This privacy however makes it difficult, or even impossible, to benefit from previous people's solutions. Often, we will find that if we ask a common question, then we will only get an impersonal, pre-written reply.

Tickets also make it difficult to gauge how widespread problems are with the software before using it, and how responsive the developer is to supporting it.


Email seems to be the preferred method of support for many people. It feels personal to contact someone directly, and makes us comfortable to think that someone we know is on the job. But the reality is very different.

Many developers, just like the rest of us, get dozens of emails a day or more. Many of them much more urgent to the developer than our problem. Plus, when reading their email, a developer is often not directly working at that time so will put our request on hold until the next time they are working. As a result, they will occasionally just be forgotten, buried under all the other mails.

On the other hand, a developer will usually only look at the other non-email support avenues when they are actively working and looking for support issues to solve, so the chances of them answering our request promptly are greatly improved.

As we can see, email is potentially the least reliable and timely of the support avenues. To make matters worse, many developers will see it as an invasion of their privacy to be constantly bombarded with "help me" and "fix this" emails in their personal accounts, on their personal time. This makes them reluctant to give us help, and they may just ignore our email altogether.

It is not all bad news however, as email support can be useful and prompt if used in conjunction with a specific, monitored, business only email address.

Support request etiquette

Now that we know the different routes for getting our support, it is time to look at how we can influence the results we get from our requests.

Going to a developer for support is an experience that can be either helpful or painful, depending on two main factors: firstly, the developer's attitude, and secondly our own attitude.

The first one we unfortunately can't do anything about. If a developer doesn't care about supporting their product, there probably isn't anything we can do to change their mind. We have a few alternative options though:

  • Hire a skilled developer familiar with the extension to fix it
  • Try again to fix it ourselves
  • Replace the extension with a different, similar one, or drop the feature altogether

They may not be fantastic options, but they are options.

If the developer is interested in supporting their product however, as it is usually the case, then it is our own attitude and actions that will affect how good the service we receive is.

There are a lot of factors in our behavior that will influence how much and how in depth the support we receive is. Let's take a look at some of these factors and how we can best utilize them to improve our chances of getting good support.

These factors can apply to any of the support routes, forums, tickets, or emails.

Act like we respect the helper and their time

This is the single most important factor in support, and in fact almost every other factor is simply a different way of showing this. If we go into any support request appearing to have no respect or concern for the person on the other end, then the best we can expect is a cold, bare minimum response. At worst, we will get no response now, and possibly none in the future regardless of what we do or say after.

The biggest way to show our respect for other people's time is to put in some effort to make it easier for them to help us out and not just expect them to drop everything they want to do and instead do everything we want them to do.

This is especially important for free extensions, or the Joomla! core itself, because the people answering are working on a totally voluntary basis and are under no obligation to help us. However, it still applies to commercial extensions, because even though we have paid for something we want to receive good service, not just minimum service.

It is also important to show some politeness and personal respect. "Please" and "Thanks" go a long way ensuring prompt, reliable support. Remember that the support person is just as much a human being as we are and we should follow the golden rule of treating them as we would like to be treated.

Choose our forum/category/email target carefully

The people who monitor forums, tickets, and email addresses often are specialized in that area, and may not be in others. In the case of forums, the people viewing that particular forum are interested in that subject.

Posting to the wrong place will make us look like we haven't done any research, or for that matter, care about the protocols of the group. If we don't care about them, why would they want to care about us?

Different mistakes people often make in this factor are:

  • Posting a request to the first email address/forum/category that we come across
  • Posting to a personal email address of somebody who is neither an acquaintance nor responsible for solving our problem
  • Posting a request where it's clearly off topic (such as installation questions in a customizing forum)
  • Posting an unrelated question in a thread or ticket that was started with a different problem
  • Posting multiple times in different places (this one will get us ignored almost immediately)

Write a useful, meaningful subject line

The subject of our request is one of its most important parts. This is because people scanning tickets, forums, and emails can often identify what it is we want, and if they are able to help us before even looking at our request in detail. It will allow qualified people to find us quickly and unqualified people to not waste their time.

Remember that we want to encourage people to help us, and wasting their time makes them less likely to do so.

Our subject line is not only a description of our problem, but it is also a perfect illustration of ourselves and how much effort we are putting into solving our own problem. People will look at it and can guess immediately what kind of person we are, a needy person who wants a solution done for them, or someone willing to fix the problem themselves who is just looking for a pointer on how to. Only one of these types of people get good support, and I don't think I need to point out which one.

Some common subject lines we can see on forums, and why they are productive or counterproductive, are listed below.

Please help/I need help/can someone help me/help me!!!!!!!!!!

This sort of subject will get ignored as a reflex by almost everyone on a public forum. Paid or dedicated support people will probably read it, but will have a negative attitude about it because they aren't sure if it's for them or another support person.

Because we didn't put any thought or effort into writing a good subject line, other people will think that we are lazy and just want someone to solve our problems for us. Rightly so, they won't want to waste their time on us.

The only worse thing than this is if the title is in all capitals, which is the written equivalent of shouting. All capitals will turn off everyone before they even look at our post.

Urgent/help now/important

Just as bad as the previous subjects, this will turn most people off immediately. The reason being that our deadline simply isn't as important as their own deadlines.

A subject like this is the same as saying to everyone who reads it that our problem is more important than theirs and we think they should stop what they are doing and help us now. This sort of statement is very unlikely to be received well.

Titles like this are actually more likely to get us a slow response or no response at all, so they are totally counterproductive.

Again, all capitals is even worse.

Slideshow module doesn't work

Significantly better than the examples above, this subject may actually attract a couple of passerbys, and will get the right support people helping us out. But it still won't be enthusiastic help.

This sort of subject shows we are prepared to articulate the absolute basics of our problem, but we haven't done any in depth though about it and probably haven't provided much information in our post body.

It also shows we have very little technical knowledge and don't understand what the cause of our problem is, and don't want to find out. Experts want to avoid this kind of support request because they will have to explain everything in great detail to such a person, or have to do the work themselves.

Magic Slideshow V1.02—no animations due to JavaScript error

This is a much, much better subject line. We have the full name of our extension, including the version and we have a clear but concise statement of the problem and cause.

A subject line like this in a public forum is likely to get at least twice as many people read it as the previous subject, and at least ten to twenty times as many as the "Help me" or "Urgent" style subject. It is also much more likely to attract someone who has actual experience with our problem and is willing to help us.

It tells people that we know what we are talking about and that we have personally investigated and understood our problem but can't fix it, rather than just running here at the first sign of trouble.

Provide as much information as possible

When writing the body of our support request, it is very important that we provide as much information as possible. This is so that the people providing us with support can give us more accurate responses, and are inclined to give them.

This also saves a lot of time because if we don't provide any information, then the first thing we will be asked is to provide some basic information before they begin to diagnose our problem. No matter what happens, we need to provide this information at some point, so if we provide it up front we will get a faster response, and a more enthusiastic one.

For example, we wouldn't walk into a doctor's office and say, "Doc, I am sick, make me better," and expect them to know exactly what is wrong and what to do about it would we? Well we shouldn't do the same to support people because they can't help us without information.

Some points to explain when writing our body:

  • The environment on our server
  • The browsers where the problem occurs (if a front end issue)
  • The version of Joomla! we are running
  • The version of the extension(s) in question
  • The URL of our site, preferably a link to the problem page
  • Any error messages that are output
  • Any research or testing you did and the results of that testing/research
  • A screenshot of the problem if possible
  • A detailed description of the symptoms and how to replicate it

The sort of request below, for example, will probably get us no response at all, or simply a question asking for more information and a link to the page.

The slideshow has a bug and doesn't work.
Can someone fix it for me?

This sort of request is unproductive for a few reasons. First, we have publicly insulted the developers and their skills by assuming there is a bug in their code when it could be something we have done wrong. There are likely to be many other users who aren't experiencing our problem. We shouldn't cry "bug" unless we have, or can provide a copy of, the problem code to back our claims up; otherwise this is likely to make the developers unhappy with us, even if it is actually a bug.

Second, there is no information at all to give the support people any idea what our problem actually is. As a result, this sort of question will take at least twice as long for us to get an answer to, than if we wrote our question well.

Third, we have come across as someone who doesn't want to fix their problem, but someone who wants their problem fixed. Skilled developers are often eager to give advice to people who want to fix their problems, but try to avoid people who want their problems fixed. This is because the latter types of people usually require a lot of work to assist, but the former usually just need to be pointed in the right direction.

A better request would be like the one below.

I have installed version 1.02 of the Magic slideshow into Joomla 1.5.10 but when I view a page with it loaded in Internet Explorer 6 or 7 it doesn't move.

I found that it worked if I changed the template. Does anyone have any ideas how I can try to work out the problem?

The problem page is, you can see the slideshow at the top of the page under the menu.

Here we have provided all the information needed to make a basic diagnosis, and the developers can even check out our site to see it for themselves without having to ask us to for a link and then wait for us to post it.

It also shows that we have put some time into trying to diagnose the problem ourselves, and that we are prepared to fix it ourselves if we get the right information.

Taking the an extra minute or two when writing our support request and putting in some extra information will almost always take hours or even days off the time it takes to solve our problem, so there is absolutely no excuse not to do it.


We should now be much better equipped to tackle problems with our site.

We looked at how we can diagnose and fix some common problems with Joomla! sites.

We also now understand the implications and risks of customizing our site, and using extensions that hack the Joomla! core.

Finally, we talked about the best practices when going to others for assistance and support, and the how to go about it so that we get the most positive and helpful responses we can.

If you have read this article you may be interested to view :

You've been reading an excerpt of:

Joomla! 1.5x Customization: Make Your Site Adapt to Your Needs

Explore Title