[#48228] - Update not detected despite valid, reachable update XML (package, component, and plugin types all affected)
- New
- Medium
- Build: 5.4-dev
- # 48228
What happened?
1.## Update not detected despite valid, reachable update XML (package, component, and plugin types all affected)
Description
Extension updates are never detected by the core Update Finder (System → Update → Extensions), despite every documented requirement being met and independently verified. This was tested extensively across three different extension types (package, component, plugin), multiple Joomla installs (including a completely fresh/clean install), and multiple manifest configurations, with identical negative results in every case.
This closely mirrors issue #46366 (module update not detected), but affects package, component, and plugin extension types as well, suggesting the root cause may be broader than originally scoped in that report.
Steps to reproduce
- Package/component/plugin manifest declares
<updateservers>pointing to a self-hosted update XML file. - The update XML file is confirmed reachable (HTTP 200, verified in server access logs on every check) and confirmed byte-for-byte correct (verified directly in browser).
- The update site is correctly registered and enabled in
#__update_sites(enabled = 1,last_check_timestampupdates on every check, confirming Joomla successfully re-fetches the file each time). #__update_sites_extensionscorrectly links the update site to the extension'sextension_id.- The installed extension's
manifest_cachein#__extensionsshows a version number lower than the version declared in the update XML. - Go to System → Update → Extensions, click Clear Cache, then Find Updates.
Version
6.1
Expected result
Expected result
The extension should appear in the update list, matching the documented behavior: "If it finds it's a valid update for this website, it inserts a record into the #__updates table."
Actual result
No update is shown. #__updates remains completely empty for the extension's element, with no error message displayed (unlike genuinely unreachable update sites, which do show a clear "Impossible d'ouvrir le site de mise à jour" warning banner). This absence of any error, combined with confirmed-successful HTTP fetches, made this very difficult to diagnose — the failure appears to happen silently after the file is retrieved and parsed.
System Information
Joomla version: 6.1.1 (also reproduced on 6.1.2)
PHP version: 8.1–8.2
Extension types tested: package, component, plugin (system group)
Manual ZIP installation works without issue every time
MIME type of update XML confirmed as application/xml, content confirmed well-formed and byte-accurate via direct browser inspection at time of each failed check
Additional Comments
Server access logs confirm Joomla's HTTP client (Mozilla/5.0 Joomla!/6.1.1 Joomla) successfully retrieves the update XML on every "Find Updates" click (HTTP 200, correct byte count matching the live file content).
last_check_timestamp in #__update_sites updates correctly on every check, confirming the update site is being processed, not skipped.
Given the extent of isolation testing performed (single-variable changes, clean-state reinstalls, fresh Joomla install), a configuration error on the extension developer's side seems unlikely, though of course not impossible to rule out entirely without server-side debug access to Joomla's update finder internals.
Happy to provide the exact update XML files used, full access log excerpts, and database query results for #__extensions, #__update_sites, and #__update_sites_extensions if useful for reproducing this.
| Labels |
Added:
bug
|
||
joomla-cms-bot
- | Labels |
Added:
No Code Attached Yet
|
||
I can provide all the files related to this issue (exact XML files, log excerpts).
@webmaster382 Please do that. Without knowing the XML files on the updateserver, e.g. the targetplatform value, it is almost impossible to investigate this.
@webmaster382 The first update for Joomla 5 will not be found (except if you are on Joomla 5.0):
<targetplatform name="joomla" version="5.0" />
@webmaster382 The first update for Joomla 5 will not be found (except if you are on Joomla 5.0):
<targetplatform name="joomla" version="5.0" />
It should be (assuming your extension supports Joomla 5.0 to 5.4):
<targetplatform name="joomla" version="5.[01234]" />
@webmaster382 I would also need the extensions manifest XML file, which should be located in folder administrator/components/com_integritychecker
And maybe the <php_minimum> should be added to the update site XML? See also example here: https://manual.joomla.org/docs/4.4/building-extensions/install-update/update-server/
And maybe the <php_minimum> should be added to the update site XML? See also example here: https://manual.joomla.org/docs/4.4/building-extensions/install-update/update-server/
Update: I just see that's optional but not necessary.
@webmaster382 The extension type is <type>component</type> in your update site XML, but the download is named pkg_... and not com_.... That's at least weird.
In the last XML file (manifest file) there is no section <updateservers> at all. So that would explain why no update is found.
Update not detected despite valid, reachable update XML
As we can see, this is a false claim. Your XML files are not really valid, they contain mistakes.
This closely mirrors issue #46366 (module update not detected), but affects package, component, and plugin extension types as well, suggesting the root cause may be broader than originally scoped in that report.
In that report it was clearly found out that there was a mistake in the updatesite XML.
If we had a general problem with all kinds of extensions, we would have received a lot of issue reports, but we haven't.
Apologies — I pasted the wrong file by mistake, that was an unrelated manifest from applidata.fr, not the actual com_integritychecker.xml. Sorry for the confusion. I'll paste the correct file shortly.
Thanks for taking the time to look into this so carefully, it's genuinely helpful.
Thanks again for the review — you were right on both counts, and I appreciate you taking the time.
You're right that my report's framing was too strong ("false claim" is fair) — this genuinely was a mistake on my end, not a Joomla core issue. Sorry for the noise.
On the type/download mismatch: I only ever ship a single distributable artifact (the full pkg_ package), so declaring separate component/plugin update entries pointing at that same package zip was inconsistent, as you spotted. I've removed those <updateservers> declarations from the child component and plugin manifests entirely, and I'm now only declaring <updateservers> at the package level, matching what's actually downloadable:
<element>pkg_integritychecker</element>
<type>package</type>
<downloads>
<downloadurl type="full" format="zip">https://applidata.fr/downloads/pkg_integritychecker_install.zip</downloadurl>
</downloads>I'll close this issue — turned out to be a combination of my own manifest inconsistency plus the targetplatform regex issue you flagged earlier. Thanks for the patience working through it.
@webmaster382 So now after your corrections it works?
Not more !
Not more !
? I don't get it.
No, still not working — sorry if that wasn't clear in my last message. Both fixes are applied (targetplatform regex + consistent package-level updateservers), tested after a full clean uninstall/reinstall, and "Find Updates" still shows nothing for pkg_integritychecker. The exact files I'm currently using are in my previous comment above.
Then I hope someone else steps in because I will be a bit busy in the next days.
No worries at all, and thank you for the time you already put into this — the targetplatform regex catch and the package/type mismatch were both genuinely useful, and I've fixed both. I'll leave the issue open in case anyone else has an idea, but no pressure either way. Really appreciate the help so far.
Just an idea
<targetplatform name="joomla" version="6\."/>
<targetplatform name="joomla" version="(6\.(0|1|2))"/>
this read can be usefull https://manual.joomla.org/docs/building-extensions/install-update/update-server/
I can provide all the files related to this issue (exact XML files, log excerpts).