Copies params from all mokowaas_* extension entries to their mokosuite_*
equivalents (plugins, modules, component, package), then unprotects and
deletes old extension records, update sites, and filesystem remnants.
Load FA7 in admin pages — checks MokoOnyx template params for Kit code,
falls back to bundled FA7 Free files, then FA6 CDN. Install script now
migrates mokowaas_* tables to mokosuite_* (create, copy data, drop old).
Rebrand all 17 sub-extensions from mokowaas to mokosuite naming,
including component, plugins, modules, task plugins, and webservices.
Updates package manifest, workflows, docs, wiki, and issue templates.
Adds new plg_system_mokosuite_license extension.
Hidden field defaults aren't stored in database params until the plugin
is re-saved. All 3 heartbeat paths now read the signing_key default
from the monitor plugin's manifest XML as a fallback.
cleanupStaleUpdateSites() matched '%MokoWaaS%' which also caught
MokoWaaSBase entries, deleting their update server registration.
Added NOT LIKE exclusions for MokoWaaSBase.
MokoWaaS now only saves/restores its own download key (pkg_mokowaas),
matching the pattern used by all other Moko extensions. Removed the
universal backupDownloadKeys/restoreDownloadKeys and the runtime
preserveDownloadKeys no-op from the core plugin.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The #__mokowaas_download_keys table approach was over-engineered.
Download key preservation is handled by the install script's
preflight/postflight with element-name matching.
Removed:
- #__mokowaas_download_keys table from install SQL
- syncKeysToTable/applyKeysFromTable from core plugin
- saveDownloadKey/applyDownloadKey/reapplyAllDownloadKeys from model
- ensureDownloadKeysTable/syncKeysToDatabase/reapplyKeysFromDatabase
from install script
Added:
- Migration SQL (02.35.00) to DROP the table from existing installs
- Uninstall SQL for all component tables
- Install/uninstall SQL blocks in component manifest
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The cleanup method used the old /raw/branch/main/updates.xml URL as
its keep target, but migrateUpdateServerUrls had already rewritten
all URLs to /updates.xml. This caused the method to find no match
and delete all MokoWaaS update sites — including the one with the
download key.
Fixed by updating the hardcoded URL to match the current manifest
format: /MokoConsulting/MokoWaaS/updates.xml
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Root cause: the #__mokowaas_download_keys table was only in
install.mysql.sql (fresh installs). Existing sites never got it,
so syncKeysToTable/applyKeysFromTable silently failed.
- Add sql/updates/mysql/02.35.00.sql migration for existing installs
- Register <update><schemas> in component manifest
- Add ensureDownloadKeysTable() as belt-and-suspenders in postflight
- backupDownloadKeys() now saves by element name (stable identifier)
- restoreDownloadKeys() matches by element first, URL second, ID third
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The URL migration in postflight changes update site URLs BEFORE
restoreDownloadKeys runs, so URL-based matching fails. Element names
are stable across updates. Now backs up keys as elem_ELEMENT and
restores by matching the extension element name first, falling back
to URL and ID.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace JSON file backup with #__mokowaas_download_keys table as
the persistent single source of truth for download keys.
- Core plugin: syncKeysToTable() copies keys from Joomla to our table,
applyKeysFromTable() re-applies from our table to Joomla. Runs on
every admin page load — Joomla can wipe keys all it wants.
- Install script: preflight saves to table, postflight re-applies.
- ExtensionsModel: saveDownloadKey(), applyDownloadKey(),
reapplyAllDownloadKeys() static method for install/update hooks.
- Extension manager: prompt for download key on install, skip
extensions with no release, show missing key warning badge.
- Catalog: expanded to 11 Joomla extensions.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Joomla's package installer deletes and recreates update site rows
from the manifest BETWEEN preflight and postflight. By the time
postflight ran backupDownloadKeys(), the extra_query values were
already empty.
Moved the backup to preflight() via a class property. The restore
in postflight() now uses keys saved before Joomla touched them.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
backupDownloadKeys() saves all extra_query values before migration and
cleanup operations. restoreDownloadKeys() re-applies them after, matching
by URL first then by old ID. Also updates the file-based backup used by
the runtime preserveDownloadKeys() guard.
Root cause: cleanupStaleUpdateSites() deletes update site rows which
destroys their extra_query (dlid) values. The rows get recreated by
Joomla but without the download keys.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Rename top-level src/ directory to source/ and update all references
in .gitignore, CLAUDE.md, manifest.xml, docs, and PATH comments.
Internal namespace path="src" attributes within extension packages
are unchanged (they refer to the package-internal src/ folder).
Closes#188
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Jonathan Miller