Managing extensions in Joomla! 1.6
Friday, 18 June 2010Joomla! 1.6 Alpha 2 has been out for some time, and while it should not be used for production purposes at all, it gives some nice insights what Joomla! 1.6 Stable will look like. Among other things, Joomla! 1.6 will ship with an Update Manager. This blog shows some of the things that are already there under the hood.
Reorganizing the extensions
With the migration from Joomla! 1.0 to Joomla! 1.5 some things already changed regarding third party extensions - mambots were renamed to plugins, a new type of extensions were created (language packs). With Joomla! 1.6 again some things change, but mostly in the architecture of Joomla! itself - not the third party extensions.
While with Joomla! 1.5 each type of extensions had its own database table (jos_components, jos_modules, jos_plugins), with Joomla! 1.6 all these tables will be replaced with one: jos_extensions.

Also, a new type of extension will be added to the list of current types (components, modules, templates, languages, plugins): library. This makes it possible to easily add common functionality for multiple extensions. Things like a jQuery library, Nooku Framework, extra JForm fields or a MageBridge product-cache to my mind. Very promising.
Updating extensions
Part of these changes is also that Joomla! 1.6 will ship with an Update Manager which will allow you to update extensions from within Joomla!. Other systems like Drupal or Magento have had such managers already for a long time, but because of the many other features Joomla! has been working on, this one was falling behind. But it's finally here!

There are no practical examples yet that prove the actual workings of this update procedure, but the concept is clear: Each extension is able to define it's own update URL, and this URL is checked by the Update Manager to see if there are any available updates. Actually updating an existing extension will be the same as installing a new extension.
Under the hood
Some things of how the Updater will work, become apparent when looking at the code: There is a new core-class called JUpdater with a few subclasses, adapters and helpers that aid to the working of the update manager. The database table jos_update_sites contains a listing of all the available update URLs, while the table jos_update_sites_extensions contains a cross-reference of which extension is using which site.
Now, the Update Manager will check for updates by looping through the update URLs in the database. For each URL, it checks whether it sends with the suffix ".xml" and if it does not, it appends "extension.xml" to the URL. It fetches all the available updates by downloading and parsing all the remote XML-files. All this information is then stored in the database table jos_updates.
Downloading updates
So, after checking for updates, all update information is stored in the database. Once the site administrator decides to install these updates, the relevant packages are downloaded to the Joomla! tmp-directory and installed as usual. Because the information stored in jos_updates does not contain the actual download URL, this download URL will be most likely defined in the extensions XML-based manifest-file:
<authorUrl>http://example.com/my-extension</authorUrl>
<downloadUrl>http://example.com/downloads/com_extension.zip</downloadUrl>
Note that this is all still uncertain, until Joomla! 1.6 Stable comes out. Because packages are downloaded by Joomla!, Joomla! requires the PHP-option allow_url_fopen to be enabled. On hosting environments this option is disabled for security reasons, but unfortunately CURL is not yet supported.
