Administrator instructions

media.hslg.uk hosts the demonstration and HSLG API separately. Keep the WordPress plugins independent. Install or update a plugin ZIP only after backing up the site and reviewing its version, compatibility, schema migration and rollback plan.

Use WP-CLI as media with --path=/home/media/public_html/ rather than manipulating WordPress post tables. The documentation publisher is a third, independent plugin; installing a new ZIP automatically publishes reviewed, namespace-owned documentation. Existing unowned pages and manually edited managed pages are protected. No routine CLI publication step is required.

Scope of this administrator role

The HSLG staging WordPress site is media.hslg.uk. It currently hosts three independent plugin responsibilities: the presentation, the application API, and documentation publication. Use the WordPress plugin management interface to install the correct reviewed ZIP; do not upload a source ZIP as though it were an installable plugin. Source archives, build dependencies, private signing keys and Gradle caches should remain outside public_html.

Install a presentation update

Confirm the installed version and the intended replacement plugin identity. Read the corresponding release report and check that it is a presenter build rather than a mobile-native artifact. WordPress may ask to replace the existing plugin with the uploaded ZIP. After replacement, reload the showcase, inspect the five venues, table-first ordering, account demonstrations, screen sizes and links. A successful install message does not prove customer flows still work; browser regression results and a staging inspection are separate evidence.

Install an API update

Treat this as a database-affecting release even if a particular change claims no migration. Back up the website and database before applying it. Review the schema and API version changes, route registrations and rollback notes. The HSLG API has separate business tables and bearer authentication; it should not replace WordPress's own users or alter other Virtualmin virtual servers. Verify health and protected endpoint behaviour against MariaDB. A plugin downgrade may not undo an additive database migration, so never assume replacing a ZIP restores all previous schema state.

Install a documentation publisher update

The documentation publisher is designed to create or update its own pages automatically during activation and newer bundle installation. Routine operation requires neither SSH nor a WP-CLI command. Pages are organized under /app/ with separate Code, Architecture, User Guide, Licensing and Disaster Recovery navigation; the complete journal is at /devlog/. After the upload, open Pages and confirm expected documents exist. Open the Revisions view for a changed page and ensure the page ID remained unchanged. Unchanged pages should not create artificial revision noise.

If an administrator manually edited an HSLG-managed page, the publisher intentionally blocks any conflicting update. Record the intended change in the canonical project documentation and ship a new bundle. Do not delete the original page and recreate it to force publication; that destroys the continuity the project needs. If an unrelated page occupies a planned slug, resolve naming/ownership explicitly rather than claiming it as HSLG documentation.

Virtualmin, Webmin and PHP safety

The server is a multi-tenant Virtualmin host. HSLG does not have permission to solve a plugin or file-upload error by globally changing all PHP services. Identify the media virtual server, its Unix user, selected PHP version and actual PHP-FPM pool before applying configuration. The previous 64M upload / 80M POST limits are an example of an approved historical per-site adjustment, not a universal system setting. Use the inventory and controlled stage script described in the Disaster Recovery page for exceptional work. Keep a rollback copy and validate the relevant FPM service.

Privacy, commercial rights and rollback

Before putting new media or SDK packages into a commercial release, check the licensing evidence register for the exact asset hash and package version. 'Downloaded from the internet' is not evidence of commercial-use permission. Keep access tokens, customer data, payment secrets and signing material out of WordPress page bodies, log exports and bug screenshots. If an update fails, first preserve the error and identify which of the three plugins changed. Roll back only the affected plugin where safe, and use the disaster-recovery procedure if data/schema damage is suspected.

Evidence to record

Capture installed plugin versions, publication page count, a changed page's stable ID and revision, and relevant screenshots. API releases additionally need migration/endpoint results. Presentation releases need browser smoke journeys. Native releases need actual APK/IPA and physical-device tests. Every new release must update the source history, licensing review and disaster-recovery review; a WordPress 'updated' notice does not replace those checks.