Extension With Problematic Updates

Some package extensions use the Joomla! extensions update system incorrectly. This affects how you use them with Panopticon and causes problems with these extensions in Joomla! itself.

THIS IS NOT A BUG IN PANOPTICON. It means that the developer of the extension in question is using extension updates wrongky. Please contact the developer and tell them to read this page, so they can fix their extension's updates.

High-profile known extensions doing that: Regular Labs extensions (sorry, Peter!).

What's the problem

The package extension has an update site which claims that the updates available are for a different extension: one of the sub–extensions (component, plugin, module, …) included in the package type extension. This is wrong, and against what Joomla! expects.

Joomla! expects that the extension the update site offers update information for matches the installed extension on your site that Joomla! is looking updates for. When the update site claims to offer information only for a different extension things start to break.

Updates will appear under a different extension. Instead of seeing the updates for the package, you will see the updates for a different sub–extension belonging to the package, e.g. a component, module, plugin,… included in that package. Since Panopticon retrieves update information from Joomla! itself, if you choose to automatically update such a package extension you will never see any updates being installed. Instead, you will have to choose to automatically update the sub-extension. For example, you should not choose to automatically update the “What? Nothing!” package from Regular Labs, you will have to choose to automatically update the “What? Nothing!” plugin. To make things more confusing, choosing to update the plugin actually updates the package because that's what Regular Labs, the developer of “What? Nothing!” offers as the update ZIP file of the plugin. Yes, it's as crazy as it sounds.

The Pre-Update Check will be unreliable. Before you update Joomla! to a new minor (e.g. 4.0 to 4.1) or major (e.g. 4.3 to 5.0) version, the Joomla! Update extension that's shipped with Joomla! tries to determine whether your installed extensions are compatible with the new Joomla! version you're about to update to. It does that by checking the update information in extensions' updates sites. Joomla will only check top-level extensions i.e. packages, and extensions which do not appear to belong to a package (the value of package_id in their #__extensions table entry is 0 or NULL). Since there are no updates listed in the update site for the package extension, Joomla! will report it as “No Update Information” and mark it as incompatible with the next Joomla! version. This may erroneously prevent you from updating your site which will cause you a myriad of problems in the mid- to long-term.

Very important clarification: having problems with the pre-update check does NOT necessarily mean that the extension suffers from the problem described here. Joomla can erroneously report an extension as incompatible, or having no update information, because of bugs in Joomla! Update the maintainers refuse to fix since August 2020, when we first reported them. For example, if an extension has a version 1.0.0 compatible with Joomla 3 and 4 that you have installed on your Joomla 3 site, and a version 2.0.0 compatible with only Joomla 4, both shown in the update site's XMl content, then Joomla's pre-update checks idiotically reports that the extension is incompatible with Joomla 4 when you try to update from Joomla 3 to 4. The reason? Because your installed version 1.0.0 is not the latest version, and the latest version (2.0.0) which is compatible with Joomla 4 cannot be installed on your Joomla 3 site before updating it. As noted, we reported this issue in August 2020. At the time of this writing (August 2023) the issue still exists, and there is no indication it will ever be fixed. The Pre-Update Check is not to be trusted; that's why it's not supported in Panopticon.

What should you do?

If you want to install automatic updates for such an extension you MUST NOT choose that option for the package extension. Instead, there's a same or similarly named component, plugin, module, template, file, or library extension which you should choose to update. Sorry, there's no (reasonable) way for us to automate this, or even tell you which extension you should choose. You should ask the developer of the extension, because this mess is theirs to clean up. Not yours, not ours.

Definitely complain to the developer of the affected extension, letting them know that they are doing it wrong. Ask them to read this page, especially the Information For Developers below.

Kindly note that Akeeba extensions DO NOT abuse the Joomla! extensions update system like that. We have co-authored parts of it. We know how it works, and how it's supposed to be used. Please do not contact us about this issue.

Information For Developers

If you're told to read this page, start from the top to understand that what you are doing with your extension updates is wrong, and why you are doing a disservice to your users by doing it wrong.

You just need to make a change to your update site. That's all.

Let's say, for example, that you have a package called pkg_example which includes the extensions plg_system_example and lib_example. Let's also assume that your package is claiming that updates are available for plg_system_example instead of pkg_example, like so:

<?xml version="1.0" encoding="UTF-8"?>
<updates>
    <update>
        <name>Example 1.2.0</name>
        <type>plugin</type>
        <folder>system</folder>
        <element>example</element>
        <version>1.2.0</version>
        <client>administrator</client>
        <infourl title="https://www.example.com/"/>
        <downloads>
            <downloadurl type="upgrade" format="zip">https://www.example.com/pkg_example.zip</downloadurl>
        </downloads>
        <php_minimum>7.2</php_minimum>
        <infourl>https://www.example.com</infourl>
        <targetplatform name="joomla" version="(3\.(10|9)|4\.(0|1|2|3|4))|5\.0"/>
    </update>
</updates>

You are claiming to provide a plugin update to a package extension which is wrong. You are then telling Joomla! to download a package ZIP file for what is ostensibly a plugin update which is also wrong. Why?!

Change that so it targets the package extension; that's the extension you're actually providing updates to.

<?xml version="1.0" encoding="UTF-8"?>
<updates>
    <update>
        <name>Example 1.2.0</name>
        <type>package</type>
        <element>plg_example</element>
        <version>1.2.0</version>
        <client>site</client>
        <infourl title="https://www.example.com/"/>
        <downloads>
            <downloadurl type="upgrade" format="zip">https://www.example.com/pkg_example.zip</downloadurl>
        </downloads>
        <php_minimum>7.2</php_minimum>
        <infourl>https://www.example.com</infourl>
        <targetplatform name="joomla" version="(3\.(10|9)|4\.(0|1|2|3|4))|5\.0"/>
    </update>
</updates>

“But, wait!”, I hear some of you say. “My extension was a plugin, and Joomla! does not let me remove that update site from the plugin extension record. That's why I did what I did!”. Fair point, but you can delete the #__update_sites and #__update_sites_extensions records for the old update site, if they exist, in your update script's upgrade() method.

“But how would the users of my previous, plugin-only version update if I do not offer plugin updates anymore?” someone else asks. It's a simple migration — and your users won't even notice. The existing update site will continue to exist as-is (serving a package update file to a plugin type extension) but it will be frozen in time; no more fiddling around with it. In new versions of your software, however, you are going to use a new update site URL which serves the package update file to the package type extension. Your old users will update to the package version from the first, frozen in time, URL, then they will see the update to the latest version. Yes, it works; that's how we went from a component package for Akeeba Backup to a package package.