Pull Request for Issue #9547.

Merge JoomlaUpdate into Installer (beta)

Simplify Joomla Installation

Objectives

• Eliminate the separation between com_joomlaupdate and com_installer, and deprecate the com_joomlaupdate component.
• Work toward a simplification of the entire package installation and update classes and procedures.
• Restrict changes to com_installer at this time to validate direction.

Assertions

• Joomla! will benefit from the centralization & simplification of package management.
• No insurmountable challenges prevent centralized installation logic for all packages.
• Isolating the installer from runtime will allow for the future use of 3rd party package managers.

Approach

• The standalone features in com_joomlaupdate has been merged into com_installer so that all installations and upgrades are processed using the forked installer and monitor. The same Akeeba restore code is still used, with a second Joomla! forked installer for non-core packages.

Testing Instructions

• Create a Joomla! package containing a joomla.xml file and install using the extension installer.
• Configure your Joomla! installation to pull core updates from a custom server, recreate the required xml files, and stage a customized Joomla! package containing the joomla.xml file, then perform an extension update.

Summary of Changes

• Joomla! core updates were made visible in the Extension Update list.
• All install and update controller events that performed installation were supplanted with logic to direct the procedure to a new installer controller.
• A new installer controller and model were added that receive requests for single or batch installation.
• The com_joomlaupdate monitor and standalone installer logic was ported into the new installer operation.
• The Akeeba restore engine was ported and upgraded to support package folders.
• A Joomla! standalone installer was created.

Issues & Considerations

• During installation we are unpacking using a new InstallerModelInstall -> initialize operation that separates the previous unpacking and installation operations. The net result of this method is the set the package state value for the model and return true on success. This should be further compressed into the core JInstaller class.
• The forked Joomla! installer that is launched for extension processing currently requires the Joomla! kernal / library.
• The com_joomlaupdate features that deal with instructions and notification have not been ported. This could best be refactored into a standard for all packages to share, allowing updates and upgrade notices for all packages.
• A standard for the installer provider needs to be defined along with considerations toward deprecating all JUpdate class operations into the JInstaller class.
• Management of the forked installer should be controlled by the JInstaller class to eliminate dependency on the com_installer controller.
• The JInstaller class dependencies need to be isolated & minized so that it can be included for standalone operations.