[3.x] [on hold] Fix update failure from 3.9 via 3.10 to 4 on particular environments

[richard67]

Pull Request for Issue #30736 .

Summary of Changes

In Joomla 3 and 4, we use version 3.9.1 of the external library paragonie/sodium_compat.

This library had the mistake of a file having not the right case-sensitive name, which was fixed in August 2017, i.e. long before the version we use now, see change here paragonie/sodium_compat@a998aad#diff-a3e132db53566250cd35112b9e76329f and PR here paragonie/sodium_compat#47, so their version 3.9.1 has the right filename.

But it seems this change has never arrived in our sources, maybe because git clients on Windows were used for the composer update (last one in 2018).

This PR here renames the file so it is identical what can be found in the zip package for the 3.9.1 version of that library which can be found here: https://github.com/paragonie/sodium_compat/releases/tag/v1.9.1.

Testing Instructions

Issue #30736 is hard to reproduce because it seems to happen only on particular environments. I couldn't reproduce it either.

If you can't reproduce it with the first part of the test, skip the second one. You can't test this PR with a real test in this case. But if you are an experienced maintainer or a release lead, a code review could be sufficient, too ;-)

Test 1: Reproduce the issue.

Hint: It would be sufficient to skip step 1 of the following test and start with step 2 by just installing a new 3.10 nightly. But because the issue has to be fixed in both 3.9.x. and 3.10, the test here proceeds the complete sequence like the later test 2 for testing both fixes, so both tests can be compared.

1. Install the latest 3.9 nightly build or current staging.
2. Update to the latest 3.10 nightly build with the Joomla Update component, either using update channel "Custom URL" with Live Update, or if that does not work for you for some reason (intranet), uploading a zip file using Upload & Update.

• Custom URL: https://update.joomla.org/core/nightlies/next_minor_list.xml
• Zip package: https://developer.joomla.org/nightlies/Joomla_3.10.0-alpha3-dev-Development-Update_Package.zip.

3. Now update to the latest 4.0 nightly build.

• Custom URL: https://update.joomla.org/core/nightlies/next_major_list.xml
• Zip package: https://developer.joomla.org/nightlies/Joomla_4.0.0-beta5-dev-Development-Update_Package.zip

Result: See section "Actual result BEFORE applying this Pull Request" below.

Test 2: Verify that this PR fixes the problem when is has been merged into staging and later into 3.10-dev.

1. Install current staging with the patch of this PR included, using the installation package built by drone for this PR:
   https://ci.joomla.org/artifacts/joomla/joomla-cms/staging/30746/downloads/35650/Joomla_3.9.22-dev+pr.30746-Development-Full_Package.zip
2. Update to the latest 3.10 nightly build with the patch of this PR included.

• Custom URL: https://test5.richard-fath.de/next_minor_list_pr-30746.xml
• Zip package: https://test5.richard-fath.de/Joomla_3.10.0-alpha3-dev-Development-Update_Package_2020-09-23_pr-30746.zip.

3. Now update to the latest 4.0 nightly build.

• Custom URL: https://update.joomla.org/core/nightlies/next_major_list.xml
• Zip package: https://developer.joomla.org/nightlies/Joomla_4.0.0-beta5-dev-Development-Update_Package.zip

Result: See section "Expected result AFTER applying this Pull Request" below.

Actual result BEFORE applying this Pull Request

In most cases, the update to 4.0 will succeed. But on some kind of environment you might get what is described in issue #30736 .

Expected result AFTER applying this Pull Request

No issue #30736 anymore on such environments where it could be reproduced.

Documentation Changes Required

None.

[alikon]

I have tested this item ✅ successfully on 2ab4c02

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/30746.}

[SharkyKZ]

This is still problematic for existing sites. See #23725.

[richard67]

This is still problematic for existing sites. See #23725.

Does this mean there is something wrong with this PR?

[SharkyKZ]

I don't think we can just rename the file. Although under normal circumstances this fixes the missing class on case sensitive systems, we probably want to have only the file with correct casing. This would avoid issues when moving between OS.

[richard67]

I don't think we can just rename the file. Although under normal circumstances this fixes the missing class on case sensitive systems, we probably want to have only the file with correct casing. This would avoid issues when moving between OS.

So you want to hold back this fix, which fixes the issue on all unixoid OS, on which by far most of the webservers are running, as soon as the core is updated to a new version which includes this PR, and which does no additional harm for Windows (on which only a small part of webservers are running)?

Or tell me which harm can this PR do to an installation on Windows which would justify to reject it?

[HLeithner]

this will not work sorry, we (or I) have to fix the upgrade/install function first...

Because we should remove the wrong named file first and add the new then but that's not possible at the moment.

[richard67]

this will not work sorry, we (or I) have to fix the upgrade/install function first...

Because we should remove the wrong named file first and add the new then but that's not possible at the moment.

@HLeithner So what to do with this PR? Close it so it will be forgotten and once you have fixed the update (maybe with 5.0?) nobody will remember all those external library files where we have this problem? How many of these things do we meanwhile have buried in our issue and PR history?

Feel free to close it.

I have done what I could do.

[richard67]

Or set it on draft status, whatever it needs so it’s not forgotten.

[HLeithner]

I can't set it to draft but would be a good idea

[richard67]

Will be replaced by PR #30802 .