With the release of 1.5.10 we introduced an interesting side effect with an installer fix. This  side effect caused a whole heap of incorrectly written XML install files for components to fail to install. The reason for this is simple: a check added in the component installer that silently ignored errors in the XML file specification until the installer fix by passed that check in certain specific situation causing those broken XML file’s to break but for intended functionality to actually behave properly.

Joomla! has a custom install file that basically permits the component extension developer to specify code that should be run when the extension installs. There is also a similar item for when the extension is uninstalled as well which behaves in an identical manner to the install file, except it is only run when the extension is being uninstalled. During installation the installer copies the file denoted by the installfile and uninstallfile from the root of the package to the administrator folder. This feature has been around for a while and interestingly when I flicked through a copy of Mambo 4.5.1, I found the following comment:

// check if parse files has already copied the install.component.php file (error in 3rd party xml's!)

After all of these years the comment has evolved into its present incarnation:

// Make sure it hasn't already been copied (this would be an error in the xml install file)

As you can see the comment hasn’t changed much in its intent. This comment was placed above the code that is used to copy the install file across, which checks to see if the file exists which brings us to JoomlaCode’s bug number 15217.

Bug 15217 is that “custom isn’t upgraded on component installation”. Basically the same check that the above mentioned comment warns about prevents a new 1.5 feature, ‘method=”upgrade”‘, from upgrading the installfile. For good or ill the bug was submitted on the 24th of February 2009 and by the 2nd of March 2009 it was in the Joomla! 1.5 release branch. This means that by the 3rd of March it would have made it to the Joomla!’s Nightly Build. At this point, third party developers could have themselves installed and tested the build to see if it caused an issue but unfortunately we ended up finding out after we released that people hadn’t used installfile as documented (either by us or by my favourite Joomla! 1.5 development book by James Kennard) and had used their own work around for bug 15217 instead of filing a bug report and getting it fixed. I was told in a bug report related to the new issue 1.5.10 introduced that I shouldn’t blame a third party developer for not reporting the bug and developing their own workaround. I wonder if our third party developers aren’t writing bug reports, who we should hope to get bug reports from for code related issues? It would have been nice to have had the issue reported early on instead of so late in the piece but I thank the reported of the issue for bringing it to the fore.

Interestingly I think this bug has been exarcerbated by an interesting combination of situation. The installfile tag is very old where as the upgrade functionality is new for Joomla! 1.5 and permits overwriting extensions that have been installed. So when the original check was written over three major versions previous it couldn’t have been imagined that there would be an upgrade attribute added. We combine this with another feature also added to 1.5: SQL install statements live in their own file and specifying them in the manifest file only sets them to be used, doesn’t copy them like the installfile/uninstallfile tags do. Interestingly this was added using the administrator folder and the “files” tag that normally copies files across with either one per file and a full pathname with folders set or the “folder” tag (and attribute for the files tag) that had been added somewhere along the line (folder tag was I think added in 1.5 and the the folder attribute for files was added in Joomla! 1.0 or earlier; these also seems to be a contributing factor for this issue as well causing confusion in functionality). This appears to have perhaps caused some confusion about how the feature works with the install file using one older method and the newer SQL file using newer features. Add to this the new language feature that has the “folder” attribute as well and can handle folders accordingly permitting developers to put language files within a subfolder relevant to the client. This tag does copy the files to the relevant location and also copies the files from the root of the extension like the installfile/unintallfile tags however in permitting the ‘folder’ attribute this tag avoids some of the issues by permitting the files to be located in different folders. Further more these files aren’t contained within the application’s directory but are in fact shipped off to a different part of the filesystem. This means that confusion about what the tag does and how the files get there are quite clear as there is only one way, unlike the installfile which could errorneously be copied by the files tag in the administrator or correctly by the tag’s processing itself.

At the end of the day it was a silent check that should have raised more noise for developers so they could be alerted of it when they failed to follow documentation. It would have also been nice that any of the developers who had found the bug where the installfile didn’t update had actually reported it instead of just doing a workaround and then getting upset when the bug is fixed and their work around breaks. It would have also been nice to have them also regularly testing the release tree to see what is coming up instead of waiting until a release came along to surprise them (they could even join bug squad and help out there as well). Many eyes make issues shallow unless they don’t get reported or don’t get tested. Soon there will be a Joomla! 1.5.11 that will put in checks against incorrect install file definitions and in 1.6 we’ll be deprecating those two tags in favour of a newer “scriptfile” tag that will behave like the SQL one does and not try to copy files (it also uses classes with functions instead of fixed “com_install” and “com_uninstall” functions that clash when more than one are defined).