Introduction
At the present moment components have the ability to run custom installation scripts by utilising the "com_install" and custom uninstall using "com_uninstall". The problem with this is that if one is to implement a multi-installer, these functions can become redefined for multiple component installs which then causes an error.
Proposal
Instead of relying on the com_install and com_uninstall functions, a special class (named like the extension) handles the special installation routines. In addition to running two functions, com_install and com_uninstall, we can easily expand this to handle more than just two functions and encapsulate support functions so that the global function namespace isn't littered with these component specific functions.
For example say we have a component called "Hello", which creates a special class called "HelloInstaller" which is included in a special file (much like install.php or uninstall.php, perhaps this could be called "installer.php"). Within the installer we add support for various calls:
Check (or pre-install)
This is a basic sanity check run before installing the component so that the component can flag anything it thinks is an issue. We run existing pre-install checks with in the installer but we don't give the component a chance to check for anything. This would allow a component to check and cancel a possible installation.
This function should return true on success or false if the installation should be halted. It should also pass back a message if it halts the installation with the error in it.
Install
This would function the same as it does in the existing environment. This would also allow for the installation to be rolled back if part of it failed as well in addition to displaying a message.
This function should return true on success or false if the installation should be halted. It should also pass back a message if it halts the installation with the error in it.
Upgrade
The upgrade function allows the developer to build their own upgrade functionality into the installation system. This would allow the developer to build their own database update and conversion scripts into the installation upgrade method. This method would be triggered as part of the upgrade after all of the files have been replaced with their new versions. This also allows a single package to be used as an installer or an upgrade. In the case of an upgrade the Joomla! installer needs to merely check the file list of the existing on disk component and then do a comparison with the new file. Any file that isn't in the new file can be deleted
This function should return true on success or false if the installation should be halted. It should also pass back a message if it halts the installation with the error in it.
Uninstall
This would behave like the existing "com_uninstall". It does not matter what it returns.
Sample
This is a sample of a potential class. If doesn't do anything but demonstrates how such a class could be layed out. As it is a class it means that support functions can be deployed that allow a neater design.
Code: Select all
class HelloInstaller {
function install() {
// do stuff
if($success) return true;
else return false;
}
function uninstall() {
// do stuff
// uninstall doesn't return a value
}
function upgrade() {
// do stuff
if($success) return true;
else return false;
}
function check() {
// do stuff
if($success) return true;
else return false;
}
}
Implementation
This would require a slight change to the way the installer behaves and having some extra checking code to see if the appropriately named class has been defined (e.g. class_exists). This then paves the way for multi-installers to work properly without clashing.
A new entry would need to be added to the installer XML file to designate where this installation class would exist.
Impacts
Users
The users notice no difference. Component support for upgrading is provided however which can make their life easier. This also allows for multi-installers to be created that won't cause errors.
Third Party Extensions
Third party extensions do not need to be updated, the old style method can still be supported. However migrating to using the new method is quite easy for third party developers, it is just a matter of adding a class and renaming a few functions.
Performance
This has minimal impact on performance as it is only done during component installation, upgrading and removal. The main issue would be a slight increase in memory usage and parsing time if the disparate functions (install/uninstall) are combined into the same file.
See also
Installation system check improvements White Paper (
http://forum.joomla.org/viewtopic.php?f=500&t=266084)