jed searchIn a previous post, I covered the Joomla! Extensions Directory (JED) to some degree, highlighting why the JED makes sense for both developer and user. In this post, I intend to go through some ways in which a Jooma! website owner can take full advantage of the JED’s various elements in order to make appropriate decisions about what extensions to install on the website.

Directly search specific extension

The JED has a pretty useful search engine built in, so if you know the specific extensions you want to install for your Joomla website, this is your first port of call. Not only does it work if you have the exact name of the extension, but it also allows you to narrow down your search parameters by extension type (component or plugin or module), the version(s) of Joomla you need compatibility with, whether it is a free extension or a paid one, and whether it has a demo so that you can see it in action before installing it. The resulting extensions can even be sorted using various criteria (alphabetically, by date of update, rating etc.) albeit only by a single criterion at any time. However, the search engine is not the smartest one around (for example, it will not recognise ‘multifactor’ if you meant ‘multi factor’), so you may need to slightly tweak your keywords now and then.

Browse by category

If you don’t know which Joomla extension(s) you want by name (or by any other distinguishing factor e.g. developer), the extensions are also listed in the JED according to various categories. In practice, this actually just pre-filters the extensions by a specific category (which can then be further narrowed down by using the above search parameters and sorted). Alternatively, you can browse the top rated extensions, those that were reviewed the most times, and extensions that were recently submitted.

Deciphering the extension entry

The JED is a database, and so various metrics can be (and are) stored and processed. You can use some of the information displayed to give you a better understanding of whether this extension is for you or not. Some information that could be of key value to you are the reviews, the date the extension was last updated, and whether it is a free or paid/commercial extension.

Reviews give you an idea of whether a given Joomla extension even works (and whether it is likely to work across a wide range of installations), as well as provide some historical insights. It can also indicate whether the developer is inclined to listen to its users or not. So reviews can be a primary source of information on the extension. An extension that is frequently updated will show up closer to the front/top when people search (and sort) by ‘last update date’. And by comparing free extensions to paid ones, you can tell which ones give you better value.

Here’s an example of how you can use the information presented to your advantage. Digital Peak’s DPCalendar Lite and DPCalendar Joomla extensions have separate listings (as one is free and the other is paid). We do not provide free support for our Lite offering, so you can imagine that we will get some negative reviews on this matter, as indeed we did. However, the reviews for our paid extension are uniformly (and glowingly) positive – which stands to reason, because our support for our paid users is top-notch and we spare no expenses in drilling down to the problem(s) they may be facing.

How was it in the past

As I posted my first extension in the JED (the successor of DPCalendar -> GCalendar) you could just brows the JED and the ratings have been numbers between 1 and 5. The people appreciated the work of volunteers and posted mostly positive reviews to express the work of the developers. Everything was more relaxed than it is nowadays. As developer you felt motivated to publish your stuff for free.

jed unpluggedWhile the Joomla! CMS is quite a comprehensive package, most of its power lies with its high level of customisability. As with all other software platforms, Joomla is designed to allow other programs to run on top of it, exposing a series of API calls for the convenience of such programs. OSes have applications, WordPress has plugins, and Joomla has extensions. So where does one get one’s hands on the various programs that run on top of a given platform (in this case, Joomla)?

There have traditionally been 2 schools of thought on this; the wide-open sandbox (let’s call this the ‘Microsoft’ way), and the walled garden (let’s call this the ‘Apple’ way). Microsoft has always been more than happy to fully document the Windows API, allowing everybody and his brother to write applications that will run on Windows, a trend that continues even into Windows 10. These third-party bodies, called Independent Software Vendors (ISVs), will then sell, rent or freely distribute their applications any way they can. By way of contrast, Apple has always wanted stricter control over who can write applications that run on iOS, restricting all of its devices that run iOS to applications that can be found in its App Store.

As an open-source product, Joomla is generally considered to be free (as in speech) software. As such, there are no such restrictions laid on what kind of extensions you can run, or where you can obtain them from. However, the developers of Joomla did set up what they call the Joomla Extensions Directory, or JED. The JED is a repository of many (if not most of the) Joomla extensions, including some of the most popular ones. It represents a level of assurance that the extensions listed on it have been curated to some degree, and are more likely to be genuine.

Why use the JED? For users, this is a no-brainer. The JED provides comprehensive information on all the extensions listed, from the Joomla versions supported to user reviews (and developer replies). It represents a central location from which a user can download their desired extensions to enhance the functionality of their Joomla installation all at once.

For extension developers, the issue is slightly more nuanced. For instance, only GPL-licensed extensions may be listed in the JED. If you’re using the BSD licence, or the Apache licence, or (gasp!) your own proprietary licence, it’s not welcome there. Additionally, commercial extensions are given more scrutiny (especially in terms of user reviews). On the other hand, there are a variety of tools and checklists that can help you ensure that your extension(s) are JED-friendly – which generally means that they will work on the vast majority of Joomla installations.

In our next few posts, we will take a closer look at the JED. In the meantime, here are a few things you might want to keep in mind when submitting anything to it:

General guidelines for submitting extensions to the JED

GPL and other licencing restrictions

Is your extension free or commercial?

joomla 2.5 end of liveOn 10th December 2014, the Joomla core product team released Joomla 2.5.28, the last planned release in the v2.5 series. As a result, all further Joomla core development efforts will go towards Joomla 3.x and beyond, and v2.5 will be officially declared End Of Life (EOL) as of 1st January 2015. Here is why this should be news of some import to you.

Firstly, EOL does not mean that your Joomla site will simply stop working come New Year’s Day. Oh, no, that would be too easy. Instead, what it will mean is that the Joomla core team will no longer officially care about v2.5 – if a security vulnerability was discovered the next day, it is highly likely that the only patch available (if at all) would be a community-contributed one. It also means that Joomla extension developers (including Digital Peak) will gradually consider dropping support for the Joomla 2.5 series.

You do not have to upgrade your Joomla installation to 3.x if you don’t want to, as long as you remain up-to-date about any security vulnerabilities that might crop up afterwards, and you can use unofficial patches to keep your system secure. However, if you rely on Joomla extensions to any significant degree (and let’s be honest, most of us do), then be aware that more and more, extensions will be written to require v3.x or higher, and the extension developers will themselves also stop supporting issues or queries related to v2.5 at some point. If you have a reasonably good backup of all your databases (or at least your data), now would be a good time to start deploying and testing Joomla 3.x so that you can ensure a worry-free migration.

The strategy of Digital Peak

In the interests of full and public disclosure, here is how Digital Peak will be handling Joomla 2.5’s EOL. We will continue to support v2.5 on DPCalendar 4.2.x and GAnalytics 3.2.x (the last branch that can be installed on v2.5) through March 2015, giving you that time to migrate to Joomla 3.x with all the support resources available to help you out. So what does support mean on that versions? We will provide bug fix releases till March 2015 when the next major major version 5 of DPCalendar is planed. Till then the branch 4.2 should be pretty stable on Joomla 2.5. For sure we will accept also support cases on our case management system. After June 2015 (which is a half year after the end of life) we will REFUSE support on Joomla 2.5 installations. Means cases on our support platform which belong to a Joomla 2.5 web site will be closed immediately.

There is always an exception

If a vulnerability is discovered in the Joomla 2.5 branches of our products then we will create releases with a fix and you will be informed through our newsletter. So be sure that your E-Mail address on your account is valid!!

How to migrate to Joomla 3

For more information on how and why to migrate your site to the latest version of Joomla, visit their Why Migrate page. If you migrate your web site to Joomla 3 then there is no special actions required to update our extensions. They should work as before. If you did some template overrides then you need to adapt them as well. But you have to create a new template anyway. The best thing would be completely remove all template overrides during the upgrade and them move them back piece by piece.

joomla-bcIn this post, I’m continuing along the theme of backward compatibility, and this time, applying it directly to Joomla – specifically, its release policies – and what this means for extension developers like Digital Peak. Bear in mind that Joomla is open-source, which means that in theory, if you really need backward compatibility, you can always hack the source code yourself to implement whichever functions and behaviours that have changed in successive versions.

Joomla is in the rather curious (but hardly unique) position of being both a software package running on top of a platform (in most cases, the LAMP software stack, but it could equally be the WAMP, WIMP or MAMP stacks), as well as being a software platform of its own. Hence, backward compatibility is required both in respect to the platform it runs on, as well as the extensions that it runs.

Joomla’s Software Platform

While Joomla requires a software stack consisting of an OS, a Web server, a database engine and PHP to run, in practice the OS can be just about any version that will successfully install and run the other 3 components of the stack. Judging from previous data, Joomla is not very concerned with backward compatibility between major releases. For example, sometime between v1.5 and v2.5, Joomla dropped support for IIS6, Apache 1.3, PHP4.x and MySQL 4.x – but it also added support for nginx and SQL Server.

It’s hardly surprising – as a FOSS project, the Joomla project does not itself derive any income from licencing the CMS for commercial (or indeed any other) use, and cannot devote resources to supporting the edge cases. Between 2008 (when 1.5 was released) and 2012 (when 2.5 was released), both IIS6 and Apache 1.3 reached end-of-life (EOL) status (which meant neither would be supported by their respective manufacturers beyond the EOL date), while PHP4.x and MySQL 4.x were EOL even before that. Popular CMSes (and fellow FOSS projects) like WordPress and Drupal also dropped support for PHP4.x and MySQL 4.x around the same timeframe, so Joomla was in good company. From this, it can be inferred that Joomla will likely drop support for a particular component of the stack it runs on shortly after the component’s vendor itself drops support for it.

Joomla As Software Platform

What about the people who develop on or for Joomla, then, like Digital Peak? How does Joomla treat us whenever it updates itself? The current Joomla SDLC is a bit more clear-cut about how it treats backward compatibility. Within any individual major release, Joomla is guaranteed to be backward-compatible. That is to say, it will make no changes to its currently-supported APIs or other public surfaces (config and settings files, for instance). Every major release from 3.x onwards will be supported for a minimum of 4 years, presumably with a period of around 2 years between each major release.

Between major releases, however, Joomla makes no such guarantee. New APIs may be introduced, existing APIs may be deprecated, deprecated APIs may disappear completely, settings may be completely jettisoned. Joomla’s core developers see major releases as opportunities to refactor Joomla’s code, introduce new ground-breaking features and generally get rid of any cruft that may have accumulated.

Implications For Developers And Users

As a Joomla developer, Digital Peak has to be open to the possibility that each extension may need a separate version for each major release of Joomla (and perhaps drop support for older, unsupported releases of Joomla). For users, it is a clear signal that in order to stay supported by Joomla’s core developers, a proper upgrade roadmap needs to be in place. Or pay for 3rd-party support.

for-bcIn a previous post of mine, I mentioned that we would look at some of the pros and cons of maintaining backward compatibility. In this post, I take a look at some of the reasons software companies choose, like Microsoft, to make their new products as backward compatible as possible.

Most software companies are for-profit organisations; that is to say, either they make money from licencing their software (rarely is software outright sold), renting their software (the SaaS model) or from selling support services (especially if the software in question is FOSS). In all of these cases, the commercial sector is where the real money is, which the home consumer market can have a massive influence on.

The business market

One of the core reasons why software (and indeed, other) companies decide to allocate resources on backward compatibility is because customers – especially business customers – are generally resistant to change. The less change there is, the better it is – especially if the change has a quantifiable dollar cost attached to it (which would be the case if upgrading one piece of software also required you to upgrade other pieces of software which used to work well with the earlier version but not with the new one). Furthermore, many corporate users of software platforms would also have made their own customisations and installed business-critical add-ins and extensions, so they would be much less willing to buy and install a new version if they could not keep their customisations intact.

In addition, many large organisations have internal IT procurement processes that require regression testing of software upgrades against their standard set of software installed on user machines. A software upgrade that did not break the other software in use has a much greater chance of being approved for purchase (in the case of proprietary software) in a quicker timeframe and deployed in production environments.

Another reason why software vendors – especially enterprise software vendors – maintain backward compatibility is to support customers who rely on custom-made line-of-business applications or modules that relied on the particular set of quirks and behaviours (both explicitly defined and internally) of a specific software version. Many times, the developers of such applications are no longer around to maintain or update their creations, and the source code may have been lost or otherwise unavailable. Breaking backward compatibility is not an option for these customers, who might represent a large chunk of a vendor’s market.

The Catch-22

An interesting scenario occurs once a software platform becomes sufficiently popular and entrenched in a global market, and a healthy ecosystem of independent software vendors (ISVs) develop applications that run on that platform. When that happens, backward compatibility becomes a high priority for both the platform manufacturer as well as its ISVs. For the software platform’s developers, they have to ensure that their next version continues to allow all (or virtually all) of the existing ISV software products to keep running with no changes. The ISVs in turn have to ensure that their next-generation software continues to run on the existing versions of the software platform with next to no changes. In this case, both platform and ISV vendors have a vested interest in maintaining backward compatibility with each other’s current- and previous-generation products.

So what about Joomla, which is itself a software platform? How does it handle backward compatibility? That is a matter for a future post.

We use cookies on our website. Some of them are essential for the operation of the site, while others help us to improve this site and the user experience (tracking cookies). You can decide for yourself whether you want to allow cookies or not. Please note that if you reject them, you may not be able to use all the functionalities of the site.