Prerequisites
Use an active account-owned PHP website, supported application capability and active MariaDB website binding. Panel account creation is not WordPress installation. Select Website Tools → WordPress Toolkit or the website Applications tab and inspect current state. A runtime/module not advertised must remain unavailable.
Detect an existing site
The supported detection route is POST /v1/websites/{id}/wordpress/detect. Inspect its durable result and detected resource association before attempting installation. Detection is not a website clone, migration or database import, and does not prove arbitrary existing installations are compatible.
Install a new site
Enter site title, WordPress administrator login/email and new private password. Either choose a verified existing same-account MariaDB user/binding or deliberately create database prerequisites through the durable database wizard. Wait for database, user and binding success independently.
The UI stages write-only WordPress material at /v1/application-secrets with account/website ownership and kind: wordpress, then stages matching database material with the reserved application ID and kind: database. It expects scoped wpcred: and dbcred: handles. The final install request goes to /v1/websites/{id}/wordpress/install; raw passwords are not placed in durable operation history. Never substitute fabricated handles or another site's binding.
Update WordPress
Select the managed application and inspect its current release/configuration and backup prerequisites. The update flow requires both require_file_backup: true and require_database_backup: true under the WordPress configuration and sends current application revision to /v1/applications/{id}/wordpress/update. A checkbox does not prove recovery; verify the actual required backup evidence and follow the durable update operation.
Verify behavior
After success, check the exact website, public content, WordPress admin login, database connectivity and applicable TLS. Confirm that another account cannot see the application or staged secrets. Keep a tested recovery path before updates. If any prerequisite job fails, retain its operation and inspect current resources before retrying; do not create duplicate users/databases to bypass an uncertain result.
Current limits
This is the source's managed WordPress workflow, not a promise of every WordPress plugin/theme compatibility. Dedicated staging environments, cloning, general website migration and cache-management menu actions are not implemented. Optional third-party installers/licenses are not bundled merely because a menu mentions application installation. Panel remains a TEST ONLY hosting candidate pending the documented native/public-service/recovery acceptance.