How QCUL Handles Extension Update Metadata and Downloads

For extension updates QCUL starts from Joomla’s updater records/manifests, preserves update-site extra-query handling, downloads the selected package into protected run storage, and treats the captured bytes as the tested artifact.

Metadata path

• Reads the available Joomla extension/package update and stable extension identity.
• Uses normal update manifest/package metadata, including update-site query requirements where Joomla exposes them.
• Downloads the package to the run-owned protected package vault.
• Records filename and byte size and calculates SHA-256.
• Uses vendor checksum metadata when supplied to catch mismatched/corrupt bytes.

Identity is not just update_id

Joomla update cache IDs can be reused/changed across refreshes. QCUL associates tested extension results by stable extension identity (element, type, folder, client_id) plus exact target version so a retained test remains meaningful after updater cache changes.

Failure handling

If usable package metadata cannot be resolved or package verification fails, the item is not a production candidate. Refresh metadata or fix the vendor/update source rather than injecting a different ZIP behind the recorded test.

Keep the evidence chain intact

The value of How QCUL Handles Extension Update Metadata and Downloads depends on preserving one traceable transition: known starting version, one selected update, exact captured package/hash, resulting laboratory version, automated evidence, and human review. Avoid manual package installs or unrelated lab changes that make that chain ambiguous before a production decision.

Community Discussion

Want to compare update-testing workflows, share practical tips, or discuss how you use this QCUL feature? Visit the QC Update Laboratory Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.