New 'ticketsettings' view with inline CRUD for ticket statuses
and priorities:
- Table display with color preview, default/closed flags, ordering
- Inline add/edit form with all fields
- Delete with in-use protection (can't delete if tickets reference it)
- Auto-generates alias from title
- Controller actions: saveStatus, deleteStatus, savePriority, deletePriority
- Gated by core.admin ACL
- Pass contact_id, assign_users, assign_groups, custom_fields from
controller to model on ticket creation
- Fix updateTicketStatus: getString→getInt (was passing string to int param)
- Add getBackendUsers() and getUserGroups() to TicketsModel
- Add assign users/groups multi-select fields to creation modal
New UsersController with 6 actions, all authenticated via health API token:
- POST /users/reset-passwords — reset all non-master passwords, force change
- POST /users/reset-2fa — disable 2FA/MFA for non-master users
- POST /users/disable-all — block all non-master accounts
- POST /users/enable-all — unblock all accounts
- POST /users/force-logout — terminate all active sessions
- GET /users/export — export user list with groups
Master users are always protected from mass actions.
Update catalog entry to point to the correct MokoSuiteBackup repo with
updated description and article URL. Add per-session ordering enforcement
so MokoSuite admin modules are always first in their position slot.
- Plugin params: use Extension Table::load/store instead of raw UPDATE
- Package version: use Extension Table::load instead of raw SELECT
- HTTP requests: use Joomla HttpFactory instead of curl_* functions
- All three methods now use Joomla's built-in abstractions
- onExtensionAfterInstall: immediate heartbeat after package install
- onAfterInitialise: detect version change on first admin page load,
send heartbeat if version differs from last sent, store version
in plugin params to avoid re-sending every session
Self-healing now recreates module instances via ModuleModel::save()
if they were deleted from #__modules, not just if unpublished or
missing position. Checks extension is installed before attempting.
System plugin checks mod_mokosuite_cpanel, menu, and cache on each
admin session. If unpublished, wrong position, or missing menu
mapping, auto-repairs via Joomla's ModuleModel::save(). Runs once
per session (flag in session storage) to avoid repeated DB hits.
Replace raw DB queries with Joomla's ModuleModel to properly handle
module creation, position, published state, and #__modules_menu
assignment. Fixes modules not showing after install despite being
marked as published.
Also fix cpanel default collapsed state to 0 (expanded).
Module setup methods now update position and published state on
reinstall/update instead of returning early when module exists.
Also add mokosuite_dbip to plugin enable list.
Modules: cpanel→top, menu→menu, cache→status
The system plugin is loaded before the package installer overwrites
component files, so the old code runs during install and class_exists
still fails because the autoloader has the old paths cached. Removing
the hook entirely — extension_install automation can be triggered on
next page load instead.
System plugin event handlers fire during install before com_mokosuite
is fully loaded. Guard AutomationEngine and NotificationService calls
with class_exists() to prevent fatal errors during package install.
IMAP polling scheduled task:
- Connects via php-imap, reads UNSEEN messages
- Creates tickets from new emails, matches sender to Joomla user
- Detects replies via [#123] in subject line
- Marks processed emails as seen, optionally moves to folder
- IMAP config fields in component options
Auto-close scheduled task:
- Closes resolved tickets after configurable days
- Uses autoclose_days from component params
Both registered as Joomla scheduled task types in
plg_task_mokosuite_tickets alongside existing automation task.
- onUserAfterLogin: notifies on backend admin logins with IP and username
- onUserLoginFailure: tracks failed attempts, alerts after every 3 failures
- Both use NotificationService::securityAlert (email + ntfy push)
- GET /v1/mokosuite/tickets — list with status/category/assigned filters
- GET /v1/mokosuite/tickets/{id} — single ticket with replies + attachments
- POST /v1/mokosuite/tickets — create ticket
- PATCH /v1/mokosuite/tickets/{id} — update status/priority/category/assignment
- POST /v1/mokosuite/tickets/{id}/reply — add reply with notification
- Routes registered in plg_webservices_mokosuite
- Edit existing responses via modal (click card to edit)
- Category filter dropdown in list view
- Drag-and-drop reorder with AJAX persistence
- reorderCanned controller task for ordering
- Category badges on response cards
Adds pushNtfy() alongside existing email notifications in
NotificationService. Sends push via ntfy HTTP API for ticket_created,
ticket_replied, status_changed, ticket_assigned events with emoji
tags, priority levels, and click-through URLs.
Security alerts also pushed via ntfy at priority 5 (urgent).
Configurable via component params: ntfy_enabled, ntfy_server,
ntfy_topic, ntfy_security_topic, ntfy_token.
New system plugin plg_system_mokosuite_dbip provides IP geolocation
via DB-IP MMDB databases. Supports CDN auto-download of city DB,
local MMDB file mode, and bundled MaxMind DB reader library.
Registered in package manifest.
Each installed Moko component now renders as its own top-level
collapsible section instead of being nested under a single MokoSuite
parent. com_mokosuitehq is pinned first, com_mokosuite uses static
views as children, all others auto-discover from #__menu.
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>
> 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)"
- 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.45)
# MokoSuite Operations Guide (VERSION: 02.34.83)
## 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.45)
# MokoSuite Rollback and Recovery Guide (VERSION: 02.34.83)
## 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.45)
# MokoSuite Testing Guide (VERSION: 02.34.83)
## 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.45)
# MokoSuite Upgrade and Versioning Guide (VERSION: 02.34.83)
## 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.45)
# MokoSuite Documentation Index (VERSION: 02.34.83)
## 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.83
BRIEF: Baseline documentation for the MokoSuite system plugin
NOTE: Foundational reference for internal and external stakeholders
-->
# MokoWaaS Plugin Overview (VERSION: 02.32.45)
# MokoSuite Plugin Overview (VERSION: 02.34.83)
## 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);
$db->setQuery("UPDATE {$db->quoteName('#__mokosuite_tickets')} SET status = {$db->quote($value)}, modified = {$db->quote(Factory::getDate()->toSql())} WHERE id = {$ticketId}")->execute();
}
break;
case'set_priority':
if($ticketId){
$db->setQuery("UPDATE {$db->quoteName('#__mokosuite_tickets')} SET priority = {$db->quote($value)}, modified = {$db->quote(Factory::getDate()->toSql())} WHERE id = {$ticketId}")->execute();
}
break;
case'assign':
if($ticketId){
$db->setQuery("UPDATE {$db->quoteName('#__mokosuite_tickets')} SET assigned_to = {$db->quote($value)}, modified = {$db->quote(Factory::getDate()->toSql())} WHERE id = {$ticketId}")->execute();
$db->setQuery("UPDATE {$db->quoteName('#__mokosuite_tickets')} SET status = 'closed', closed = {$db->quote(Factory::getDate()->toSql())}, modified = {$db->quote(Factory::getDate()->toSql())} WHERE id = {$ticketId}")->execute();
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.