Skip to content

Latest commit

 

History

History
116 lines (77 loc) · 22.9 KB

agent-guide.md

File metadata and controls

116 lines (77 loc) · 22.9 KB

JoomEngine Playground: guide for people and agents

JoomEngine Playground is a browser-based workspace for creating, testing and improving Joomla extensions with Joomla Component Builder (JCB). It runs Joomla, PHP and MariaDB in browser workers. Use your browser controls to configure a site, work in Joomla and JCB, edit files, compile a component, install it, test its behavior and download the results. This guide gives people and browser agents a practical route through those tasks and links to the detailed JCB model documentation.

How to operate the browser

  1. Open the Playground URL and inspect the visible controls. The outer page is Rocket; Joomla runs in its site preview. Open the preview or its iframe with your browser tool and use the visible Joomla administrator interface for JCB actions.
  2. Wait for launch and page navigation to finish, then inspect the resulting page before choosing the next control. When a page or dialog changes, use its current labels and fields; JCB layouts can vary with the installed version. If a control is outside the visible part of the frame, scroll it into view or use keyboard focus and verify the result.
  3. Use Rocket for site configuration, saving, downloading and opening JoomEngine Code. Use Joomla's administrator for extension installation and JCB records. Keep the Playground tab open while working with the site.
  4. Preserve evidence as you go: record versions and source revisions, inspect saved records after changes, and retain downloaded files when the task calls for them. Review and use any browser-tool-supported file upload/download workflow to transfer packages.

Start here

  1. Open Playground with setup shown. In Deployment, choose the deployment, Joomla version, JCB version and PHP runtime, then inspect any other settings. The source catalog records the pinned defaults. The version selectors read the current published catalog of stable, nightly and upcoming releases. Choose a listed compatible combination; check the selectors again after a new catalog is published when the target version changes.
  2. Decide whether the work needs a temporary site or a saved site. For independent clean testing, open Configure deployment and choose Use this deployment, or use fresh=1; the latter also bypasses prepared snapshots and builds the chosen recipe. Launch, wait for provisioning and the actual Joomla/JCB page, and note the effective versions. A normal visit may instead reopen the last used saved site.
  3. Record the Joomla, PHP and installed JCB versions, deployment, browser, candidate repository/branch/commit and relevant package checksums. An existing saved site may contain an older JCB than the current default. Prepared installations are pinned and are not automatic latest-version downloads.
  4. To build or test JCB models, follow the JoomEngine JCB skill router, its agent operating contract, and the relevant model workflow linked below. Then test the actual compiled and installed consumer, not just the import.
  5. Save useful work in the running site and Download a complete backup when needed. Report the separate results of acquisition, compilation, installation and runtime testing, including anything blocked or not run.

Choose and configure a site

Choose Joomla, JCB and PHP on the main dashboard. Rocket's Deployment editor offers the same deployment list, plus the site name, administrator, login behavior, packages, languages, menus, template and content. Basic fields and advanced JSON edit the same values. Use the Site and Admin controls to navigate the already-running preview. Credentials displays the site's administrator details.

  • JCB and JCB + MCP require a compatible JCB version. Other deployments allow None or an additional compatible JCB package. Deployment requirements disable unsupported Joomla and PHP choices. See the deployment guide.
  • Selecting a deployment fills its setup fields. Save keeps a named custom recipe in this browser and adds it to both deployment lists. Changes to a built-in save as a Custom copy. Save as copy creates another recipe; Delete removes custom recipes without deleting existing sites.
  • Changes are staged and validated at launch. Changing the Joomla release or deployment selects a separate profile; it does not upgrade the Joomla installation in an existing site. Supported PHP changes preserve its files and database, but still record the effective PHP version and settings.
  • ?start=0 suppresses the startup countdown so configuration can be reviewed. Other supported URL parameters include deploy, joomla, jcb, php, path, persist, fresh, language, login, extensions, commands, and config. Values are validated against available catalog entries. The URL reference explains syntax and precedence.
  • A Joomla path and its query string must be encoded as one path value. For example, /administrator/index.php?option=com_componentbuilder&view=compiler becomes path=%2Fadministrator%2Findex.php%3Foption%3Dcom_componentbuilder%26view%3Dcompiler. The path chooses a screen, not a repository branch or a tested candidate.
  • Use starts an independent deployment using the edited configuration. Apply to this site checkpoints and applies supported changes to the running site; review packages and commands first. Removing a package from configuration does not uninstall it. Failed application offers recovery from its checkpoint as a separate site.
  • Startup commands are arrays of Joomla CLI arguments, for example [["cache:clean"]]; they are not host shell commands. They run after package installation, and a completed site's original commands are not replayed on reopen.

Export configuration downloads the complete version 2 recipe, including its name, requirements and administrator details. Import configuration adds it as a named custom deployment. Share creates a password-free version 1 link for an independent installation. Neither carries the site's files or database. Links are limited to 16 KiB and JSON documents to 1 MiB. See the deployment document guide.

Choose releases, prereleases and nightly builds

Choose Joomla first. PHP choices follow that release's requirements and the available browser runtimes. The list contains Joomla 5, 6 and 7, beginning with the latest stable of each available major. Current stable choices appear first, followed by Nightly builds and Upcoming releases. There is one current nightly per active development line and only the newest alpha, beta or RC for each future release. Joomla 4 and outdated releases are excluded.

The JCB list follows the Joomla major version and shows only current stable and forward versions from JCB 5 onwards. Joomla 5 uses JCB 5, Joomla 6 uses JCB 6, and Joomla 7 can use JCB 6 for experimental forward testing until JCB 7 is available. Choose the versions, then launch: the Playground automatically fetches its staged packages and installs them. Selecting a listed version does not require downloading a ZIP to the computer or adding it back through a file picker.

Package discovery happens during the static-site build. Joomla discovery follows the official next patch, next minor and next major lists to their extension feeds, selecting Full Package ZIPs for new installations. JCB discovery reads only the 6.x and 5.x update manifests. A single recent Joomla release query, limited to 100 records, supplies stable and published preview releases absent from the nightly feeds. The build does not enumerate JCB branches or tags or scan old release pages.

The build verifies published SHA-256 or SHA-512 checksums and gives packages without a published full-ZIP checksum a SHA-256 content fingerprint. It stages the packages on the Playground origin with assets/version-catalog.json; the catalog's generatedAt identifies the build time. The selectors refresh this published catalog when opened and periodically while setup is visible. This refresh does not contact upstream package hosts. Pages rebuilds the catalog daily at 03:15 UTC and on changes to main, then runs the same validation and installation gates before publishing. Failed discovery, downloads or validation leave the previous deployed catalog intact.

A saved selection can remain visible under Saved version after it drops from the current list. Saved and shared configurations retain the selected package identity and hash; reopening an existing site does not replace its installed Joomla or JCB. Use Configure deployment → Use this deployment to test a new nightly and keep a complete site export when retaining that exact build matters. Prepared copies are used only for matching pinned selections; other catalog choices install from their staged packages.

Install another Joomla extension

In Deployment → Extension packages, paste the package ZIP URL and add rows for further packages. The advanced JSON editor accepts objects with a url; user-supplied checksum fields are ignored. Choose Use for a new site or Apply to this site for the current site. Rocket passes each custom URL to Joomla's extension:install --url=URL command for download and installation. The running Joomla administrator also provides its normal extension installer.

Extension and template URLs support HTTP and HTTPS. If a custom package fails, its installer error remains available while the site opens, and it can be retried in Joomla. Core deployment packages remain required. PHP's HTTP transport follows the browser's CORS and mixed-content rules; the error details identify the failed operation.

Understand JCB's sources and results

JCB uses authoring records and linked models to generate Joomla extensions. A component blueprint may include views, fields, permissions, code, assets and references to reusable dependencies. The precise structure and serialization depend on the model and JCB revision. Do not treat one JSON file, a compiled extension ZIP or installed PHP files as the complete editable blueprint. The JCB architecture publication and model router provide the conceptual and field-specific detail.

Use the complete JoomEngine Skills distribution and select the task-specific entry point:

Work Read first Important distinction
Component, module or plugin blueprint Packages skill and model contracts A package is a graph of records, dependencies and assets. Identity and encoding differ by model.
Reusable PHP class/interface/trait Super Powers skill settings.json and code.power are import inputs; preserve existing identities and keep derived files/index consistent.
Field Type catalog Field Types skill A Field Type is reusable metadata; a concrete Field is a separate JCB authoring record.
Reusable view source Snippets skill A snippet is copied into a consumer; updating its catalog does not automatically rewrite previously copied content.
Import, compile and exercise any model Playground integration workflow Record acquisition, persisted records, compilation, installation and runtime checks separately.
Create a blueprint in JCB and export its source GUI authoring and export JCB source Push is different from downloading a compiled component ZIP.

These are the AI-oriented operational docs for JCB; load their linked references and source evidence as required. Consult the loading guide when supplying a complete portable skill distribution to an agent. Check current documentation and target source revisions, because fields and supported versions can change.

For machine-readable architecture documentation, start with llms.txt, the article index, or the complete Markdown download. The architecture skill references explain how to navigate these resources. For human-oriented tutorials, see the JCB documentation index.

Build or test a JCB model

  1. Identify the task, authorized source repository, target Joomla/JCB/PHP versions, model and dependencies. Read the matching skill, contract and workflow above. Perform its source validation and identity/collision checks. Record the exact candidate commit; a branch name alone can move.
  2. Start a suitable independent JCB site. In the administrator preview open Component Builder → Repositories. Inspect existing entries, then add or enable the candidate and needed dependencies. Set the content target to Super Power (1), Joomla Power (2), Field Types (3), Packages (4), Snippets (5), or the separate Repositories catalogue (6); select the GitHub or Gitea provider, enter the host, organization and repository, and set the read branch to the candidate branch. Save and check enabled state, repository order and the effective source including fallbacks. The deployment URL does not set the JCB read branch. Record the exact commit and selected source, without exposing credentials.
  3. In the relevant JCB list, use the supported Init, Pull or Reset flow for the installed version. Init may preserve an already-local item; a selection page or success notification alone does not prove that candidate data was loaded. Reset can overwrite local changes. Save/reopen and inspect the relevant identity, content and dependencies. JCB's entity Reset is distinct from Playground's site Reset.
  4. Build a real consumer. For a basic component, create Fields with the desired Field Types and data/storage settings, create an Admin View, attach those Fields in its field association editor, then create a Joomla Component and attach the Admin View through its component association editor. Add needed site views, permissions, code, assets and dependencies. For a Power, reference it from an actual caller; for a Snippet, copy it into an attached view. Save and reopen each record and association to check persistence. Use the relevant model workflow for the exact settings and acceptance cases.
  5. Open JCB's compiler, select the actual component and target, compile, and inspect messages. Use Download Component to retain the resulting ZIP, inspect its generated files and record a hash when possible. The generated extension ZIP is not the same thing as a portable JCB source repository or a full site backup.
  6. Install the package in a compatible disposable Joomla site using an available supported package upload or URL flow. Exercise the relevant admin/frontend behavior and boundaries, verify saved data, and inspect generated/installed files where relevant. A successful import, compile or ZIP alone does not establish correct installed behavior.
  7. If Code reveals a defect, use edits there as diagnostics; carry lasting changes back to the authoritative repository, JCB authoring records or compiler source as appropriate, then reimport/refresh, recompile, reinstall and retest. If a stage is unavailable, state exactly what was blocked and why.

To export reusable blueprint source, open Repositories, configure the authorized Packages destination and its write branch, and inspect all effective writable Packages connections before continuing. In Joomla Components, select the component and choose Push. Inspect every result, then compare the remote branch before and after for the complete records, indexes and assets. Open a fresh JCB site, configure that branch as the read source, acquire the root and its dependencies, then compile and test again. Follow the detailed authoring, Push and read-back procedure; the selected component does not by itself restrict Push to one destination. The compiled extension ZIP and the blueprint source export are separate deliverables.

Inspect files and debug

Open JoomEngine Code from the Playground header. Its workspace is the active site's Joomla document root, /persist/www. Browse, search, open and edit available site files; use editor Save or Save All before checking behavior, and Refresh site when a preview reload is required. Code's workspace is not automatically a checkout of the model repository, and editing installed files does not update JCB records held in the database. Playground Save is a separate operation that persists site files and database.

For a PHP problem, set a breakpoint in executable source and use Debug and refresh for the current GET, or Arm PHP request with the exact URL, query and method before the relevant form/navigation. Inspect the stack and variables and continue/step. Debugger expression evaluation can have side effects. While a request is paused, other requests and source saves can queue; continue or stop before waiting on them. Stopping a request does not roll back database writes already completed. See the Code user guide and debugger notes.

The optional in-product AI Assistant can propose file changes using bounded context for review. Local editing and debugging do not require an AI key. A configured provider must support the browser connection, including its CORS restrictions; provider presets and protocol fixtures alone do not establish live account compatibility. Review changes and sensitive context before sending or accepting. Its capabilities are separate from those of an external agent. See AI validation.

Save, download and move work

Action What it does
Editor Save Writes a file to the active virtual site. Unsaved editor buffers are not portable exports.
Playground Save Flushes site files and database to browser storage. Wait for success; browser storage can be cleared or evicted and is not a backup.
Deployment editor Save Stores a named custom recipe in this browser; built-in deployments remain unchanged.
Export / Import configuration Transfers the complete version 2 recipe, including administrator details; it does not transfer site files or the database.
Share Recreates an independent installation from password-free public configuration.
Deployment images Lists reusable browser images and removes selected images without deleting saved sites.
Download complete site Includes the installed files, database, runtime configuration, opening page and known sandbox administrator in a portable ZIP.
Upload Restores that complete ZIP as an independent saved site without replaying installation commands.
Files-only / SQL-only Download Exports only that part; neither alone is a complete movable site.
JCB Download Component Downloads the compiled Joomla extension; it is distinct from the site archive and editable blueprint source.

For conventional Joomla hosting, follow the complete archive's DEPLOYMENT.md: provision compatible PHP/MariaDB, upload the files, import SQL, configure the destination database and paths, and verify login. The export contains portable placeholder database settings. Complete site downloads retain the Joomla account records and known sandbox login in export.json; browser sessions are excluded.

To move the installed site within Playground, use Download → Complete site, then Upload. It restores the edited files, database, configuration, known credentials and opening page under a new saved-site identity. Upload validates the payload hash when present; older complete exports without it remain supported with a short notice. Share and Import configuration recreate deployment instructions and do not carry edited files or database content. See the export and lifecycle reference.

Closing a temporary site discards its state after confirmation. Restart preserves current site data. Reset deletes the selected site's files and database; preserve needed evidence first. Recover saved site can offer backup/recovery without booting Joomla, but a files-only recovery from a failed database contains no SQL and may include private settings. Only one tab can own a particular saved site at once.

Report a result another person can reproduce

Include the task and expected behavior; Playground build/revision if available; Joomla, PHP, installed JCB, deployment, browser and source repository/branch/commit; dependency sources and effective precedence; exact setup and actions; observed results; errors; generated package hash and relevant files; and a clear status for each of source validation, acquisition, record inspection, compilation, installation and runtime testing. Include separate native-server testing where required. Preserve a sanitized reproduction and relevant artifacts without credentials, personal data or private site archives.

Use the skills repository's verification workflow and issue-reporting guidance. Historical validation is useful background, but it is not proof that the current candidate passed. Do not claim a stage passed unless it was actually performed.