The Joomla Museum is an archive-style repository that preserves historical and current Joomla extensions. It can be a useful resource for site owners, developers and researchers who need discontinued extensions, older releases or reference code. This guide explains how to find and download Joomla 3 and 4 extensions in the Museum, how to test them safely on a staging site, how to prepare a submission if you want to contribute, and what checks you should run to reduce the risk of breaking a live site.

Important: Some site-specific details (counts, accepted versions, validation rules) should be verified directly on the Museum website before you rely on them in production. See the technical verification notes at the end of this article.


Quick overview: What is the Joomla Museum?

The Joomla Museum functions as an archive for Joomla extensions — components, modules, plugins, templates and language packs. It aims to preserve releases for historical reference and to help site owners recover or maintain legacy sites when vendor downloads are no longer available.

Museum scope: supported Joomla versions and extension types

Typical archive entries include extension packages (zip files), manifest files (manifest.xml or extension.json), author metadata, version history and a license declaration. Archives often cover multiple Joomla generations (legacy 2.5/3.x and 4.x and beyond), but exact version coverage varies by archive. Verify the Museum's supported versions on its official pages.

Is the Museum official?

Archives may be community-run or independent projects rather than official Joomla.org resources. That distinction matters for trust and support: an official directory will have formal review and policies, while community archives may have different validation processes. Before depending on files from the Museum, check the About/Contact pages for ownership, maintenance contacts and site policies, and cross-check with joomla.org when appropriate.

Practical example: Confirm Museum ownership by locating an About or Contact page on the Museum site and verifying the listed email or organization. If uncertain, cross-reference announcements or the official Joomla channels.

Warning: Do not assume Museum entries receive the same level of automated or editorial review as the Joomla Extensions Directory (JED). Always inspect and test each extension.

Why an extension archive matters for Joomla site owners

Extension archives fill a practical need: they can return files that are no longer available from original vendors, preserve historical versions for auditing, and provide developers with old code necessary for migrations or security fixes. However, archived code may be outdated and potentially insecure.

Use cases: restoration, migration, and research

  • Restoring a legacy site that depends on an extension no longer sold or hosted by its original vendor.
  • Testing migration paths by comparing behavior across versions during Joomla upgrades.
  • Reviewing historical code for security audits, academic or archival research.

Limitations and legal considerations

Archives may not always present complete licensing information or author contact details. Verify license files and manifest license tags before reuse. If the Museum enforces a GPL-only policy, contributors must be able to grant or confirm GPL licensing for their uploads. If licensing is unclear, do not redistribute or alter an extension until you have confirmation.

Scenario: A client’s site requires an old menu module. Use the Museum to locate a plausible candidate, then follow the safety checklist in this guide to validate and test the module before using it in production.

Warning: Archived files may contain unpatched vulnerabilities. Treat them as untrusted until scanned and tested.

How to browse and search the Museum (finding Joomla 3 & 4 extensions)

Efficient searching will save time and reduce risk. Use available filters first, then verify candidate entries by inspecting their metadata and downloads.

Search filters to use (version, type, author, keywords)

  • Filter by Joomla version (e.g., 3.x or 4.x) where available.
  • Filter by extension type: component, module, plugin, template, language.
  • Use keywords such as feature names, original vendor, or module identifiers.
  • If the Museum site lacks advanced filters, use a site: search with an external search engine (for example, search engine site queries) or use the browser’s Find tool to scan pages.

How to read an extension entry page

On an extension entry page, look for:

  • Manifest information (manifest.xml or extension.json) showing supported Joomla versions and a version number.
  • Download links and file names — prefer archives that clearly show versioned filenames.
  • Author contact and homepage metadata.
  • Changelog or release notes.
  • License declaration (license.txt or license tag in manifest).

Red flags: missing manifest, no author listed, no changelog, or a package that contains unexpected binaries or installers.

Practical walkthrough: To fetch a Joomla 3 module, filter by type=module and version=Joomla 3, download the package, then open the archive and inspect the manifest.xml to confirm target versions and any install scripts.

Warning: Manifest data can be modified; always inspect the actual package contents before trusting compatibility claims.

Download and installation — safe workflow (checklist)

Follow a structured workflow to reduce the chance of breakage. The checklist below is intended for testing archived extensions safely.

Pre-install checklist

  1. Read the extension entry details carefully: version, author, license and changelog.
  2. Confirm license permits your intended use.
  3. Download the package and save a checksum if provided.
  4. Inspect the archive contents for manifest files and known file structures.
  5. Run malware/virus scans and static analysis on the files.
  6. Set up or identify a staging environment that mirrors production (same Joomla and PHP versions where possible).
  7. Create full backups (files and database) or snapshots of the staging/prod site before installing anything.

Staging site setup: exact steps to test an extension before production

  1. Create a copy of your production site: export the database and copy site files, or use a snapshot tool.
  2. Install the copy on a local development environment or isolated hosted staging server.
  3. Match the PHP version and server extensions to production as closely as possible.
  4. Enable Joomla debug and error reporting for testing (do not leave these enabled in production).
  5. Install the extension on the staging copy and run a full site check (frontend, backend, menus, user login flows).

Backup checklist before installing any archived extension

  • Export the production database and store a copy offsite.
  • Make a compressed archive of site files or take a server snapshot.
  • Record the current list of installed extensions and their versions.
  • Test restoring the backups periodically so you are confident the process works.

Example workflow: Download module.zip → run ClamAV scan → extract and inspect manifest.xml → install on staging → test menu creation and admin forms → verify no PHP errors → plan rollout.

Warning: Never install unknown packages directly on production. If installation breaks admin access, be prepared to disable the extension from the filesystem or database and restore backups.

How to submit your extension to the Museum — step-by-step

If you want to contribute, prepare a clean, well-documented package and provide accurate metadata. The Museum usually requires account registration before submitting.

Step-by-step: creating an account and submitting an extension

  1. Create an account on the Museum site and verify your email address.
  2. Prepare your extension package as a single zip file containing the extension files, manifest, README and license file.
  3. Log in and choose the appropriate extension type (component, module, plugin, template etc.) on the Submit Extension page.
  4. Upload the zip, complete required metadata fields (name, version, supported Joomla versions, PHP requirements, description, tags) and attach license details.
  5. Accept the site terms and submit. Monitor your email for validation feedback.

What files and metadata to include in your submission

  • Manifest: manifest.xml for Joomla 3, and extension.json or updated manifest for Joomla 4. Include version, author, and supported Joomla versions tags.
  • README and changelog to help users understand changes and compatibility.
  • LICENSE or license.txt declaring the license used (e.g., GPL) and attribution where required.
  • Optional: link to a source repository and an issue tracker to help users report bugs.

Packaging example (conceptual): folder/
├─ plugin.php
├─ manifest.xml
├─ README.md
├─ changelog.txt
└─ license.txt
Zip the folder and upload the zip file.

Warning: Do not include sensitive files (private keys, credentials) in your package. Malformed manifests or missing license files are common causes for rejection.

What the Museum validation likely checks (and what to expect)

While the exact validation rules vary by site, common automated checks include manifest validation, basic package integrity, allowed file types and license declaration. Many archives also run malware scans.

Typical validation failures and how to fix them

  • Malformed manifest: validate XML/JSON syntax and required tags before zipping.
  • Missing license: include a license.txt file and declare the license in the manifest.
  • Unsupported file types: remove executables or unrelated artifacts from the package.
  • Dependency mismatches: document required PHP versions and Joomla dependencies in metadata.

Validation checklist example that contributors can run locally

  1. Run an XML validator (xmllint) against manifest.xml.
  2. Run a PHP linter (php -l) on PHP files to catch syntax errors.
  3. Check zip integrity (unzip -t or similar tools).
  4. Run a malware/antivirus scan on the package.

Warning: Automated scans can produce false positives. If your package is flagged, review the flagged items manually and contact Museum maintainers with clarifying information when re-submitting.

Compatibility tips: using older extensions on Joomla 3, 4 and later

Compatibility is the main technical hurdle when reusing older extensions. Manifests and install scripts are the first place to check for constraints; the code itself may rely on APIs that changed between Joomla 3 and Joomla 4.

How to read an extension manifest to check Joomla compatibility

Look for tags that indicate supported Joomla versions and PHP requirements. For Joomla 3 manifests, check the <version> and <creationDate> tags and any <files> or <scriptfile> entries. For Joomla 4 packages, check extension.json or the manifest fields that declare supported CMS versions and dependencies. Confirm any installation script names referenced in the manifest, as these scripts can require API calls that changed across versions.

Compatibility test matrix example

Create a simple matrix to record results:

Columns: Extension version | Joomla 3.10 | Joomla 4.x | PHP 7.4 | PHP 8.0/8.1
Rows: Pass/Fail and notes (admin form, frontend output, menu creation, errors).

Practical example: Install an older admin module on Joomla 3.10 and Joomla 4.x in staging, test configuration forms, and note any deprecated function calls or missing classes. If the module uses legacy API names, review and patch code only after confirming legal right to modify.

Warning: Older extensions may use deprecated APIs. Enable strict error reporting on staging only and be prepared to patch code or find alternatives.

Security, licensing and legal considerations (GPL requirement)

Security and licensing are central when reusing or distributing archived extensions. Always perform both automated and manual checks and confirm license terms before redistributing.

Automated and manual malware checks you should run

  • Automated tools: ClamAV for general virus scanning; PHP static analysis tools (e.g., PHP_CodeSniffer, Psalm) to flag suspicious patterns.
  • Manual checks: inspect PHP for eval(), base64_decode(), system() or unexpected external calls. Search for binary files or installers that do not belong in a Joomla extension.
  • For Composer-based packages, run dependency vulnerability checks (e.g., using a service or local scanner) if applicable.

What GPL-only acceptance means for contributors and users

If the Museum requires GPL licensing for uploads, contributors must be entitled to license code under GPL. For users, GPL permits redistribution and modification under GPL terms but may impose obligations on downstream distribution. If licensing is unclear, seek clarification from the Museum or legal counsel before republishing.

Practical example: Locate license.txt inside a package and confirm it states the GPL version. If absent, check the manifest license tag. If both are missing, do not redistribute until you have confirmation.

Warning: A GPL license does not guarantee code safety. Even GPL-licensed packages can contain insecure or malicious code. Always scan and test before using.

Troubleshooting common problems and rollback strategies

Installing archived extensions can trigger errors. Know how to recover quickly to minimize downtime.

How to revert a failed install: restore from backup, disable extension, roll back database

  1. If you have backups or snapshots, restore files and database to the pre-install state.
  2. If you need immediate mitigation and cannot restore a backup, disable the extension by renaming its folder in plugins, modules or components, or by setting its enabled state to 0 in the extensions table in the database.
  3. Clear Joomla caches and test admin access. If the admin area is inaccessible, review server error logs to find fatal errors and disable offending code.

Common error messages and how to approach them

  • PHP fatal errors: trace the file and line number to the extension files and examine recent changes.
  • Missing classes: check for namespace or API changes between Joomla versions and whether the extension expects legacy code.
  • Menu or routing failures: test menu items and check for overridden router scripts or outdated manifest routing declarations.

Example rollback scenario: An installed extension breaks menus. Restore the database from backup, rename the extension folder to prevent it loading, and reinstall a known-good extension version on staging to confirm the fix before redeploying.

Warning: Direct database edits carry risk. Always export the current database before making manual changes and verify SQL statements against official Joomla database documentation if you are unsure.

Where to get help and next steps

If you encounter problems related to an archived extension or a Museum entry, gather details and contact the appropriate support channels.

Who to contact and what information to provide when reporting a broken archive entry

  • Contact the Museum maintainers via the site’s contact form or support channel; include extension name, version, download link and exact error messages.
  • Include Joomla and PHP versions, relevant server environment details and reproduction steps.
  • Attach log excerpts (redact any sensitive data) and screenshots where helpful.

Next steps for maintainers and contributors

  • Maintain clear changelogs and update manifest metadata when releasing patched versions.
  • Provide a source repository and an issue tracker when possible to help users report and follow problems.
  • Encourage submitters to validate packages locally before upload using the validation checklist provided above.

Practical template for a support message: Include extension name/version, download URL (from Museum), Joomla & PHP versions, a short description of the problem, steps to reproduce, and a copy of relevant log entries.

Warning: Never include full database dumps or unredacted personal data in public bug reports.

FAQ

Is the Joomla Museum an official Joomla.org resource?

Not necessarily. Some archives are independent community projects. Verify the Museum’s status on its About/Contact pages and cross-check with official Joomla.org announcements before relying on it for production use.

Can I submit non-GPL extensions to the Museum?

Archives often have a licensing policy. Some may accept only GPL-licensed uploads. Verify the Museum’s policy before preparing a submission. If your code cannot be relicensed, consider vendor-hosted distribution or providing the package under the terms allowed by your license.

How do I know an archived extension is safe to install?

Use a safety checklist: inspect the manifest and metadata, run malware and static code scans, test on a staging site with matching PHP/Joomla versions, and review the author’s reputation and changelog.

What happens if my uploaded extension fails validation?

You will typically receive feedback explaining the failure (manifest errors, missing license, malware flags). Fix locally using the validation checklist and re-submit. If problems persist, contact Museum maintainers for clarification.

Can I request an extension to be uploaded if it's not in the Museum?

Yes. Provide the maintainers with as much information as possible—original vendor, download links, license details and proof of permission if required. Expect response times to vary depending on curator workload and validation processes.

Conclusion

The Joomla Museum can be a valuable resource for locating legacy and discontinued Joomla extensions. Use it with care: verify catalog and ownership details, inspect and scan packages, test everything on a staging site that mirrors production, and follow secure submission practices if you contribute. Before making production changes, verify important technical claims against the official Museum site and Joomla documentation.

For next steps, follow up with JoomlaForever guides on creating staging sites, performing backups, and safely managing extensions.

Add comment

Submit