I was recently writing some code to migrate data from one database to another in small chunks (so that the progress could be reported to the browser using AJAX), but while developing on my Windows XP machine, I kept getting the above 2 error messages. This would occur only after a significant amount of data had already been processed successfully.

As the processing involved opening and closing connections to 2 different databases many times, it smelt like the connections were not being closed properly, but I double-checked everything and I was indeed explicitly closing all of the connections after use. Several frustrating hours later, I discovered the cause of the problem...

I just spent an infuriating hour trying to work out why the tooltips output by nBill, using OverLib, were always coming out with a transparent background - even if I explicitly specified a background colour when calling OverLib. I tried sending commands in the call to OverLib and setting the javascript variable, but the commands were just ignored.

It seems the solution lies in your template's CSS file...

If you want to capture one of the above events in javascript, in most cases, it will be on an input element (eg. a text box). But what if you want to capture a keypress anywhere on a document (eg. to delete a highlighted element from the page when the delete key is pressed, which is what I was trying to do)? I tried adding onkeydown to the body tag, but it would only fire in IE. Firefox, Safari, Chrome, and Opera all failed to fire the event unless I first clicked on a text box. But there is a way to do it...

If you use XAMPP to run a local web server, you might have come across the problem whereby Apache will not start. You click the Start button in the XAMPP control panel, the green 'Running' message appears for a second or two, then disappears again, and Apache fails to start. This can be a very frustrating problem, as you get absolutely no feedback about why it won't start. I found 2 possible causes for this...

I finally got round to re-writing the xplike.plesk template to work with Joomla 1.5. The original xplike.plesk template was written by SWSoft (now known as Parallels - the makers of Plesk), and released under the GPL for Mambo 4.5.0. I tweaked it to work on Mambo 4.5.1, and Joomla 1.0, and it proved very popular. As I did not write the template (just modified it), it was difficult for me to provide support for it. It also did not escape my notice that the code in the template was heavyweight and ugly (although the design itself is great).

So, I re-wrote the whole thing from scratch for Joomla 1.5. The result is much improved - a very lightweight, standards-compliant, accessible, search-engine-friendly, tableless template, with collapsible menus (that 'remember' your preferences if you re-visit the site within 30 days), a resizable header area (lots of people wanted a custom-sized header so that their company logo would fit), and a choice of 3 colour schemes.

For more information, and to download, visit: http://www.netshinehosting.com/home-page/free-joomla-1.5-templates.html

Sadly, the official Joomla Extensions Directory (JED) is no longer accepting any extensions that are not released under the same license as Joomla itself (GPL). Even open source extensions released under compatible licenses (eg. LGPL) are no longer allowed. Any existing extensions released under other licenses will be removed from the JED in June 2009. Also, all Joomla 1.0 extensions, whether GPL or not, will be removed from the official directory.

In my opinion, this is a huge mistake, and a terrible shame. The JED has been an incredibly useful and well-managed resource, providing Joomla users with a one-stop-shop for extensions of every type. Now this resource is losing some of its value. I could understand if it were just commercial or just encrypted extensions that were being excluded (although I would still disagree with that), but I cannot understand why extensions released under GPL-compatible licenses such as LGPL and Expat are being ousted, nor why no provision is being made for the hundreds of thousands of Joomla 1.0 sites that still need access to some of the older extensions. Whilst I'm sure the JED will continue to be a valuable and well-used resource, if you want a non-biased, all-inclusive directory, you will soon have to look elsewhere.

Several individuals and companies have set up their own extension directories in response to this. One of the more interesting new directories is the one at www.cmsextensions.org/extensions/. This site, built by a group of Joomla extension developers rather than an individual or single company, aims to provide an unbiased collection of extensions not only for Joomla, but also for other content management systems, such as Elxis, Mambo, and Drupal. It also provides a discussion forum, news, job postings, and social networking features. If you have written an extension for Joomla (or any of the other CMSs supported), whether GPL or not, please add your listing, and help make this a new 'one-stop-shop' for CMS extensions.

nicEdit is a very lightweight wysiwyg HTML editor, distributed under the MIT license (which means that as long as the copyright info remains intact, you can do pretty much anything with it, including distribute it with a commercial application). There are a couple of drawbacks to nicEdit - first, it does not produce standards compliant HTML. If it did, it would not be anywhere near as lightweight, so that's a bit of a tradeoff (it relies on the browser's own HTML editing features, so if you use a decent browser you should get pretty good results). The other main problem I found though, is that if you have a form containing a nicEdit editor, and submit the form using Javascript ie. form.submit(), the content of the editor is not posted back to the server!

If you would like to know why that is, and what you can do about it, read on...

There are gazillions of articles out there telling you how to restrict access to a directory using either FilesMatch or mod_rewrite rules in .htaccess. But trying to find out how to restrict access to a page based on a URL is somewhat more difficult. FilesMatch and RewriteRule only work on the first part of the URL - they ignore the querystring. But mod_rewrite is capable of restricting access to a page based on the querystring value and the IP address of the visitor if you can find the right syntax - and here it is...

I was surprised to find that after the clocks changed on 26th October 2008, all of the dates on my billing records were showing up a day early. Invoices paid on 28th September showed as being paid on 27th. I tried it out on 3 different servers as well as my local PC. On the 3 Linux servers, it always calculated the wrong date, but on my PC (running Windows XP), it showed the correct date. The explanation was fairly simple, but I found it infuriatingly difficult to fix!

Javascript is incapable of rounding numbers to a certain number of decimal places accurately. The problem occurs because Javascript treats decimal numbers as floats, which, as most programmers know, are a pain in the proverbial. As such, if you try to round a number like 0.285 using Javascript (using either Math.round or the toFixed function) you end up with 0.28 instead of 0.29. After a half-hearted search on google, I could not easily find a sample script that I could use in nBill to calculate this accurately (because nBill is commercial, and the only sample I found would not allow me to use it for commercial purposes). So I wrote my own function from scratch...