J4 Issue ?
avatar astridx
astridx
11 Aug 2019

In every manifest we have a version number in the extension tag. Here we have 4.0.
<extension type="component" version="4.0" method="upgrade">
This is also used by third parties. If my information is correct, it was once planned to test whether the extension is installable. If I searched correctly, then the information is not used anywhere. I think we should use or delete this entry. Otherwise, it only causes confusion.
Am I right? Whats your opinion?

avatar astridx astridx - open - 11 Aug 2019
avatar joomla-cms-bot joomla-cms-bot - change - 11 Aug 2019
Labels Added: ?
avatar joomla-cms-bot joomla-cms-bot - labeled - 11 Aug 2019
avatar astridx astridx - change - 11 Aug 2019
The description was changed
avatar astridx astridx - edited - 11 Aug 2019
avatar astridx astridx - change - 11 Aug 2019
The description was changed
avatar astridx astridx - edited - 11 Aug 2019
avatar franz-wohlkoenig franz-wohlkoenig - change - 11 Aug 2019
Labels Added: J4 Issue
avatar franz-wohlkoenig franz-wohlkoenig - labeled - 11 Aug 2019
avatar franz-wohlkoenig franz-wohlkoenig - change - 11 Aug 2019
Status New Discussion
avatar ReLater
ReLater - comment - 11 Aug 2019

Please don't use this attribute for validations. Would be another B\C break that makes installations more complicated if your version is compatible with Joomla 2.5, 3 and 4 or so.

How should version be interpreted then? higher, lower, equal than...? Or shall we create different packages for each Joomla version just because this attribute doesn't match?

Simply use minimumPhp, minimumJoomla in the installation <scriptfile> that also can be simply implemented as tags in the extension manifest XML if you prefer that. Like other custom tags like maximumJoomla that can be implemented easily that way.

XML:

<minimumJoomla>3.9.0</minimumJoomla>
<maximumJoomla>3.9.99999</maximumJoomla>

InstallerScript:

$minimumJoomla = trim((string) $manifest->minimumJoomla);
$this->minimumJoomla = $minimumJoomla ? $minimumJoomla : $this->minimumJoomla;
// Rest will be handled by InstallerScript class because it's a core property.
// https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/Installer/InstallerScript.php#L89


$maximumJoomla = trim((string) $manifest->maximumJoomla);
if ($maximumJoomla && version_compare(JVERSION, $maximumJoomla, '>'))
{
 // Create nag message. Return false.
}
avatar Bakual
Bakual - comment - 11 Aug 2019

Afaik it could be removed easily.
As @ReLater already wrote we have now better ways to specify compatibility, so this isn't needed.

avatar laoneo
laoneo - comment - 12 Aug 2019

I would rather go the opposite way and treat the version as a minimum requirement. If this doesn't match then throw a warning out to the user. Somehow the developer needs to be able to define what for a minimum CMS version is required for this package.

avatar astridx
astridx - comment - 12 Aug 2019

@laoneo Thanks for you feedback. What advantage do you see in checking the version in the manifest file instead of the script file?
And do you really think we need the value in the core extensions?

avatar mbabker
mbabker - comment - 12 Aug 2019

Remove it. The preflight hook of the install script is the best place to do these checks. That attribute can only cover CMS version, many extensions also have additional requirements beyond "am I compatible with this version of Joomla" and trying to write all of those into XML when there is already a reliable solution in PHP is just asking for trouble. Stop over-engineering everything for crying out loud.

avatar laoneo
laoneo - comment - 12 Aug 2019

@astridx for me core extensions should not really be treated differently as the other ones. Not every developer has a script file and it is rather convenient to define a tag in the manifest than writing a PHP script (remembering the time I wrote my first one and struggled with the class name) ? .

avatar mbabker
mbabker - comment - 12 Aug 2019

Script files should be used and encouraged (and here's a novel idea, document the damn things, I know it's such a foreign concept for Joomla development but the documentation is really what makes working on some of the platforms I deal with a breeze; Joomla is the only platform I constantly have to reverse engineer things and I wrote or refactored half the system). XML files cannot be made to sanely deal with the complexity of checking version compatibility; you can only define a minimum supported version. How do you deal with defining a maximum supported version, or blacklisting install of a given version because of a core bug that leaves things inoperable for you? How do you deal with PHP version compatibility, or database engine compatibility, or more exotic requirements such as having specific PHP extensions available? Hint, script files are the only sane way to do it.

But sure, if you want to make it easy, then spend time making an XML attribute that is by designed crippled in functionality work. Wouldn't be the first time a feature in Joomla is implemented in a half-hearted manner.

avatar franz-wohlkoenig franz-wohlkoenig - change - 12 Aug 2019
Status Discussion Closed
Closed_Date 0000-00-00 00:00:00 2019-08-12 15:32:28
Closed_By franz-wohlkoenig
avatar franz-wohlkoenig
franz-wohlkoenig - comment - 12 Aug 2019

Closed as having Pull Request #25820

avatar franz-wohlkoenig franz-wohlkoenig - close - 12 Aug 2019
avatar Bakual
Bakual - comment - 12 Aug 2019

Somehow the developer needs to be able to define what for a minimum CMS version is required for this package.

@laoneo You just need to set $this->minimumJoomla in your installerscript. If that one extends JInstallerScript and you call its preflight method, then it will take care of it automatically. You don't need that attribute in the XML. See what @ReLater wrote, he explained it.

avatar astridx
astridx - comment - 13 Aug 2019

@laoneo You are right. For developers it is easier to make an entry in the manifest than to create a script file. But in my opinion this statement should only be in teh manifest, if it is used. It took time for me to find out what that version number means. And the result, it will not be used, was frustrating.

avatar laoneo
laoneo - comment - 13 Aug 2019

But in my opinion this statement should only be in teh manifest

Totally agree, there should be one point to define the minimum version.

@Bakual the problem I have is the installer file and not the easy way of doing it once I have that file. Just to define the minimum Joomla version my extension runs with, I need to create an installer file, which is for me rather overhead.

avatar mbabker
mbabker - comment - 13 Aug 2019

@laoneo you are approaching this as if you will ONLY define a minimum supported CMS version. And that's just not reality. How many extensions support core's minimum PHP version? How many extensions support all of core's database engines? Are those checks compatible with the XML schema? A minimum version in XML does not let you block installing a non-compatible extension on a non-compatible Joomla version (i.e. how do you define without stupid complex XML that your non-4.0 compatible extension shouldn't be installed there; 4.0 > 3.x so the minimum version check passes). And unless you're going to suggest rewriting everything that you would normally do with a script file into stupid complex XML (removing files being a common one), you're going to need a script file sooner or later. Just use script files and be done with it, if a 10 line file is too much overhead then honestly there are other problems you need to deal with.

avatar Bakual
Bakual - comment - 13 Aug 2019

I think all of my a bit more complex extensions have an installer script anyway. Eg to create a default category, add the UCM content types, remove unneeded files, set default parameters and of course check some minimum requirements.

Of course one could develop an XML element which is automatically checked, but it is offtopic anyway as the current attribute doesn't do that (you'd need to compare that in your installer script manually). So this would be a feature request independant from this request here.

Add a Comment

Login with GitHub to post a comment