Hi,

This is a high level summary of tools I have become used to, that help me in everyday testing and debugging of my web sites. As I am primarily a Mac person, so are my tools. However most of them are available for Windows and LINUX as well. At least it will give you an idea of how to leverage certain tools.

Good luck!

Oliver Ratzesberger
(aka fxstein)

====== Useful Tools for investigating Problems ======

Dynamic websites based on an CMS and its associated plugins and modules can be tricky to debug. Quite often problems are isolated to specific browser/os versions or a combination of multiple modules interfering with each other.
So how does one go about identifying the root cause of a problem?

==== Firefox ====

To start with I highly recommend you take a look at Firefox and some of the plugins available to aid in the search for those nasty buggers. Whether you are on Windows or Mac, there are versions available. They can be downloaded [[http://www.mozilla.com/en-US/firefox/|here]]

Once you have got yourself a version of Firefox installed, go get some plugins to help with the root causing finding mission.

==== WebDeveloper ====

The first one to get would be [[https://addons.mozilla.org/en-US/firefox/addon/60|Web Developer]]. A very feature rich plugin that let you look under the cover of any website, helps with nasty CSS issues and makes error tracking a whole lot easier. This is not the place to give you a full tutorial about Web Developer but it should get you started.

==== Firebug ====

The second tool to get would be [[https://addons.mozilla.org/en-US/firefox/addon/1843|Firebug]]. There is some overlap between the two tools but I find them both very useful.

==== JoomlaPack ====

Then there is [[http://extensions.joomla.org/component/option,com_mtree/task,viewlink/link_id,1606/Itemid,35/|JoomlaPack]]. A very useful backup solution for any Joomla install. Not only does it allow you to backup and entire Joomla site and its database, it also comes with the neat little feature to restore such a backup onto a different server - in my case my test server. It makes it possible to move and entire site with the latest data and files to the test environment within a few minutes. A must have to perform much needed testing locally, without interfering with your users.

==== LAMP - MAMP - WAMP ====

Test server? Huch!? Where are we going to run that one? Well, the best choice would be the same system you do you everyday development or test work on. In my case its my daily laptop. Nothing beats a fully integrated solution that you can take with you. I am running
a MacBook Pro with OS X and the #1 solution for my webserver needs is called: [[http://www.mamp.info/en/index.php|MAMP]]. MAMP stands for Mac-Apache-MySql-PHP - just what we need to run a full Joomla install. There is a free version of it if you are happy with a single virtual host or a Pro version that allows unlimited vhost on the same server.

Same thing for Windows [[http://www.wampserver.com/en/|WAMP]] and LINUX [[http://lamphowto.com/|LAMP]]

==== BBEdit ====

Last but not least you want a solid editor, that allows you to do some Regular Expression searching. There are many out there. My favorite one on the Mac is [[http://www.barebones.com/products/bbedit/index.shtml|BBEdit]]. Sorry - its not free, so others might chime in with alternatives. Anyway a solid editor will help in multiple ways.

===== =====
Equipped with these basic tools we can start attacking those nasty issues like java script incompatibilities.

===== How to spot potential Java Script Problems =====

By now you might have seen discussions about collisions between different versions of Jquery or mootools. What's that all about?
Without wanting to explain the full breath of potential java script issues, let me say so much: The java script frameworks are notoriously known for colliding with each other and even themselves if multiple versions of the same framework are present on a single page.

How can that happen? Once you install Joomla, a custom template, a few components, mambots and plugins, you have mixed together a cocktail of code that - in many cases - all comes with its own java script framework. Some come with mootools, others with jquery, some others with ufo. To make matters worse, you might be running an old mambot with an outdated version of one of these frameworks. The result? The site behaves strange: e.g. all the quick replies are open all the time.

==== A web browser and an editor to fight JS crime ====

So how can these tools aid you in finding the problem in that deadly mix of versions and incompatible code?
The first step is to identify what is going on.
Open the webpage in question n Firefox or you favorite web browser. Once open, view the page source code. In Firefox you will find that in >>View>>Page Source.

You should get a whole bunch of HTML source code.

NOTE: Every page on your website will contain significantely different HTML code. Not only will the obvious screen elements be different, the list of plugins and scripts will vary whether you are on the home page, the forum or your PM system. So make sure you check them out one at a time.

Once you are at the source view, I usually copy and paste the entire page (might be multiple pages of code) into my favorite editor. It allows me to do more sophisticated stuff that possible in a web browser.
The first thing to do is to find all instances of java scripts present on that page. To do so I like to use a little regex search that matches a very simple pattern.

<script.*src=.*\.js

In BBEdit I get this through checking the grep option and perform a Find All. It even allows me to perform that search over an entire directory tree, which comes in very handy if you don't know where certain includes are coming from.
Back to the page source and our search for java scripts. The regex search above will return  every instance of a javascript on that page. Again, its a very simplistic pattern and I am sure you can make it a lot more elegant and fool proof, but for me it does the trick.

{{problem:bbedit.javascript.jpg|Search results for Java Scripts}}

In this particular example you see 16 instances of java scripts for the web page we are investigating. 
The very first come from a PM solution, followed by a set of scripts for Fireboard, Multithumb and finally the mootools from the template. A rather deadly mix of java scripts that is going to cause problems in one way or another.

This page is actually including the very same scripts, named in slight variations, with different versions of java script code.
We see two version of jquery (jquery.js & jquery-latest.pack.js) as well as two versions of mootools (mootools.js & mootools.r462.js) - a big RED flag.

With this example it will lead to always open Quick Edit boxes in most web browsers and even an error message in Internet Explorer 6.  

In case you don't have access to an editor with regex search you can do the same by 'hand' and look over the source code line by line. I would still recommend doing that within an editor (e.g. Notepad) so that you can at least highlight the lines you found in a different color.

==== OK - Problem found - What's next? ====

Finding the problem is usually the difficult part, fixing it is easy. Well usually. In this case the finding part is actually very easy, the fix is a bit more involving.
It helps having a local copy of your website, that you can search, modify and test on.

To fix these issues that are most of the time multiple possible ways:

**First** of look at the list of modules, plugins and mambots and decide whether you can live without one ore more of them. Removing an extra piece of code, can fix the whole problem to begin with. That is by far the easiest fix, but it might not work for you.

The **Second** option is to edit the code of certain modules, plugins and mambots to remove duplicate instances of the same java scripts and limit it to load only the latest versions and only once. A nice side effect of this is that your download size for individual pages will shrink, helping with user experience and server bandwidth.

The **Third** option, while not particularly sophisticated and clean, gets the job done when editing the code is not an option, like with encrypted modules. In this case find the location of all the java scripts on your server and overwrite older versions with the latest version in your install. You have to keep the names identical so the unmodified code will still point to the proper files.

This is just a quick start in helping you to deal with these rather nasty java script problems. More work has to be done to make this a lot more fail safe for the average user. 

As such this is work in progress...