Fix branches already have their version bumped by pre-release (patch).
Auto-release now uses --bump none for these, just stripping the -dev
suffix to publish as stable. Feature/dev branches still bump minor.
- updateStatus() now accepts status ID, validates against lookup table,
writes both status and status_id columns, uses is_closed flag
- Added automation recursion guard to prevent infinite loops
- getStatusCounts() now joins on statuses table (dynamic, not hardcoded)
- getOverdueTickets() uses is_closed instead of ENUM string comparison
- Template SLA checks use status_is_closed instead of in_array()
- Status summary cards rendered dynamically from lookup table
Replace hardcoded ENUM status/priority with lookup tables
(#__mokosuite_ticket_statuses, #__mokosuite_ticket_priorities) so admins
can add custom values with colors and ordering. Integrate Joomla's
native custom fields (com_mokosuite.ticket context) with a junction
table linking field groups to ticket categories. Includes migration SQL
to populate new columns from existing ENUM data.
Tickets can now link to Joomla contact records (optional contact_id FK).
Replaces single assigned_to with junction table for multi-assignee
support — tickets can be assigned to multiple users and/or user groups.
Updates pre-release workflow to trigger on push to dev/alpha/beta/rc.
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.
Derives MOKO-XXXX-XXXX support PIN from health token and displays
it as a badge in the cpanel header row alongside the version badge.
Also adds base_url manifest XML fallback for Send Heartbeat button.
Removes handleGrafanaProvisioning(), sendHeartbeat() from core plugin,
and Grafana heartbeat from core plugin install script. MokoWaaSHQ
monitor plugin now handles all heartbeat communication. Updates language
strings to reference MokoWaaSHQ instead of Grafana.
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.
Client signs domain|timestamp|token with private key (distributed via
monitor plugin manifest). Base verifies with public key in component
config. Replaces shared secret and key ring approaches — no rotation
needed. Includes 5-minute timestamp window for replay protection.
Adds a heart icon button in the token field input group that triggers
an AJAX heartbeat to MokoWaaSBase. Shows spinner while sending,
green check on success, red X on failure. Uses the monitor plugin's
configured base_url and the core plugin's health_api_token.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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>
When Joomla deletes and recreates update site rows, they get new IDs.
The backup was keyed only by ID, so restored keys couldn't match the
new rows. Now stores keys by both ID and URL (url:https://...) and
looks up by URL as fallback when the ID doesn't match.
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>
- catalog.xml: added MokoWaaSBase, MokoJoomBackup, MokoJoomCommunity,
MokoJoomCross, MokoJoomStoreLocator (11 total extensions)
- ExtensionsModel: fetchFromUpdateServer() now returns has_stable,
has_dev, needs_dlid flags from updates.xml parsing
- ExtensionsModel: hasDownloadKey() checks if dlid is configured
in update_sites for each extension
- Template: red alert badge when download key is missing on installed
extensions that require one for updates
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
All net-new site-side files (19 files). No existing views modified.
Portal Dashboard:
- KPI cards: open orders, unpaid invoices, open tickets, pending signatures
- Recent orders table, quick links to all portal sections
- User matched to ERP contact by email address
My Orders (list + detail):
- Customer's order list with status/payment badges
- Order detail with line items, subtotal/tax/total
My Invoices (list + detail):
- Invoice list with overdue highlighting, balance due
- Invoice detail with line items and payment totals
E-Signature Public Signing Page:
- Token-based access (no Joomla login required)
- Consent checkbox (must accept before signing)
- HTML5 Canvas signature pad with touch/stylus/mouse support
- High-DPI canvas rendering
- Geolocation capture on submit
- Decline with reason
- signature-pad.js: full signing flow with consent → sign → success
E-Signature Verification Page:
- Hash-based public verification (no auth)
- Document status, signer table, complete audit trail
License Portal:
- Current license package, status, active services
- DLID entry/update form for self-service license management
Assets:
- portal.css: shared portal styles
- signature-pad.js: Canvas drawing with touch events, DPI scaling
1 model: PortalModel (resolves user→contact, loads orders/invoices/dashboard)
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>
ProvisionController: POST /api/v1/mokowaas/provision-reset
- Resets article hits to zero
- Deletes content version history
- Regenerates heartbeat token (optional, for breach response)
- Revokes all user API tokens with email notification (optional)
- Sets setup-required flag for new client info collection
Core plugin: checkSetupRequired() shows persistent admin banner
until plugin settings are saved. Clears flag on save.
Route registered in webservices plugin.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Monitor plugin now includes live health data (16 checks) and client
info (company name, email from Joomla config) in the heartbeat payload.
Health data is fetched via local HTTP call to /?mokowaas=health to
reuse existing auth and check logic without internal coupling.
MokoWaaSBase can use client_info for auto-contact creation and the
health payload for dashboard visualization without separate polling.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- RemoteLoginController: POST /api/v1/mokowaas/remote-login validates
health token, generates a one-time login token (60s TTL), returns
a URL that auto-authenticates the master user
- Core plugin: handleOneTimeLogin() in onAfterInitialise checks for
mokowaas_otl query param, validates and consumes the token, logs in
the master user, logs the event, redirects to admin dashboard
- Webservices plugin: register remote-login route
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Derives MOKO-XXXX-XXXX from health token for phone-based identity
verification during support calls. Displayed below the token field
in the core plugin config.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace ad-hoc Grafana receiver with MokoWaaSBase API integration.
The heartbeat now posts to /api/index.php/v1/mokowaasbase/heartbeat
with token, domain, site_name, versions. Configurable base URL
(defaults to mokoconsulting.tech). Removed hardcoded HEARTBEAT_URL
and HEARTBEAT_KEY constants.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Relocate CLAUDE.md from repo root to .mokogitea/ per project convention.
Content updated with focused, repo-specific architecture and rules.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Remove outdated branding/identity description, fix source directory
paths, update extension list to include all 17 sub-extensions,
document updates.xml is now in-repo, add Joomla 5/6 event compat note.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
DemoResetService, ContentSyncService, and ContentSyncReceiver were
deleted from the core plugin but still referenced by the demo task
plugin and API controllers. Moved service classes into their owning
packages with updated namespaces:
- DemoResetService → plg_task_mokowaasdemo/src/Service/
- ContentSyncService → plg_task_mokowaassync/src/Service/
- ContentSyncReceiver → plg_task_mokowaassync/src/Service/
Updated all require_once paths and FQCN references in API controllers
and DemoReset task plugin.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Override values are now hardcoded in the .ini files. Removed
getPlaceholders(), getPluginParams(), and resolvePlaceholders() methods
that were doing no-op string replacements.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Both plugins used Joomla 6-only event->getArgument() pattern without
fallback for Joomla 5 individual args. Added dual-compat pattern
matching DemoReset plugin: check for event object, fallback to
func_get_arg for Joomla 5.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The config field existed but had no backing implementation. Super admin
users are now redirected to the admin panel when accessing the frontend
if the toggle is enabled.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Add getMokoExtensions() to DashboardModel to fetch installed MokoWaaS
component and modules with versions. Renders version badges below the
info bar for com_mokowaas, mod_mokowaas_cpanel, mod_mokowaas_menu,
mod_mokowaas_cache, and mod_mokowaas_categories.
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>
Single header item with two clickable halves instead of two separate
status bar entries.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Add forms/trusted_ip_entry.xml to firewall plugin (was deleted from core)
- Update formsource paths to point to firewall's own forms directory
- Add missing Security Headers fieldset language strings
- Use hardcoded English labels in subform to avoid cross-plugin translation issues
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Joomla's installer can wipe extra_query (dlid) from #__update_sites
when rebuilding or reinstalling. The core plugin now backs up all
download keys and auto-restores any that get cleared. Runs on every
admin page load with a single lightweight query.
Closes#187
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace hardcoded CATALOG constant with catalog.xml that points to each
extension's updates.xml. The model fetches update servers at runtime to
resolve latest version and download URL. Adds update_available status
with Update button in the extensions view.
Closes#186
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
New module mod_mokowaas_categories auto-discovers article categories
from a configurable root and renders them as a collapsible sidebar tree.
Supports configurable depth, article counts, empty category filtering,
and ACL-aware access. Matches existing MokoWaaS sidebar styling.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
All API controllers now accept the $task parameter required by
Joomla\CMS\MVC\Controller\BaseController::execute($task).
Closes#183
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Remove branding, security hardening, demo mode, content sync, and API
actions from the core plugin. Config now shows only the heartbeat token.
Extension class reduced from 4226 to 2051 lines. Deleted 5 Field classes,
3 Service classes, 2 form XMLs, and media assets. Core retains health
checks, Grafana provisioning, site aliases, and extension cascade.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Template is managed independently; submodule reference no longer needed.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Override Atum's deep padding-left with tighter padding-inline-start
(0.5rem for level 2, 0.75rem for level 3 sub-components).
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Helpdesk: fa-solid fa-handshake-angle (was icon-headphones, unmapped)
- .htaccess: fa-solid fa-file-code (was icon-file-code, unmapped)
- Query now finds ALL submenu items under the MokoWaaS parent menu,
including those linking to com_plugins, com_installer, com_checkin, com_cache
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Move protectPlugin(), ensureProtectedFlag(), isOurExtension() from
core to firewall. Core no longer handles extension protection —
the firewall's onAfterRoute does it. Uses MokoWaaSHelper::isMasterUser().
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The act_runner DinD architecture means the job container (inner Docker)
doesn't share the outer container's volume mounts. Always clone fresh.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Plugin name: System - MokoWaaS Core (was System - MokoWaaS)
- Description updated to reflect admin tools suite coordinator role
- Removed updateAtumBranding() from plugin install script
- Removed brand_name placeholder from language override deployment
- Renamed "Health API Token" label to "Heartbeat Token" in language files
- Updated all .ini and .sys.ini descriptions (en-GB + en-US)
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replaced clickable header with a dedicated caret button (fa-caret-right/down)
on the far left that toggles the collapse. Dashboard button pushed to far right.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Unicode left/right quotes caused git clone to fail with
"protocol 'https' is not supported" inside Docker runner.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The icon-chevron-down appeared as random noise when the card was
collapsed. The entire header row is already clickable as a collapse
toggle — no separate indicator needed.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Targets a[href*="dashboard=help"] in addition to existing
help.joomla.org/docs.joomla.org overrides. Opens in new window.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Text::_() returned raw keys (COM_MOKOBACKUP, COM_MOKOJOOMCOMMUNITY)
because Joomla hadn't loaded those components' language files yet.
Now loads both .sys.ini and .ini for each discovered component.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
All workflows check for /opt/moko-platform first (updated by cron
every 6h). Falls back to fresh clone if not available. Eliminates
composer install timeouts that were causing build failures.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
MokoGitea license server generates updates.xml dynamically.
Removed: updates_xml_build.php call, updates.xml commit/push,
updates.xml branch sync. These are no longer needed.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Joomla's update finder sometimes fails to link #__updates records
to the installed extension. fixUpdateRecords() joins on element+type
to set the correct extension_id.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Queries #__menu for all com_moko* components (except com_mokowaas).
Renders each as a collapsible parent with its submenu items nested
at level 3. Icons and titles loaded from the DB menu records.
Uses Text::_() for language key translation.
MokoJoomBackup, MokoJoomCommunity, MokoJoomCross, etc. automatically
appear with their full submenu when installed — zero config needed.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace manual file deletion with Joomla's built-in cache API
(CacheControllerFactoryInterface::createCacheController->clean).
Same approach as com_cache uses. Cleans both site and admin cache.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
File-based cache cleanup already handles purging. The gc() calls
used a Joomla 5 API that may not work in Joomla 6, causing the
AJAX response to fail and show an error icon.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Delegates version bumping to moko-platform CLI tools:
- version_bump.php (patch default, --minor for RC)
- version_set_platform.php (stability suffix)
- version_check.php (consistency)
This keeps the workflow thin and the logic in the shared CLI.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Without this, repeated dev releases produce the same version and
Joomla won't offer the update (version not higher than installed).
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Add collapsible "New Request" form to privacy view (user select, type, auto-process)
- Controller handles 'create' action (pending) and 'approve' without request_id (auto-process: create + immediate approve)
- User dropdown populated from #__users
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Shows an "Open" link to the component dashboard for installed
components and packages that have a com_ admin directory.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Chart.js not bundled with Joomla 6 — use jsdelivr CDN with integrity check.
Dashboard user manager button shows MokoJoomCommunity (not Community Builder).
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The dashboard already shows site info, plugins, WAF blocks, logins,
and updates. The cpanel module duplicates this. Now it auto-hides
when option=com_mokowaas and view is dashboard or empty.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Add WAF activity bar chart and login activity line chart (Chart.js, 14 days)
- Add border-left separator between plugin grid and info panel
- Remove all 'small' CSS class usage for better readability
- Add getWafBlocksByDay() and getLoginsByDay() to DashboardModel
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- CHANGELOG.md now uses [Unreleased] section as staging area
- Only minor version headings (no dev patch numbers)
- pr-check.yml blocks PRs to main if [Unreleased] is empty
- pre-release.yml and auto-release.yml extract from [Unreleased] for release notes
- CONTRIBUTING.md documents the changelog workflow
- RC pre-release bumps minor version consolidating dev patches
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Dev patches (02.33.01, 02.33.02, etc.) exist for the update system.
RC consolidates to next minor: 02.33.xx → 02.34.00-rc.
auto-release already uses --bump minor for stable.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Adds a step after release creation that reads CHANGELOG.md, extracts
the latest version section, and PATCHes it onto the Gitea release body.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
MokoOnyx is a separate repo with its own release pipeline.
Bundling it as a submodule causes "Install path does not exist"
because the build doesn't create the ZIP correctly from submodule content.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Manual dispatch workflow that builds package from dev branch and
uploads to "development" release tag. No static updates.xml —
MokoGitea generates the update feed dynamically.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Joomla 6 + MySQL STRICT_TRANS_TABLES: the element column is NOT NULL
with no default. Package installer creates placeholder rows before
processing sub-extension manifests, causing INSERT failures. preflight()
adds DEFAULT '' so the INSERT succeeds.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Swap order: migrateStandalonePlugins() now runs before
removeRetiredExtensions() so TOS params are copied to
mokowaas_offline before the old plugin is deleted.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Add to removeRetiredExtensions(): uninstalls plugins, removes update sites,
and deletes files on MokoWaaS install/update. These features are now built
into MokoWaaS directly.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Add migrateUpdateServerUrls() to postflight: rewrites /raw/branch/main/updates.xml to /updates.xml for all Moko extensions
- Fix Helpdesk icon to fa-handshake-angle, .htaccess to fa-solid fa-file-code (unmapped in joomla-fontawesome.css)
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Cache cleaner button uses native header-item-content/header-item-icon markup
- Fix <em>Unassigned</em> showing raw HTML in tickets list (escape only non-null values)
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Joomla only renders img column icons for level-1 menu items. Level 2+
need menu_icon in the params JSON. This runs on every install/update.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Rewrite mod_mokowaas_menu template to use native MetisMenu classes (item, has-arrow, mm-collapse, mm-active, sidebar-item-title) — no custom CSS/JS
- Add <languages> element to component manifest so sys.ini deploys to administrator/language/en-GB/ for menu title translation
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Admin menu module now collapses by default, auto-expands on MokoWaaS pages (CB-style)
- Add mod_mokowaas_cache: one-click cache cleaner button in admin status bar (replaces Regular Labs Cache Cleaner)
- clearCache now purges all cache files (not just expired), matching RL behavior
- Update server URL changed to https://git.mokoconsulting.tech/MokoConsulting/MokoWaaS/updates.xml
- Add setupCacheModule() to package install script
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Restored warnMissingLicenseKey() in onAfterRoute. No session caching —
the warning fires on every admin page load if no download key (dlid)
is configured in the MokoWaaS update site. Only shown to master users.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
CI auto-bump was inserting duplicate version lines. Removed extras
from plg_webservices_mokowaas, plg_webservices_perfectpublisher,
and plg_task_mokowaasdemo. All 14 extensions now at 02.32.45.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
New trigger events hooked into core plugin:
- user_login — fires on successful Joomla login
- user_register — fires on new user creation
- user_login_failed — fires on failed login attempt
New action type: create_ticket with behavior options:
- append: add reply to existing open ticket (same user+category)
- always_new: always create a new ticket
- skip_if_open: do nothing if open ticket exists
New method: runSystemEventAutomation() for non-ticket events
that builds a virtual context object from event data.
Automation rules can now create tickets from any system event,
with intelligent deduplication to avoid ticket spam.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
New module mod_mokowaas_menu renders a dedicated MokoWaaS section
in the admin sidebar at position=menu, ordering=0 (before CB at 1
and Joomla's mod_menu at 2).
Menu items: Dashboard, Helpdesk, Extensions, .htaccess Maker,
Privacy Guard, WAF Log, Feature Plugins
Active state highlighting on current view.
Auto-created on package install with access=Special.
Added to package manifest.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Ticket Categories admin (view=categories):
- Inline editable table with SLA times, auto-assign user
- Add/save/delete with AJAX
- SLA response + resolution minutes per category
Canned Responses admin (view=canned):
- Card list with title + preview
- Modal form for new responses with category filter
- Delete with AJAX
Automation Rules admin (view=automation):
- Card list with conditions + actions displayed inline
- Enable/disable toggle per rule
- Modal form with trigger, conditions JSON, actions JSON
- Delete with AJAX
Controller tasks: saveCategory, deleteCategory, saveCanned,
deleteCanned, saveAutomation, deleteAutomation, toggleAutomation
All ACL-protected (tickets ACL for categories/canned, core.admin
for automation rules).
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
#118 Display current IP on dashboard info bar
#124 HTTP security headers at runtime (X-Frame, X-Content-Type, X-XSS,
Referrer-Policy, HSTS, CSP, Permissions-Policy) — new firewall
fieldset with per-header toggles
#143 WAF auto-ban: threshold + window params, auto-adds to IP blocklist
after N blocks in M minutes
#148 SSL certificate expiry monitoring in cpanel module (green/yellow/red
badge with days remaining)
#132 Settings import/export — export all plugin + component params as
JSON, import on another site
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Admin view at MokoWaaS > WAF Log:
- Rule distribution cards showing block counts per shield
- Filterable log table: rule, IP, search (URI/detail/UA), date range
- Pagination (50 per page)
- One-click IP ban from any log entry or top IPs sidebar
- Top 10 blocked IPs sidebar with ban buttons
- Purge old logs (configurable days)
- Color-coded rule badges (sqli=red, xss=red, mua=yellow, etc.)
WaflogModel:
- getLogs with filters + pagination
- getTotal for page count
- getRuleCounts for distribution cards
- getTopIps for sidebar
- getRuleNames for filter dropdown
- purgeLogs(days) with affected count
- banIp adds to firewall plugin IP blocklist params
ACL: core.admin (Super Users only)
Submenu: MokoWaaS > WAF Log
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Import markers stored in com_mokowaas component params (imported_admintools,
imported_ats). checkAdminToolsAvailable() and checkAtsAvailable() return null
if already imported, hiding the dashboard banner and ticket list button.
Also fixed missing 'use Joomla\CMS\Factory' in admin tickets template.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Ticket List (view=tickets):
- Staff see all tickets with Submitted By + Assigned To columns
- Customers see only their own tickets
- Status filter dropdown for staff
- isStaff check: core.admin OR mokowaas.tickets ACL
Ticket Detail (view=ticket):
- Staff see all tickets + internal notes (yellow highlight)
- Customers see only their own + no internal notes
- Staff sidebar: ticket details, change status buttons, assign to me
- Staff can post internal notes from frontend
- Customers can reply (disabled for closed tickets)
- Ownership enforced: customers can't view/reply to others' tickets
Controller:
- updateStatus: staff only
- assignTicket: mokowaas.tickets.assign ACL
- submitReply: verifies ownership OR staff
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Both frontend and admin ticket creation now show a KB search step
first. User types their issue, Smart Search (com_finder) returns
matching articles. If nothing helps, they click through to the
ticket form with the search query pre-filled as the subject.
Frontend (/support/submit-ticket):
- Search input with live results from #__finder_links
- Article links open in new tab
- "Submit Anyway" shows the ticket form
- Falls back to direct form if Smart Search has no indexed content
Admin (New Ticket modal):
- Same KB search step before the form
- Results as clickable list-group items
- Modal resets on close
Also:
- Added searchKb controller task (both frontend + admin)
- Added "Submit a Ticket" child menu item under Support on install
- Fixed innerHTML → safe DOM methods for search results
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Creates a frontend menu item at /support pointing to the customer
portal (com_mokowaas&view=tickets). Access level: Registered.
Idempotent — skips if already exists.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Frontend (site-side) views for authenticated users:
Ticket List (view=tickets):
- Shows user's own tickets with status badges
- Collapsible new ticket form with category + priority
- Redirects guests to login with return URL
Ticket Detail (view=ticket):
- Conversation thread (excludes internal notes)
- Staff replies highlighted with badge
- Reply form (disabled for closed/resolved tickets)
- User can only see their own tickets
Also fixed .gitignore to allow src/packages/*/site/ directories.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
New ImportModel with two importers:
Admin Tools Importer:
- Reads #__admintools_wafconfig → maps WAF shields, admin secret,
session timeout, template blocking to firewall plugin params
- Reads #__admintools_storage → maps server signature, HSTS, GZip,
expires, ETag, www redirect, directory listing to htaccess options
- Reads #__admintools_ipblock → merges into firewall IP deny list
- Disables com_admintools + all admintools plugins after import
Akeeba Ticket System Importer:
- Imports tickets with status/priority mapping
- First post becomes ticket body, rest become replies
- Imports canned replies
- Disables com_ats + all ATS plugins after import
Dashboard shows blue import banner when Akeeba data is detected.
Both importers require core.admin (Super Users only).
Idempotent — safe to run multiple times.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Auto-detects ATS tables (#__ats_tickets, #__ats_posts, #__ats_cannedreplies)
and shows an import button on the helpdesk ticket list with counts.
Imports:
- Tickets: maps ATS status (O/P/C) to MokoWaaS statuses, priority 1-5
to low/normal/high/urgent, preserves created_by/assigned_to/dates
- Posts: first post becomes ticket body, subsequent posts become replies
- Canned replies: imported with title and body (HTML stripped)
- Skips duplicates on re-import (idempotent)
ACL enforced: requires mokowaas.tickets permission.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Renamed plugin element from mokowaas_tos to mokowaas_offline to better
reflect its purpose (offline bypass, not just TOS).
Added migrateStandalonePlugins() to package script:
- Detects if standalone mokojoomtos plugin is installed
- Copies its params (configured slugs) to mokowaas_offline
- Removes old extension record, update sites, and files
- Logs the migration
Future standalone-to-MokoWaaS migrations can be added to the
$migrations array.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Core plugin's boot() called ipIsTrusted() which was deleted in the
cleanup. The session lifetime extension for trusted IPs is now in the
firewall plugin's boot() method where ipIsTrusted() still exists.
Firewall now implements BootableExtensionInterface.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
New plugin: plg_system_mokowaas_tos (Offline Bypass)
- Keeps configured pages accessible during offline mode
- SEF path matching + Itemid fallback
- Custom MenuslugField for multi-select menu items
- Include children option for parent menu matching
- Renamed from MokoJoomTOS to MokoWaaS Offline Bypass
Also:
- Added MokoJoomOpenGraph to extension manager catalog
- Added to package manifest, script.php, dashboard, cascade list
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Removed: resetAllHits, deleteAllVersions, warnMissingLicenseKey,
enforceDevMode, onDevModeDisabled, enforceHttps,
enforceAdminSessionTimeout, ipIsTrusted, enforceUploadRestrictions,
enforceAdminRestrictions, blockAccess, getHiddenMenuComponents
These methods were already unreachable after the call sites were
removed in the previous commit. The functionality lives in the
firewall, tenant, and devtools feature plugins.
Core plugin: 5366 -> 4759 lines
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The webservices plugin (element=mokowaas, folder=webservices) was
matching the PLUGIN_META entry for the core system plugin since the
lookup key was just the element name. Fixed by only matching system
and task plugins against PLUGIN_META; webservices/other folders use
folder_element as the key and fall through to guessPluginMeta.
Also includes auto-remove retired monitor plugin on package update.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Added removeRetiredExtensions() to package postflight script.
On every install/update, it checks for retired extensions and
removes them (DB record + files). Currently retires:
- plg_system_mokowaas_monitor (merged into core in 02.32.00)
Future retired extensions can be added to the $retired array.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The health monitor/Grafana heartbeat is mandatory infrastructure that
must always be active. The core system plugin (plg_system_mokowaas)
already has handleGrafanaProvisioning() and sendHeartbeat(), making
the separate monitor plugin redundant.
- Removed plg_system_mokowaas_monitor from package manifest
- Removed from script.php enable/protect lists
- Removed from cascade enable/disable logic
- Removed from dashboard plugin metadata
- Excluded from dashboard plugin discovery query
- Disabled on dev server (can be uninstalled manually)
Health monitoring is now entirely handled by the core plugin which
is protected and cannot be disabled.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Task plugins (demo reset, content sync) show Enabled/Disabled badge
instead of Protected — DB protected flag is for uninstall protection,
not dashboard display
- DevTools shows Enabled badge only (configure-only, no toggle) since
features are controlled inside the plugin settings
- Health Monitor marked as protected (cannot be disabled)
- Added explicit metadata for task plugins instead of relying on
guessPluginMeta
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
8 action buttons in a 4-column grid:
- Clear Cache, Check Updates, Moko Extensions (primary)
- Global Check-in, View Logs, Scheduled Tasks, User Manager, Redirects (secondary)
User Manager auto-detects Community Builder — links to com_comprofiler
if installed, otherwise com_users.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Clear Cache and Check Updates buttons now show text labels instead
of icon-only.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
MokoWaaS -> /kb/mokowaas-platform
MokoOnyx -> /kb/mokoonyx-template
Also updated all live KB category descriptions with read more links
and unpublished duplicate categories (68, 69).
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Replaced repo links with mokoconsulting.tech/kb/ article links
- Added uninstall button for installed non-protected packages
- Protected packages (MokoWaaS) cannot be uninstalled
- Uninstall confirms before proceeding via com_installer
- Removed update_available status (updates go through Joomla native)
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Removed update_available status and update button — each package
registers its own update server URL, so updates are handled via
Joomla's native System > Update mechanism.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
New view at index.php?option=com_mokowaas&view=extensions showing:
- Curated catalog of Moko Consulting Joomla packages
- Install status (installed, update available, not installed)
- Local vs remote version comparison
- One-click install/update from Gitea releases
- Repo link for each package
- Grouped by category (Platform, Templates, Components, Modules, Plugins)
- Quick access button on the dashboard
Catalog includes: MokoWaaS, MokoOnyx, MokoCassiopeia, MokoJoomTOS,
MokoJoomHero, MokoWaaSAnnounce, MokoDPCalendarAPI, MokoGalleryCalendar
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Merged disk/IP/versions, plugin badges, and quick actions into one
inline row with border separators. Icons-only for action buttons.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When the core system plugin is disabled, all feature plugins
(firewall, tenant, devtools, monitor) and the cpanel module are
automatically disabled too. Re-enabling cascades the same way.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Added module params to show/hide individual sections:
- Collapsed by default (toggle)
- Health status
- Stats cards (articles, users, updates)
- Disk usage bar
- Current IP display
- Feature plugin badges
- Quick action buttons
- Joomla/PHP versions
Each section respects its toggle. Plugin badges link to config pages.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
┌────────────────────────────────────────────────────────────────────┐
│ version_read v04.00.15 │
│ Read version — manifest.xml is canonical, falls back to README.md and Joomla XML│
└────────────────────────────────────────────────────────────────────┘
02.32.11 [skip ci]
- Module body collapsed by default, header row toggles expand/collapse
- Feature plugin badges are now clickable links to plugin config page
- Added extension_id to helper query for URL building
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Adds MokoOnyx as a git submodule at src/packages/tpl_mokoonyx (pinned
to main branch) so it packages alongside all other MokoWaaS extensions.
Every WaaS site uses both, so installing them as a single package
ensures they stay in sync.
- Added submodule for MokoOnyx repo
- Added template entry to pkg_mokowaas.xml
- Added mokoonyx to protected extensions in script.php
- Added submodules: recursive to CI checkout steps
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
┌────────────────────────────────────────────────────────────────────┐
│ version_read v04.00.15 │
│ Read version — manifest.xml is canonical, falls back to README.md and Joomla XML│
└────────────────────────────────────────────────────────────────────┘
02.32.10 [skip ci]
Atum template has a 'top' position that renders full-width above the
component output inside the content section. Removed the column-span
CSS hack since top position is naturally full-width.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
┌────────────────────────────────────────────────────────────────────┐
│ version_read v04.00.15 │
│ Read version — manifest.xml is canonical, falls back to README.md and Joomla XML│
└────────────────────────────────────────────────────────────────────┘
02.32.09 [skip ci]
Uses CSS column-span:all with :has() selector to force the module's
parent .module-wrapper to span across all card-columns, rendering as
a full-width card at the top of the dashboard.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
┌────────────────────────────────────────────────────────────────────┐
│ version_read v04.00.15 │
│ Read version — manifest.xml is canonical, falls back to README.md and Joomla XML│
└────────────────────────────────────────────────────────────────────┘
02.32.08 [skip ci]
Joomla's cpanel view renders quickicon (icon position) modules above
regular cpanel modules. Changed from position=cpanel to position=icon
so MokoWaaS appears at the very top of the admin dashboard.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
┌────────────────────────────────────────────────────────────────────┐
│ version_read v04.00.15 │
│ Read version — manifest.xml is canonical, falls back to README.md and Joomla XML│
└────────────────────────────────────────────────────────────────────┘
02.32.07 [skip ci]
┌────────────────────────────────────────────────────────────────────┐
│ version_read v04.00.15 │
│ Read version — manifest.xml is canonical, falls back to README.md and Joomla XML│
└────────────────────────────────────────────────────────────────────┘
02.32.06 [skip ci]
- Article count, user count, pending updates with badges
- Disk usage progress bar with color coding
- Current IP display
- Clear Cache button with AJAX spinner
- Check Updates + update count button
- Module defaults to ordering=-1 (top) and access=Super Users
- Added padding to module container
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The CI auto-bump's version_read.php was printing its CliFramework
banner to stdout, which got captured by exec() and injected into
<version> tags via version_set_platform.php's regex replacement.
Root cause fixed in moko-platform (--quiet flag + version format
validation). This commit repairs all corrupted manifests and adds
padding to the cpanel module.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
┌────────────────────────────────────────────────────────────────────┐
│ version_read v04.00.15 │
│ Read version — manifest.xml is canonical, falls back to README.md and Joomla XML│
└────────────────────────────────────────────────────────────────────┘
02.32.05 [skip ci]
Joomla 5 module templates don't have $this — data comes via extracted
variables from getLayoutData(). Replace $this->escape() with
htmlspecialchars() and remove $app reference.
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
┌────────────────────────────────────────────────────────────────────┐
│ version_read v04.00.15 │
│ Read version — manifest.xml is canonical, falls back to README.md and Joomla XML│
└────────────────────────────────────────────────────────────────────┘
02.32.04 [skip ci]
Admin dashboard module (mod_mokowaas_cpanel) showing:
- MokoWaaS version, debug/offline status badges
- Health indicator (database connectivity check)
- Feature plugin status badges (enabled/disabled)
- Link to full MokoWaaS control panel
- Auto-assigns to cpanel position on install
Authored-by: Moko Consulting
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
> This file may contain unfilled `{{TOKEN}}` placeholders. The MokoStandards bulk-sync system
> replaces them automatically at sync time; if you can still see them, sync has not yet run for
> this repository — or this is a brand-new repo.
>
> **On your very first interaction in this repository, before answering any other question:**
>
> 1. Check whether any `{{TOKEN}}` placeholders remain in this file.
> 2. If they do, locate the values as described in the table below and replace every occurrence
> in **both** `.github/copilot-instructions.md` and `.github/CLAUDE.md`.
> 3. After replacing all tokens, **delete this entire notice block** (from `> [!IMPORTANT]`
> through the closing `> ---` line) in both files.
> 4. Tell the developer: *"I've self-updated the AI context files with this repository's
> values — all set."*
>
> | Placeholder | Where to find the value |
> |---|---|
> | `MokoWaaS` | The GitHub repository name (visible in the URL, `README.md` heading, or `git remote -v`) |
> | `https://github.com/mokoconsulting-tech/MokoWaaS` | Full GitHub URL, e.g. `https://github.com/mokoconsulting-tech/<repo-name>` |
> | `{{EXTENSION_NAME}}` | The `<name>` element in `manifest.xml` at the repository root |
> | `{{EXTENSION_TYPE}}` | The `type` attribute of the `<extension>` tag in `manifest.xml` (`component`, `module`, `plugin`, or `template`) |
> | `{{EXTENSION_ELEMENT}}` | The `<element>` tag in `manifest.xml`, or the filename prefix (e.g. `com_myextension`, `mod_mymodule`) |
>
> ---
## Commands
# MokoWaaS — GitHub Copilot Custom Instructions
## What This Repo Is
This is a **Moko Consulting MokoWaaS** (Joomla) repository governed by [MokoStandards](https://github.com/mokoconsulting-tech/MokoStandards). All coding standards, workflows, and policies are defined there and enforced here via bulk sync.
**PHP** (≥ 7.4) is the primary language for this Joomla extension. JavaScript may be used for frontend enhancements. YAML uses 2-space indentation. All other text files use tabs per `.editorconfig`.
---
## File Header — Always Required on New Files
Every new file needs a copyright header as its first content.
**`README.md` is the single source of truth for the repository version.**
### Update Server
- **Bump the patch version on every PR** — increment `XX.YY.ZZ` (e.g. `01.02.03` → `01.02.04`) in `README.md` before opening the PR; the `sync-version-on-merge` workflow propagates it automatically to all badges and `FILE INFORMATION` headers on merge to `main`.
- The `VERSION: XX.YY.ZZ` field in `README.md` governs all other version references.
- Version format is zero-padded semver: `XX.YY.ZZ` (e.g. `01.02.03`).
- Never hardcode a specific version in document body text — use the badge or FILE INFORMATION header only.
MokoGitea generates update feeds dynamically from releases — no static `updates.xml` needed.
### Joomla Version Alignment
## Source Directory
The version in `README.md`**must always match** the `<version>` tag in `manifest.xml` and the latest entry in `updates.xml`. The `make release` command / release workflow updates all three automatically.
Source lives in `source/` (not `src/`):
-`source/pkg_mokosuite.xml` — package manifest
-`source/script.php` — install script
-`source/packages/` — all sub-extensions
```xml
<!-- In manifest.xml — must match README.md version -->
<version>01.02.04</version>
## Rules
<!-- In updates.xml — prepend a new <update> block for every release.
Note: the backslash in version="4\.[0-9]+" is a literal backslash character
in the XML attribute value. Joomla's update server treats the value as a
regular expression, so \. matches a literal dot. -->
- MokoGitea's endpoint validates license keys passed as `?dlid=MOKO-XXXX-XXXX-XXXX-XXXX`
- The generated XML includes `<downloadkey prefix="dlid=" suffix="" />` to tell Joomla a key is required
- Users enter the download key via Joomla's native **System → Update Sites** interface
- Joomla stores the key in `#__update_sites.extra_query` and appends it to all update/download requests
- Invalid/expired keys receive an empty `<updates></updates>` response
**Rules:**
- Do NOT create or commit a static `updates.xml` — MokoGitea generates it from releases
- The `<version>` in release tags must match `<version>` in the manifest and `README.md`
- Release assets (ZIPs) must be attached to git releases — MokoGitea uses them for `<downloadurl>`
-`<targetplatform name="joomla" version="(5|6)\..*">` — the backslash is a **literal backslash character** in the XML attribute value; Joomla's update-server parser treats the value as a regular expression
---
## manifest.xml Rules
- Lives at the repo root as `manifest.xml` (not inside `site/` or `admin/`).
-`<version>` tag must be kept in sync with `README.md` version and `updates.xml`.
- Must include `<updateservers>` block pointing to this repo's `updates.xml`.
- Must include `<files folder="site">` and `<administration>` sections.
- Joomla 4.x requires `<namespace path="src">Moko\{{EXTENSION_NAME}}</namespace>` for namespaced extensions.
---
## GitHub Actions — Token Usage
Every workflow must use **`secrets.GH_TOKEN`** (the org-level Personal Access Token).
```yaml
# ✅ Correct
- uses:actions/checkout@v4
with:
token:${{ secrets.GH_TOKEN }}
env:
GH_TOKEN:${{ secrets.GH_TOKEN }}
```
```yaml
# ❌ Wrong — never use these in workflows
token:${{ github.token }}
token:${{ secrets.GITHUB_TOKEN }}
```
---
## MokoStandards Reference
This repository is governed by [MokoStandards](https://github.com/mokoconsulting-tech/MokoStandards). Authoritative policies:
| Document | Purpose |
|----------|---------|
| [file-header-standards.md](https://github.com/mokoconsulting-tech/MokoStandards/blob/main/docs/policy/file-header-standards.md) | Copyright-header rules for every file type |
| [coding-style-guide.md](https://github.com/mokoconsulting-tech/MokoStandards/blob/main/docs/policy/coding-style-guide.md) | Naming and formatting conventions |
| [branching-strategy.md](https://github.com/mokoconsulting-tech/MokoStandards/blob/main/docs/policy/branching-strategy.md) | Branch naming, hierarchy, and release workflow |
| [merge-strategy.md](https://github.com/mokoconsulting-tech/MokoStandards/blob/main/docs/policy/merge-strategy.md) | Squash-merge policy and PR title/body conventions |
| [changelog-standards.md](https://github.com/mokoconsulting-tech/MokoStandards/blob/main/docs/policy/changelog-standards.md) | How and when to update CHANGELOG.md |
| [joomla-development-guide.md](https://github.com/mokoconsulting-tech/MokoStandards/blob/main/docs/guide/waas/joomla-development-guide.md) | MokoWaaS Joomla extension development guide |
---
## Naming Conventions
| Context | Convention | Example |
|---------|-----------|---------|
| PHP class | `PascalCase` | `MyController` |
| PHP method / function | `camelCase` | `getItems()` |
BRIEF: GitHub Copilot custom instructions template for Joomla/MokoWaaS governed repositories
NOTE: Synced to .github/copilot-instructions.md in all Joomla/WaaS repos via bulk sync.
Tokens replaced at sync time: MokoWaaS, https://github.com/mokoconsulting-tech/MokoWaaS, {{EXTENSION_NAME}},
BRIEF: GitHub Copilot custom instructions template for Joomla/MokoSuite governed repositories
NOTE: Synced to .github/copilot-instructions.md in all Joomla/Suite repos via bulk sync.
Tokens replaced at sync time: MokoSuite, https://github.com/mokoconsulting-tech/MokoSuite, {{EXTENSION_NAME}},
{{EXTENSION_TYPE}}, {{EXTENSION_ELEMENT}}
-->
@@ -36,24 +36,24 @@ NOTE: Synced to .github/copilot-instructions.md in all Joomla/WaaS repos via bul
>
> | Placeholder | Where to find the value |
> |---|---|
> | `MokoWaaS` | The GitHub repository name (visible in the URL, `README.md` heading, or `git remote -v`) |
> | `https://github.com/mokoconsulting-tech/MokoWaaS` | Full GitHub URL, e.g. `https://github.com/mokoconsulting-tech/<repo-name>` |
> | `MokoSuite` | The GitHub repository name (visible in the URL, `README.md` heading, or `git remote -v`) |
> | `https://github.com/mokoconsulting-tech/MokoSuite` | Full GitHub URL, e.g. `https://github.com/mokoconsulting-tech/<repo-name>` |
> | `{{EXTENSION_NAME}}` | The `<name>` element in `manifest.xml` at the repository root |
> | `{{EXTENSION_TYPE}}` | The `type` attribute of the `<extension>` tag in `manifest.xml` (`component`, `module`, `plugin`, or `template`) |
> | `{{EXTENSION_ELEMENT}}` | The `<element>` tag in `manifest.xml`, or the filename prefix (e.g. `com_myextension`, `mod_mymodule`) |
>
> ---
# MokoWaaS — GitHub Copilot Custom Instructions
# MokoSuite — GitHub Copilot Custom Instructions
## What This Repo Is
This is a **Moko Consulting MokoWaaS** (Joomla) repository governed by [MokoStandards](https://github.com/mokoconsulting-tech/MokoStandards). All coding standards, workflows, and policies are defined there and enforced here via bulk sync.
This is a **Moko Consulting MokoSuite** (Joomla) repository governed by [MokoStandards](https://github.com/mokoconsulting-tech/MokoStandards). All coding standards, workflows, and policies are defined there and enforced here via bulk sync.
@@ -257,7 +257,7 @@ This repository is governed by [MokoStandards](https://github.com/mokoconsulting
| [branching-strategy.md](https://github.com/mokoconsulting-tech/MokoStandards/blob/main/docs/policy/branching-strategy.md) | Branch naming, hierarchy, and release workflow |
| [merge-strategy.md](https://github.com/mokoconsulting-tech/MokoStandards/blob/main/docs/policy/merge-strategy.md) | Squash-merge policy and PR title/body conventions |
| [changelog-standards.md](https://github.com/mokoconsulting-tech/MokoStandards/blob/main/docs/policy/changelog-standards.md) | How and when to update CHANGELOG.md |
| [joomla-development-guide.md](https://github.com/mokoconsulting-tech/MokoStandards/blob/main/docs/guide/waas/joomla-development-guide.md) | MokoWaaS Joomla extension development guide |
| [joomla-development-guide.md](https://github.com/mokoconsulting-tech/MokoStandards/blob/main/docs/guide/waas/joomla-development-guide.md) | MokoSuite Joomla extension development guide |
echo "::error::joomla.asset.json is not valid JSON"
ERRORS=$((ERRORS + 1))
}
fi
echo "joomla.asset.json: valid"
fi
# Validate all XML files in src/ are well-formed
XML_ERRORS=0
if command -v php &> /dev/null; then
while IFS= read -r -d '' xmlfile; do
if ! php -r "libxml_use_internal_errors(true); \$x = simplexml_load_file('$xmlfile'); if(!\$x){foreach(libxml_get_errors() as \$e) echo trim(\$e->message) . ' in $xmlfile'; exit(1);}" 2>&1; then
echo "::error::Manifest contains legacy raw/branch update server URL on MokoGitea. Use the Gitea Pages URL instead (e.g. /{REPO}/updates.xml not /{REPO}/raw/branch/main/updates.xml)"
echo "$RAW_URLS"
exit 1
fi
echo "Joomla manifest valid"
;;
dolibarr)
@@ -183,6 +295,162 @@ jobs:
;;
esac
- name:Check changelog has unreleased entries (PRs to main)
if:github.base_ref == 'main'
run:|
if [ ! -f "CHANGELOG.md" ]; then
echo "::error::CHANGELOG.md not found — required for releases"
exit 1
fi
# Extract content between [Unreleased] and next ## heading
-plg_system_mokowaas_tenant — Installer, sysinfo, config, template, and menu restrictions for non-master users
-plg_system_mokowaas_devtools — Dev mode, hit counter reset, content version cleanup
-plg_system_mokowaas_monitor — Grafana heartbeat integration and health monitoring
-MokoWaaSHelper utility class for shared master-user detection across feature plugins
-RSA-signed heartbeat authentication — private key in monitor plugin manifest, public key on MokoSuiteHQ
-Monitor plugin base_url set via manifest (hidden from admin UI), propagated via update server
-Send Heartbeat button on health token field for manual heartbeat testing
-Font Awesome 7 loaded in admin backend — picks up MokoOnyx Kit code if present, falls back to bundled FA7 Free or FA6 CDN
-MokoWaaS → MokoSuite database table migration in install script (create new, copy data, drop old)
-MokoWaaS → MokoSuite extension param migration — copies params from all old mokowaas plugins/modules/component, then removes old entries and filesystem remnants
-Ticket contact linking — optional FK to Joomla contact records with display in list and detail views
- Multi-assignee tickets — junction table supports multiple users and user groups per ticket
- Customizable ticket priorities — admin-configurable lookup table with weight and color
- Joomla custom fields integration for tickets (context: com_mokosuite.ticket) with field groups assignable per category
- MokoWaaS/MokoWaaSHQ migration bridge repos with updates.xml redirecting existing installs to MokoSuite/HQ
- Pre-release workflow triggers on push to dev/alpha/beta/rc branches (deployed to all 11 repos)
### Removed
- PerfectPublisher webservices plugin (no longer needed)
### Fixed
- Download key lost on update: cleanupStaleUpdateSites used old /raw/branch/main/ URL format, deleting the manifest-registered update site that held the key
## [02.35.00] - 2026-06-06
### Added
- Core plugin stripped to heartbeat-only config (~5,500 lines removed)
- Extension catalog (catalog.xml) with update server discovery (#186)
- Download key preservation across Joomla updates (#187)
- Remote login endpoint for MokoSuiteHQ auto-login
- Provision reset API for new client setup (hits, versions, tokens)
- Setup required banner after provision reset
- Support verification PIN (MOKO-XXXX-XXXX)
- mod_mokosuite_categories — auto-category tree menu (#184)
- Cache/temp split button in status bar
- Dashboard version tiles for component and modules
- Monitor plugin sends full health payload to MokoSuiteHQ
- Firewall: block_frontend_superuser, own trusted_ip_entry.xml
- DevTools: reset download keys toggle
### Changed
- Renamed src/ to source/ (#188)
- Service classes relocated to owning plugins
- API controller execute() signatures fixed (#183)
- Joomla 5/6 event compatibility in DevTools and Monitor
- Dead placeholder resolver removed from install script
-WaaS Access config tab (master user toggle, master email)
-Suite Access config tab (master user toggle, master email)
- Content Sync config tab (targets now in scheduled tasks)
- Site Aliases config tab (hardcoded to dev.{primary_domain})
- File sync (images/, files/, media/) — sync is API/DB content only
## [02.29.03] - 2026-05-31
## [02.29] - 2026-05-31
### Added
-`allow_extension_updates` param — separate update rights from installer restrictions; tenants can update extensions by default even when the installer is restricted
- Emergency access IP whitelist: empty `allowed_ips` now permits all IPs (was blocking everyone)
- Emergency access reads `allowed_ips` from plugin params instead of global config
-`plg_task_mokowaassync` — Joomla Scheduled Task plugin for automatic content sync to remote sites
-`plg_task_mokosuitesync` — Joomla Scheduled Task plugin for automatic content sync to remote sites
- Community Builder tables added to demo reset safe table list
- API endpoint `POST /api/index.php/v1/mokowaas/install` — install extensions from a remote ZIP URL
- API endpoint `POST /api/index.php/v1/mokosuite/install` — install extensions from a remote ZIP URL
- Demo Mode with configurable warning banner on frontend when enabled
### Fixed
- Demo banner countdown now shows weeks/days/months for longer intervals instead of raw hours
-`DemoResetService` — baseline snapshot and restore for DB tables + media files
- API endpoints `POST /?mokowaas=reset` and `POST /?mokowaas=snapshot` (query-string)
- REST endpoints `POST /api/v1/mokowaas/reset` and `GET/POST /api/v1/mokowaas/snapshot`
-`plg_task_mokowaasdemo` — Joomla Scheduled Task plugin for automatic demo site reset
- API endpoints `POST /?mokosuite=reset` and `POST /?mokosuite=snapshot` (query-string)
- REST endpoints `POST /api/v1/mokosuite/reset` and `GET/POST /api/v1/mokosuite/snapshot`
-`plg_task_mokosuitedemo` — Joomla Scheduled Task plugin for automatic demo site reset
- Admin toggles: Take Snapshot Now and Restore Baseline Now in plugin config
- Content Sync: one-way push of articles, categories, menus, and modules to remote MokoWaaS sites
- Content Sync: API endpoints `POST /?mokowaas=sync` (sender) and `POST /?mokowaas=sync-receive` (receiver)
- Content Sync: REST endpoints `POST /api/v1/mokowaas/sync` and `POST /api/v1/mokowaas/sync-receive`
- Content Sync: one-way push of articles, categories, menus, and modules to remote MokoSuite sites
- Content Sync: API endpoints `POST /?mokosuite=sync` (sender) and `POST /?mokosuite=sync-receive` (receiver)
- Content Sync: REST endpoints `POST /api/v1/mokosuite/sync` and `POST /api/v1/mokosuite/sync-receive`
- Content Sync: configurable sync targets with URL + API token in plugin settings
- Package installer: protect all MokoWaaS extensions (not just system plugin) and ensure update server stays enabled
- Package installer: clean up legacy `mokowaasbrand` extension entries and files on install/update
- API endpoint `GET /?mokowaas=extensions` and `GET /api/v1/mokowaas/extensions` — list installed extensions with version, status, and update server info
- Package installer: protect all MokoSuite extensions (not just system plugin) and ensure update server stays enabled
- Package installer: clean up legacy `mokosuitebrand` extension entries and files on install/update
- API endpoint `GET /?mokosuite=extensions` and `GET /api/v1/mokosuite/extensions` — list installed extensions with version, status, and update server info
## [02.20.00] --- 2026-05-28
## [02.20.00] --- 2026-05-28
## [02.19.00] --- 2026-05-28
## [02.18.00] --- 2026-05-28
All notable changes to the MokoWaaS plugin will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
MokoWaaS is a Joomla 5.x / 6.x system plugin package that provides white-label branding, security hardening, tenant restrictions, health monitoring, and multi-domain management for the MokoWaaS platform.
MokoSuite is a Joomla 5.x / 6.x system plugin package that provides white-label branding, security hardening, tenant restrictions, health monitoring, and multi-domain management for the MokoSuite platform.
@@ -40,19 +40,19 @@ MokoWaaS is a Joomla 5.x / 6.x system plugin package that provides white-label b
## Installation
Download the latest `pkg_mokowaas-*.zip` from [Releases](https://git.mokoconsulting.tech/MokoConsulting/MokoWaaS/releases) and install via **System → Install → Upload Package File**.
Download the latest `pkg_mokosuite-*.zip` from [Releases](https://git.mokoconsulting.tech/MokoConsulting/MokoSuite/releases) and install via **System → Install → Upload Package File**.
After installation, the package auto-enables and sets protected status.
## Documentation
Full documentation is available on the [MokoWaaS Wiki](https://git.mokoconsulting.tech/MokoConsulting/MokoWaaS/wiki):
Full documentation is available on the [MokoSuite Wiki](https://git.mokoconsulting.tech/MokoConsulting/MokoSuite/wiki):
This document defines the complete build and packaging workflow for the MokoWaaS system plugin. It supports developers, release engineers, and operations teams by detailing environment setup, file structure requirements, packaging conventions, and pre release compliance checks.
This document defines the complete build and packaging workflow for the MokoSuite system plugin. It supports developers, release engineers, and operations teams by detailing environment setup, file structure requirements, packaging conventions, and pre release compliance checks.
## 2. Build Requirements
@@ -40,13 +40,13 @@ Optional but recommended:
## 3. Repository Structure Overview
The repository should maintain a clean, predictable, and modular structure suitable for Joomla system plugins, WaaS platform governance, and automated build tooling. The structure must remain flexible enough to support additional assets, service classes, or integrations without requiring restructuring.
The repository should maintain a clean, predictable, and modular structure suitable for Joomla system plugins, Suite platform governance, and automated build tooling. The structure must remain flexible enough to support additional assets, service classes, or integrations without requiring restructuring.
```text
mokowaas/
├── src/
│ ├── mokowaas.php (main plugin file)
│ ├── mokowaas.xml (plugin manifest)
mokosuite/
├── source/
│ ├── mokosuite.php (main plugin file)
│ ├── mokosuite.xml (plugin manifest)
│ ├── services/ (service providers for DI)
│ │ └── provider.php
│ ├── language/ (plugin language files)
@@ -110,7 +110,7 @@ Remove any unneeded files:
Using CLI:
```bash
zip -r mokowaas_v01.04.00.zip ./ -x "*.git*""scripts/*""docs/*"
zip -r mokosuite_v01.04.00.zip ./ -x "*.git*""scripts/*""docs/*"
```
Ensure excluded paths match release governance and do not remove required runtime files.
@@ -150,7 +150,7 @@ Possible automations:
After release:
* Update download links and release notes
* Notify WaaS internal release channels
* Notify Suite internal release channels
* Update dependent templates or modules if required
* Record the release in any internal environment or asset registry
@@ -161,7 +161,7 @@ A continuous integration and delivery pipeline is implemented using GitHub Actio
### 8.1 Build and Validate Workflow (`.github/workflows/build.yml`)
```yaml
name:Build and Validate MokoWaaS
name:Build and Validate MokoSuite
on:
push:
@@ -192,23 +192,23 @@ jobs:
- name:Lint PHP and syntax check
run:|
echo "[INFO] Run php -l over src/ and any additional linting as needed."
echo "[INFO] Run php -l over source/ and any additional linting as needed."
- name:Create build artifact
run:|
zip -r mokowaas_ci_build.zip ./ -x "*.git*" "docs/*" "scripts/*"
zip -r mokosuite_ci_build.zip ./ -x "*.git*" "docs/*" "scripts/*"
This guide outlines the configuration parameters available within the MokoWaaS system plugin and establishes recommended defaults for WaaS governed environments. Proper configuration ensures consistent branding behavior across templates, modules, and administrative surfaces.
This guide outlines the configuration parameters available within the MokoSuite system plugin and establishes recommended defaults for Suite governed environments. Proper configuration ensures consistent branding behavior across templates, modules, and administrative surfaces.
## 2. Accessing Plugin Configuration
1. Log in to Joomla Administrator.
2. Navigate to **System > Plugins**.
3. Search for **MokoWaaS**.
3. Search for **MokoSuite**.
4. Select the plugin name to open the configuration panel.
## 3. Plugin Parameters
@@ -47,7 +47,7 @@ Master switch for all branding overrides. When disabled, no language overrides a
| -------- | ----- |
| Field name | `brand_name` |
| Type | Text |
| Default | `MokoWaaS` |
| Default | `MokoSuite` |
The brand name that replaces "Joomla" throughout the interface. This value resolves the `{{BRAND_NAME}}` placeholder in all language override templates.
@@ -90,7 +90,7 @@ URL for support and documentation links. Resolves the `{{SUPPORT_URL}}` placehol
## 4. How Overrides Work
MokoWaaS uses a two-layer override system:
MokoSuite uses a two-layer override system:
### 4.1 Runtime Resolution (Primary)
@@ -103,16 +103,16 @@ On every page load, the plugin reads override template files shipped with the pl
During install/update, the install script resolves placeholders and writes the result into Joomla's global language override files inside a sentinel block:
```ini
; ===== BEGIN MokoWaaS Overrides (do not edit this block) =====
; ===== BEGIN MokoSuite Overrides (do not edit this block) =====
; Auto-generated on 2026-04-07 — do not edit manually.
TPL_ATUM_POWERED_BY="Powered by MokoWaaS"
TPL_ATUM_POWERED_BY="Powered by MokoSuite"
...
; ===== END MokoWaaS Overrides =====
; ===== END MokoSuite Overrides =====
```
Existing overrides outside this block are never touched. On uninstall, only the MokoWaaS block (and any legacy stray keys) are removed.
Existing overrides outside this block are never touched. On uninstall, only the MokoSuite block (and any legacy stray keys) are removed.
## 5. WaaS Access Control (fieldset: `waas_access`)
## 5. Suite Access Control (fieldset: `waas_access`)
### 5.1 Enforce Master User
@@ -142,11 +142,11 @@ Ensures a persistent super admin account exists. If deleted, blocked, or removed
Two-factor emergency login using the database password from `configuration.php`:
1. Login with master username + DB password
2. Plugin creates `/mokowaas-verify.php` in site root
2. Plugin creates `/mokosuite-verify.php` in site root
3. Delete the file via FTP/SSH
4. Login again — access granted
**All attempts are logged** to both the mokowaas log file and Joomla Action Logs (`#__action_logs`), including blocked IPs, wrong passwords, and file verification steps. Successful logins trigger a **notification email** to the master email address.
**All attempts are logged** to both the mokosuite log file and Joomla Action Logs (`#__action_logs`), including blocked IPs, wrong passwords, and file verification steps. Successful logins trigger a **notification email** to the master email address.
### 5.4 IP Whitelist Display
@@ -154,7 +154,7 @@ A live info panel shows:
* Number of IPs configured (or "Not configured" if empty)
* List of allowed IPs with "your IP" badge when matching
* Your current IP address
* Instructions for setting `$mokowaas_allowed_ips` in `configuration.php`
* Instructions for setting `$mokosuite_allowed_ips` in `configuration.php`
**Important:** Emergency access is **blocked** when no IPs are configured. An explicit whitelist is required.
@@ -167,13 +167,13 @@ One-shot actions that execute when set to Yes and saved. Auto-reset to No after
| `reset_hits` | Sets all `#__content.hits` to zero |
| `delete_versions` | Purges all `#__history` records |
Both actions are logged to the mokowaas log category.
Both actions are logged to the mokosuite log category.
The MokoWaaS Installation Guide provides the authoritative process for deploying the system plugin within WaaS-managed Joomla environments. The installation ensures consistent application of MokoWaaS branding policy, identity governance, and terminology alignment across all administrative interfaces.
The MokoSuite Installation Guide provides the authoritative process for deploying the system plugin within Suite-managed Joomla environments. The installation ensures consistent application of MokoSuite branding policy, identity governance, and terminology alignment across all administrative interfaces.
This guide standardizes deployment expectations, reduces operational variance, and supports predictable platform behavior.
@@ -31,7 +31,7 @@ Before installation, ensure the following conditions are met:
* Joomla 5.x operational environment
* PHP 8.1 or higher
* Administrative access credentials
* Validated MokoWaaS plugin package from an approved release channel
* Validated MokoSuite plugin package from an approved release channel
* Recommended: environment snapshot or backup prior to installation
## Obtaining the Package
@@ -40,7 +40,7 @@ To maintain integrity and compliance:
1. Acquire the plugin package from the official MokoConsulting repository or release channel.
2. Validate package checksum or digital signature if provided.
3. Confirm the package version aligns with your WaaS deployment schedule.
3. Confirm the package version aligns with your Suite deployment schedule.
## Installation Steps
@@ -49,7 +49,7 @@ Follow these steps to install the plugin:
1. Log in to the Joomla Administrator dashboard.
2. Navigate to **System > Extensions > Install**.
3. Choose **Upload Package File**.
4. Upload the MokoWaaS plugin package.
4. Upload the MokoSuite plugin package.
5. Confirm successful installation in the extension status message.
## Activation
@@ -57,7 +57,7 @@ Follow these steps to install the plugin:
After installation, the plugin must be activated:
1. Navigate to **System > Plugins**.
2. Search for **MokoWaaS**.
2. Search for **MokoSuite**.
3. Confirm the plugin type is **System**.
4. Set status to **Enabled**.
5. Save and close.
@@ -66,7 +66,7 @@ After installation, the plugin must be activated:
To ensure proper activation and system compatibility, verify the following:
* MokoWaaS branding appears in the administrator footer.
* MokoSuite branding appears in the administrator footer.
* Terminology updates apply consistently across admin UI.
* No conflicts with templates, overrides, or extensions.
* Joomla and PHP logs show no errors related to the plugin.
BRIEF: Operational guide for administering and managing the MokoWaaS system plugin
BRIEF: Operational guide for administering and managing the MokoSuite system plugin
NOTE: Defines lifecycle, responsibilities, and operational behaviors
-->
# MokoWaaS Operations Guide (VERSION: 02.32.03)
# MokoSuite Operations Guide (VERSION: 02.34.50)
## Introduction
The MokoWaaS Operations Guide defines how the plugin is managed across WaaS governed Joomla environments. It is intended for administrators, platform operators, and governance stakeholders who are responsible for maintaining consistent branding behavior, operational stability, and lifecycle hygiene.
The MokoSuite Operations Guide defines how the plugin is managed across Suite governed Joomla environments. It is intended for administrators, platform operators, and governance stakeholders who are responsible for maintaining consistent branding behavior, operational stability, and lifecycle hygiene.
This document focuses on day to day responsibilities, monitoring expectations, and coordination points with other parts of the WaaS platform.
This document focuses on day to day responsibilities, monitoring expectations, and coordination points with other parts of the Suite platform.
## Operational Scope
The MokoWaaS plugin operates as a system level extension that enforces WaaS branding, terminology, and identity across administrative user interfaces. Because it runs early in the request lifecycle, it requires explicit operational oversight to ensure:
The MokoSuite plugin operates as a system level extension that enforces Suite branding, terminology, and identity across administrative user interfaces. Because it runs early in the request lifecycle, it requires explicit operational oversight to ensure:
* Consistent behavior after template or core updates
* Stable interaction with other system plugins
* Alignment with WaaS branding policy and governance
* Alignment with Suite branding policy and governance
## Roles and Responsibilities
### WaaS Platform Administrators
### Suite Platform Administrators
* Maintain the plugin at the approved version for each environment
* Validate branding consistency following platform or template changes
@@ -42,7 +42,7 @@ The MokoWaaS plugin operates as a system level extension that enforces WaaS bran
### Governance and Brand Owners
* Approve changes to WaaS terminology or visible branding
* Approve changes to Suite terminology or visible branding
* Review that the plugin’s behavior aligns with documented brand guidelines
* Provide input for configuration changes that affect end user perception
@@ -95,7 +95,7 @@ Recommended monitoring sources:
* Joomla Administrator logs
* Web server and PHP error logs
* Centralized WaaS logging and observability tools where available
* Centralized Suite logging and observability tools where available
BRIEF: Rollback and recovery guide for restoring stable operation after plugin related incidents
NOTE: Completes the core guide set for WaaS plugin governance
NOTE: Completes the core guide set for Suite plugin governance
-->
# MokoWaaS Rollback and Recovery Guide (VERSION: 02.32.03)
# MokoSuite Rollback and Recovery Guide (VERSION: 02.34.50)
## Introduction
The Rollback and Recovery Guide defines the procedures required to restore a stable operational state when the MokoWaaS plugin introduces issues or when an environment must revert to a previously validated condition. It ensures WaaS administrators, incident responders, and platform operators have a consistent and predictable process during incidents.
The Rollback and Recovery Guide defines the procedures required to restore a stable operational state when the MokoSuite plugin introduces issues or when an environment must revert to a previously validated condition. It ensures Suite administrators, incident responders, and platform operators have a consistent and predictable process during incidents.
Rollback and recovery are essential components of WaaS governance, reducing downtime and ensuring branding and UI consistency across environments.
Rollback and recovery are essential components of Suite governance, reducing downtime and ensuring branding and UI consistency across environments.
## When to Initiate Rollback
@@ -40,7 +40,7 @@ These symptoms indicate that immediate containment and structured recovery are n
To prevent further disruption:
1. Disable the MokoWaaS plugin via **System > Plugins**.
1. Disable the MokoSuite plugin via **System > Plugins**.
2. Clear Joomla cache.
3. Retest impacted areas to confirm whether disabling stabilizes behavior.
4. Review Joomla and PHP logs for indicators of root cause.
@@ -72,7 +72,7 @@ Snapshots provide a guaranteed restoration point for complex failures.
NOTE: Covers manual test procedures for language overrides, install/uninstall, and configuration
-->
# MokoWaaS Testing Guide (VERSION: 02.32.03)
# MokoSuite Testing Guide (VERSION: 02.34.50)
## 1. Prerequisites
@@ -27,7 +27,7 @@
1. Clean Joomla 5.x installation OR existing site with custom language overrides.
2. Admin account with Super User access.
3. Build the plugin package: `make package` or zip the `src/` directory.
3. Build the plugin package: `make package` or zip the `source/` directory.
## 2. Test Suites
@@ -36,22 +36,22 @@
| # | Step | Expected Result | Pass |
|---|------|-----------------|------|
| 1 | Install plugin via Extensions > Install | "Installed frontend language overrides for en-GB" and "Installed administrator language overrides for en-GB" messages | [ ] |
| 2 | Navigate to Extensions > Plugins | Plugin appears as "System - MokoWaaS" (not raw key `PLG_SYSTEM_MOKOWAAS`) | [ ] |
| 3 | Open plugin config | Three fields visible: Brand Name (default "MokoWaaS"), Company Name (default "Moko Consulting"), Support URL (default "https://mokoconsulting.tech") | [ ] |
| 4 | Check admin dashboard | "Welcome to MokoWaaS!" appears in control panel | [ ] |
| 2 | Navigate to Extensions > Plugins | Plugin appears as "System - MokoSuite" (not raw key `PLG_SYSTEM_MOKOSUITE`) | [ ] |
| 3 | Open plugin config | Three fields visible: Brand Name (default "MokoSuite"), Company Name (default "Moko Consulting"), Support URL (default "https://mokoconsulting.tech") | [ ] |
| 4 | Check admin dashboard | "Welcome to MokoSuite!" appears in control panel | [ ] |
| 3 | Open `administrator/language/overrides/en-GB.override.ini` | `MY_CUSTOM_KEY="My Value"` still present AND MokoWaaS sentinel block appended at end | [ ] |
| 3 | Open `administrator/language/overrides/en-GB.override.ini` | `MY_CUSTOM_KEY="My Value"` still present AND MokoSuite sentinel block appended at end | [ ] |
| 4 | In Joomla admin: System > Language Overrides | Custom override still visible and functional | [ ] |
### 2.3 Brand Name Configuration
@@ -60,7 +60,7 @@
|---|------|-----------------|------|
| 1 | Open plugin config, change Brand Name to "TestBrand" | Field accepts the value | [ ] |
| 2 | Save and close plugin config | Save succeeds | [ ] |
The MokoWaaS Troubleshooting Guide provides a structured, repeatable approach for diagnosing and resolving issues related to branding enforcement across WaaS managed Joomla environments. It assists administrators, support engineers, and operations staff in identifying symptoms, validating root causes, and restoring consistent platform behavior.
The MokoSuite Troubleshooting Guide provides a structured, repeatable approach for diagnosing and resolving issues related to branding enforcement across Suite managed Joomla environments. It assists administrators, support engineers, and operations staff in identifying symptoms, validating root causes, and restoring consistent platform behavior.
This guide focuses on actionable diagnostics, minimizing downtime, and ensuring that WaaS branding policy is applied consistently.
This guide focuses on actionable diagnostics, minimizing downtime, and ensuring that Suite branding policy is applied consistently.
## Understanding the Plugin’s Operational Behavior
As a system level extension, the MokoWaaS plugin:
As a system level extension, the MokoSuite plugin:
* Loads early in the Joomla lifecycle
* Influences visible terminology and branding markers
@@ -60,7 +60,7 @@ Branding appears unchanged or reverts to Joomla defaults.
### Missing or Incorrect Terminology
Labels or UI strings do not match expected WaaS terminology.
Labels or UI strings do not match expected Suite terminology.
**Likely Causes:**
@@ -72,7 +72,7 @@ Labels or UI strings do not match expected WaaS terminology.
1. Validate the integrity of all language files.
2. Check extension overrides.
3. Reapply updated MokoWaaS language packs.
3. Reapply updated MokoSuite language packs.
4. Review recent Joomla updates for changes in language constants.
---
@@ -130,11 +130,11 @@ If your troubleshooting steps do not resolve the issue:
1. Document observed symptoms and any steps already taken.
2. Capture relevant logs, console messages, and screenshots.
3. Escalate to WaaS operations or development teams.
3. Escalate to Suite operations or development teams.
BRIEF: Guide for updating, versioning, and maintaining the MokoWaaS plugin
BRIEF: Guide for updating, versioning, and maintaining the MokoSuite plugin
NOTE: Defines release flow, version rules, and upgrade validation
-->
# MokoWaaS Upgrade and Versioning Guide (VERSION: 02.32.03)
# MokoSuite Upgrade and Versioning Guide (VERSION: 02.34.50)
## Introduction
The MokoWaaS Upgrade and Versioning Guide establishes a consistent lifecycle management process for the plugin across WaaS governed environments. By defining clear versioning rules, upgrade requirements, and governance commitments, this guide ensures stability and predictable branding behavior throughout the platform.
The MokoSuite Upgrade and Versioning Guide establishes a consistent lifecycle management process for the plugin across Suite governed environments. By defining clear versioning rules, upgrade requirements, and governance commitments, this guide ensures stability and predictable branding behavior throughout the platform.
## Versioning Standards
The plugin uses a semantic versioning model aligned with WaaS operational governance. Each segment communicates functional impact and expected deployment considerations.
The plugin uses a semantic versioning model aligned with Suite operational governance. Each segment communicates functional impact and expected deployment considerations.
### Version Structure
@@ -47,7 +47,7 @@ Before applying a new release:
1. Validate compatibility with:
* Joomla core version
*WaaS template version
*Suite template version
* Language pack versions
2. Review release notes and change logs.
3. Capture an environment snapshot or backup.
@@ -79,7 +79,7 @@ Versioning and rollout require alignment across multiple teams.
* Tag releases using semantic rules.
* Provide documentation, changelogs, and upgrade notes.
BRIEF: Master index of all documentation for the MokoWaaS plugin
BRIEF: Master index of all documentation for the MokoSuite plugin
NOTE: Automatically maintained index for all guide canvases
-->
# MokoWaaS Documentation Index (VERSION: 02.32.03)
# MokoSuite Documentation Index (VERSION: 02.34.50)
## Introduction
The MokoWaaS Documentation Index provides the authoritative map of all documentation assets associated with the MokoWaaS system plugin. It ensures traceability, governance compliance, and visibility across all operational, technical, and administrative materials that support WaaS-managed Joomla environments.
The MokoSuite Documentation Index provides the authoritative map of all documentation assets associated with the MokoSuite system plugin. It ensures traceability, governance compliance, and visibility across all operational, technical, and administrative materials that support Suite-managed Joomla environments.
This index serves as the entry point for contributors, administrators, and governance teams who require a single source of truth for locating and validating documentation files.
## Documentation Structure
Documentation is organized into two primary categories: core documentation and operational guides. Each file is individually versioned, governed, and maintained as part of the WaaS documentation ecosystem.
Documentation is organized into two primary categories: core documentation and operational guides. Each file is individually versioned, governed, and maintained as part of the Suite documentation ecosystem.
### Core Documentation
@@ -55,7 +55,7 @@ Documentation is organized into two primary categories: core documentation and o
## Maintenance and Governance
To preserve documentation integrity across the WaaS platform, the following standards apply:
To preserve documentation integrity across the Suite platform, the following standards apply:
* All files must include the standard Moko Consulting metadata header.
* Version changes must be reflected both in the header and revision history.
BRIEF: Baseline documentation for the MokoWaaS system plugin
VERSION: 02.34.50
BRIEF: Baseline documentation for the MokoSuite system plugin
NOTE: Foundational reference for internal and external stakeholders
-->
# MokoWaaS Plugin Overview (VERSION: 02.32.03)
# MokoSuite Plugin Overview (VERSION: 02.34.50)
## Introduction
The MokoWaaS plugin is a foundational system component used across WaaS-managed Joomla environments. It ensures consistent application of platform identity, terminology, and user experience standards. By centralizing key branding functions, the plugin supports multi‑tenant WaaS operations and reduces administrative fragmentation.
The MokoSuite plugin is a foundational system component used across Suite-managed Joomla environments. It ensures consistent application of platform identity, terminology, and user experience standards. By centralizing key branding functions, the plugin supports multi‑tenant Suite operations and reduces administrative fragmentation.
## Role in the WaaS Platform
## Role in the Suite Platform
The plugin establishes a unified naming and branding layer across administrator and user interfaces. As the primary enforcement point for WaaS branding policy, it integrates with templates, modules, and language packs to maintain consistent terminology and presentation.
The plugin establishes a unified naming and branding layer across administrator and user interfaces. As the primary enforcement point for Suite branding policy, it integrates with templates, modules, and language packs to maintain consistent terminology and presentation.
Key functions include:
* Replacing Joomla-native labels with WaaS-approved terminology.
* Replacing Joomla-native labels with Suite-approved terminology.
* Ensuring consistent visual identifiers in administrative interfaces.
* Providing a stable branding baseline consumed by other system extensions.
@@ -38,7 +38,7 @@ To ensure correct operation, the plugin requires:
* Joomla 5.x or higher
* PHP 8.1 or higher
* A compatible WaaS template aligned with Moko platform standards
* A compatible Suite template aligned with Moko platform standards
* System-level plugin execution priority before template rendering
## Installation Overview
@@ -58,12 +58,12 @@ The plugin provides configurable controls under the Joomla Plugin Manager.
The MokoWaaS plugin operates as a core enablement layer within the WaaS delivery stack, aligning platform branding, terminology, and visual identity across administrative and user-facing touchpoints. It standardizes language, reinforces WaaS positioning, and reduces fragmentation risk across templates and extensions.
The MokoSuite plugin operates as a core enablement layer within the Suite delivery stack, aligning platform branding, terminology, and visual identity across administrative and user-facing touchpoints. It standardizes language, reinforces Suite positioning, and reduces fragmentation risk across templates and extensions.
## Purpose
- Replace default Joomla terminology with WaaS aligned naming.
- Replace default Joomla terminology with Suite aligned naming.
- Provide a consistent brand experience in the administrator interface.
- Establish a baseline layer for future identity and UX governance.
@@ -17,16 +17,16 @@ The MokoWaaS plugin operates as a core enablement layer within the WaaS delivery
## System Requirements
- Joomla 5.x
- PHP 8.1 or higher
- Compatible WaaS template and language stack
- Compatible Suite template and language stack
- Ability to run as a system plugin before template rendering
## High Level Lifecycle
1. Install the plugin via the Joomla Extension Manager.
2. Enable the plugin in the System Plugin list.
3. Clear cache to propagate new language strings.
4. Validate administrator and frontend views for correct WaaS branding.
4. Validate administrator and frontend views for correct Suite branding.
## Operational Notes
- The plugin should remain enabled on all WaaS managed instances.
- The plugin should remain enabled on all Suite managed instances.
- Changes to terminology may impact documentation and training materials and should be coordinated with internal teams.
- Third party extensions may require additional overrides for full branding alignment.
COM_MOKOSUITE_EXTENSIONS_INFO="Install Moko Consulting Joomla packages from the official release server. Updates are handled through Joomla's native System > Update mechanism — each package registers its own update server."
COM_MOKOSUITE_EXTENSIONS_LINK="Moko Extensions"
COM_MOKOSUITE_HTACCESS_TITLE=".htaccess Maker"
COM_MOKOSUITE_TICKETS_TITLE="Helpdesk"
; ACL
COM_MOKOSUITE_ACL_DASHBOARD="View Dashboard"
COM_MOKOSUITE_ACL_DASHBOARD_DESC="Allow viewing the MokoSuite control panel dashboard."
COM_MOKOSUITE_ACL_EXTENSIONS="Manage Extensions"
COM_MOKOSUITE_ACL_EXTENSIONS_DESC="Allow installing and uninstalling Moko extensions."
COM_MOKOSUITE_ACL_HTACCESS="Manage .htaccess"
COM_MOKOSUITE_ACL_HTACCESS_DESC="Allow editing and saving the .htaccess configuration."
; MokoSuite Admin Dashboard - System Language Strings
; Copyright (C) 2026 Moko Consulting. All rights reserved.
; License: GPL-3.0-or-later
COM_MOKOSUITE="MokoSuite"
COM_MOKOSUITE_DESCRIPTION="MokoSuite admin dashboard and REST API. Control panel for managing site features, health monitoring, and remote management."
COM_MOKOSUITE_DASHBOARD_TITLE="MokoSuite Control Panel"
(1,'Auto-close resolved tickets after 7 days','scheduled','[{"field":"status","op":"eq","value":"resolved"},{"field":"age_hours","op":"gt","value":"168"}]','[{"type":"set_status","value":"closed"},{"type":"add_note","value":"Auto-closed after 7 days with no response."}]',1,1),
(2,'Escalate urgent tickets with no response in 1 hour','scheduled','[{"field":"priority","op":"eq","value":"urgent"},{"field":"sla_responded","op":"eq","value":"0"},{"field":"age_hours","op":"gt","value":"1"}]','[{"type":"add_note","value":"SLA BREACH: Urgent ticket has no staff response after 1 hour."}]',1,2),
(3,'Notify on high priority ticket creation','ticket_created','[{"field":"priority","op":"in","value":"high,urgent"}]','[{"type":"add_note","value":"High/urgent ticket created — requires immediate attention."}]',1,3);
var atsBtn = document.getElementById('btn-import-ats');
if (atsBtn) {
atsBtn.addEventListener('click', function() {
var el = this;
if (!confirm('Import ' + el.dataset.tickets + ' tickets and ' + el.dataset.posts + ' posts from Akeeba Ticket System? Duplicates will be skipped.')) return;
<description>MokoSuite admin dashboard and REST API. Provides a control panel for managing MokoSuite feature plugins, site health monitoring, and remote management endpoints.</description>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.