[4] Allow numeric client IDs in extension update XMLs#41462
Merged
MacJoom merged 3 commits intojoomla:4.4-devfrom Sep 5, 2023
Merged
[4] Allow numeric client IDs in extension update XMLs#41462MacJoom merged 3 commits intojoomla:4.4-devfrom
MacJoom merged 3 commits intojoomla:4.4-devfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request for Issue #41114 #35376 .
Summary of Changes
In older J! versions (1.6 - 3.10) an update server XML feed for an extension could define the client_id (Admin or Site) as a numeric value (0 or 1) OR as a string (admin or site).
The support for numeric values was removed in 4.x. If an update server still uses numeric IDs, this will cause a PHP notice being triggered as described in #41114 or #35376.
A PR re-allowing numeric IDs in J4 was opened (and closed) a while ago, see #35822
This PR essentially rebuilds the mentioned PR, however removed the deprecation notice.
Why removing the deprecation? Because I assume that the issue will update feeds using legacy IDs will remain relevant in the near future. Devs are unaware that their feed causes the notice, as it's invisible to end users in normal backend scenarios: after the update retrieval Joomla (which triggers the notice) the user is redirected to the update overview again - and because of the redirect, the actual notice isn't shown to end users or devs, even with debug error reporting. The issue is only visible in logs files or non-backend usecases like CLI (see #41114) or when the output of the request that includes the update retrieval is parsed (like we do in the backupmonkey.io client in order to get the current update list - here the notice breaks our JSON response, that's why the client currently includes a specific workaround because the issue is VERY widespread).
Testing Instructions
Reproduce issue, see #35376
Actual result BEFORE applying this Pull Request
Notice logged
Expected result AFTER applying this Pull Request
Notice gone