Joomla extensions manifest reforms

Written by Jeremy Wilken 24 Mar2010

Every installable extension for Joomla comes with a manifest file (usually the name as the extension, and is an xml file). It contains basic information about the extension, such as who wrote it, the version, what kind of program it is, where to install, and what to install. There tag requirements are relaxed, but I want to propose that we start to reform our ways and make them a bit more standard, or simplified. There are also some security concerns related to the file, as unless the user has implemented the .htaccess blocks, it is a publicly viewable file and can reveal some basic details about the extension for a potential hacker.

I'll go through several of the tags in the manifest file that I find have some issues to be addressed, and then will suggest an alternative standard.

Version tag issues

I shall begin with the discussion of the version number tag. This seemingly harmless tag can be helpful to spiders or hackers who wish to find a specific out-of-date extension with known vulnerabilities. Some extensions simply leave the tag out of the manifest and insert it elsewhere into the program. Problem? It doesn't show up in the Joomla extension manager anymore, so nothing huge but we lose that functionality.

Also many times I have seen version numbers or strings that don't conform to the basic PHP version methodology. They might be 1.4 stable or 1.2.demo.23, but the basic idea here is to follow the same format as Joomla. Don't make up new formats, but use the ones already set.

The last issue is that this number doesn't always seem to be updated, or extension designers ignore minor updates and only include major versions. So rather than change 1.0 to 1.0.1 for a bug fix, they just leave it as 1.0. This leaves ambiguity as to what version is being used, and is bad practice.

Creation date woes

Seems like this tag only works in theory, as it lists the creation of the program (and devs use it as the date the program was first created, or a major milestone version) as a date. However this date is open for interpretation, can be a year only, can be a full date format. Let's standardize with DD-MM-YYYY, because the time is rather irrelevant here.

Param problems

The manifest file should contain program information, installation details, uninstallation details,and author information. However it also includes a list of parameters the extension will use. I don't see the need for the parameters to be included in this particular file, and in fact it makes more sense for it to be separated from installation details. Parameters are related to the operation of the extension, not to the installation.

Language listings

It seems to me that the language process could be streamlined. The requirement now is to list each language file separately like such "<language tag="en-GB">en-GB.com_content.ini</language>". It would be nice to just list the folder that all language files reside in, and let some logic fill in the blanks. Essentially, the tag attribute is the first part of the language file name, so it could be simplified to just list a whole directory of language files, scan the file name, and load them into appropriate locations. The naming scheme for language files is pretty ridgid, so you can count on it.

Missing manifest items

This information is for 1.5 mostly, as 1.6 will address many of these items (from what I can see in the code, but its not fully functional to know for sure as of writing). The installation file is incomplete in many ways, which I'm glad to see a focus being added in 1.6, but programs for 1.5 will be around for a while and it might be worthwhile to add these in anyways.

• downloadUrl - It seems silly not to include a link to the download for the extension. The authorUrl tag is almost always used for the homepage of the developer and not the program itself.
• imageUrl - Just about every extension has a logo or some kind of image to represent it. Lets include that.
• helpUrl or supportUrl - Components can include help buttons in the toolbar, but other extensions have to put their support or help information in the program description. Lets make it easier for users to find that information.
• releaseType and releaseDate - The version number is only so helpful, its important to also know the type of release (bugfix, minor update, major update) and when it was released. The creationDate is actually pretty meaningless, but a releaseDate would be very useful.
• changelog or changelogUrl - Its also good to know whats changed from version to version, and if its included directly in the manifest or linked to on the web, users have a starting point to figure out whats new.

There are others that could be included, but I count these among the most practical to include. The neat thing is you can include them without any problems. Joomla just ignores tags it doesn't recognize.

An alternative for security

The other day a discussion on Twitter arose briefly about the version number in the manifest files. Some (rightly) claim it can compromise a site if a user leaves an outdated extension, and doesn't block it from public view. So some developers will take it out of the manifest file, and declare it elsewhere in the extension (administration of the extension). However this is not widespread yet and I'm not convinced this is the best method, but it does accomplish the goal of securing the sensitive version information. My biggest concern is that then the information is inaccessible by Joomla.

Joomla doesn't keep its version number in an xml file. It is stored in the /libraries/joomla/version.php file. It contains a simple class, JVersion, which has several properties and a few methods of getting the data. Something similar to this could be incorporated into extensions. It would have to be added to the Joomla framework to work, and in my view it should be able to completely replace the xml manifest file.

If such a system were added, it could be optional. Allow the xml manifest files for older extensions, but encourage new and updated extensions to use the PHP method for security. It would probably be best to depreciate the usage of the manifest file, and in a later version (like 1.7 or wherever we go next) mandate it.

Until there is a core alternative...

So until some alternative is part of the Joomla core, we are left with the option to remove the tag and include it in our program code to hide it from public view. For this I would like to suggest a standard methodology. I saw a similar implementation in Tienda, and have come to believe its a solid alternative for the time being.

In each extension, create a separate file called 'defines.php'. Here is a basic skeleton for the file, based on the defines.php file from Tienda.

// no direct access
defined('_JEXEC') or die('Restricted access');
 
class Joomla extends JObject
{
static $_version = '1.5.15';
 
  /**
   * Get the version
   */
  public static function getVersion()
  {
    $version = self::$_version;
    return $version;
  }
 
}

Obviously, its pretty basic and all of the properties could be included into the structure. However, at the moment the only issue is that version number, so lets keep it simple. Switch out the word Joomla with your extension name, and you have an object that describes your program.

They key here is to follow these conventions. Or else whats the point of standardizing?

1. Extend JObject
2. Class is named the same as the title of your program (should also be what's between your <name> tag)
3. Properties are to be static, begin with an underscore (_) and follow the same capitalization rules as the xml tags
4. Getter functions should start with 'get' then the name of the variable (first letter capitalized only)

Perhaps there are more things that need to be considered here, or another method I haven't thought of. If you have thoughts, please leave them below and maybe we can get a solid consensus together on how to handle this best.