?
avatar nikosdion
nikosdion
21 Oct 2020

Currently the pre-upgrade check in com_joomlaupdate depends on the update stream information of installed extensions.

There is a problem with package type extensions if they are installed with Discover instead of the regular Upload & Install method.

In this case each component, plugin, module etc does not get a value in the package_id column. Well, no entry for the package is created anyway which means it doesn't get an update stream either.

There are servers out there where the regular installation will fail for packages, especially when using the FTP layer, due to timeouts. For these servers using Discover is an one-way ticket.

As a developer I had worked around the "no entry for the package is created" by creating an entry in #__extensions, an entry in #__update_sites and associating the two.

Am I also supposed to go hunting for installed sub-extensions of the package and update their package_id column?

Or is it possible for com_joomlaupdate to read the package manifest and deduce which extensions belong to the package anyway and not list them at all in the pre-upgrade check?

avatar nikosdion nikosdion - open - 21 Oct 2020
avatar joomla-cms-bot joomla-cms-bot - change - 21 Oct 2020
Labels Added: ?
avatar joomla-cms-bot joomla-cms-bot - labeled - 21 Oct 2020
avatar brianteeman
brianteeman - comment - 21 Oct 2020

I know this wont help with existing installs but moving forward isn't there a way we can do something in core to include the package id with discovered installs.

The same thing happens with languages

avatar nikosdion
nikosdion - comment - 21 Oct 2020

That was my original idea but, unfortunately, you can't :( You'd need to a. be able to use Discover for packages, b. guarantee that packages are installed before other extensions and c. figure out how to handle orphan extensions based on packages installed during this Discover session or previously installed.

a. You can't discover packages. They are just a manifest which tells Joomla to install other extension archives. Trying to install them would fail. You'd need a special case to just copy manifests and create missing extension records which is gnarly.

b. This runs counter to how Discover works. Yeah, it can kinda sorta be shoehorned into the existing installer architecture but I'm afraid this would cause more trouble that it'd solve.

c. This requires some serious refactoring of the installer. Considering that all previous white papers I've written were met with something along the lines of "great, but there are not enough people who understand the installer to do maintain it" and combined with the fact that most people who did understand the installer have already left the project I don't see this happening anytime soon. It'd require an influx in quality contributors, interested in how Joomla works at the lowest level and who understand its architecture thoroughly.

Not to put too fine a point on it, I think that changing com_joomlaupdate, already transformed into a Frankenstein's monster compared to its original scope, would probably be much easier. If something breaks there the user can override the false information displayed and proceed with the update while someone monkey-patches it. If something breaks in the extensions installer Joomla is dead in the water.

avatar nikosdion nikosdion - change - 22 Oct 2020
Status New Closed
Closed_Date 0000-00-00 00:00:00 2020-10-22 13:57:39
Closed_By nikosdion
avatar nikosdion nikosdion - close - 22 Oct 2020

Add a Comment

Login with GitHub to post a comment