kevinveenbirkenbachandClaude Opus 4.7
c2c532c8e6
Architecture
============
- New SPOT helper `roles/web-app-dashboard/files/playwright/dashboard-card-flow.js` (`runDashboardCardScenario(page, context, target)`): per `roles_with_service('dashboard')` target, asserts tile visible → click loads in `#main iframe` (outer URL gets `?iframe=` + iframe src matches canonical_domain) → header "Tab" button pops the embed into a fresh browser tab.
- `web-app-dashboard/files/playwright/playwright.spec.js` parametrised loop calls the helper for every `DASHBOARD_TARGET_ROLES_JSON` entry — the single owner of dashboard-tile mechanics across the whole codebase.
Spec relocation
===============
- 71 `roles/<role>/files/playwright.spec.js` → `roles/<role>/files/playwright/playwright.spec.js` (`git mv`, history preserved). odoo + pixelfed show as D+A in `git status` because of substantial content rewrites; coverage retained.
- New SPOT constant `ROLE_FILE_PLAYWRIGHT_SPEC` in `utils/roles/mapping.py`, registered as optional on `ROLE_TYPE_APPLICATION` (disallowed elsewhere, mirrors `ROLE_FILE_META_VARIANTS` pattern).
- `roles/test-e2e-playwright/tasks/run_one.yml`: staging task replaced with `with_fileglob` over `files/playwright/*.js` — roles can ship companion helpers (like `dashboard-card-flow.js`) next to the spec without further wiring.
Spec migrations (no more dashboard-iframe path in app specs)
============================================================
13 specs rewritten so the persona/SSO journey starts at the app URL directly, never through the dashboard tile or iframe:
* fider, mailu, mattermost, nextcloud, odoo, taiga: iframe-wrap removed (no more `frameLocator("#main iframe")`)
* bigbluebutton, discourse, kix, matrix, openwebui, peertube: dashboard goto preamble removed
* pixelfed: ~270 LOC of iframe-aware helpers/login/logout collapsed to direct-URL flow
Title cleanup
=============
- 64 specs: `"<persona>: dashboard → app → universal logout"` / `"administrator: dashboard → prometheus → app → universal logout"` → `"<persona>: app → universal logout"`.
- 13 specs: `"<persona>: dashboard to <app> ..."` → `"<persona>: <app> ..."`.
Dead-code cleanup
=================
- `dashboardBaseUrl` consts + beforeEach assertions removed from 11 specs (no functional uses; personas helper handles env validation).
- `DASHBOARD_BASE_URL=` env-template lines removed from fider, mattermost, odoo, taiga, pixelfed, kix.
- `DASHBOARD_SERVICE_ENABLED=` env-template lines removed (pixelfed retained for the still-gated spec).
- Stale "loads inside the iframe" / "FrameLocator parameter" comments cleaned in fider, odoo, prometheus, nextcloud.
Tooling
=======
- 5 lint Python files + 1 integration test now use `from utils.roles.mapping import ROLE_FILE_PLAYWRIGHT_SPEC`.
- `eslint.config.js` glob pattern + `roles/test-e2e-playwright/meta/main.yml` description + `roles/test-e2e-playwright/README.md` updated to new path.
- 25 markdown/docstring references in `docs/`, `roles/**/README.md`, `roles/**/TODO.md`, persona-helper docstrings updated to new path.
- `docs/contributing/artefact/files/role/playwright.specs.js.md`: file-placement section now documents the `files/playwright/` convention + `ROLE_FILE_PLAYWRIGHT_SPEC` SPOT constant; dashboard SPOT delegation explicit at 3 places.
Net diff: 124 files, +1142/-1564 (−422 LOC).
Integration suite: 183/183 green.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
4.6 KiB
WordPress
Description
WordPress is a versatile and widely used content management system (CMS) that powers millions of websites, from blogs and portfolios to e-commerce and corporate sites. This deployment provides a containerized WordPress instance optimized for multisite operation, advanced media management, and extensive plugin support, allowing you to fully leverage the rich features of the WordPress software.
Overview
WordPress offers an extensive array of features that make it a robust platform for building and managing digital content:
-
User-Friendly Interface: Enjoy a modern, intuitive dashboard for effortless content creation, editing, and management.
-
Customizable Themes and Plugins: Extend your site's functionality with thousands of themes and plugins, enabling you to tailor your website's look, feel, and capabilities to your exact needs.
-
Multisite Management: Easily create and maintain multiple sites with a single WordPress installation, ideal for networks of blogs, corporate intranets, or educational institutions.
-
Responsive Design: Ensure that your website looks great on all devices with mobile-friendly themes and layouts.
-
Advanced SEO Tools: Optimize your site's visibility in search engines using built-in support for SEO best practices and a rich ecosystem of SEO plugins.
-
Robust Media Management: Manage your images, videos, and other media with an integrated media library, including options for enhanced upload limits and dynamic content delivery.
-
Extensive Community and Ecosystem: Benefit from a massive community with frequent updates, security patches, and a wide range of third-party tools that continuously enhance the platform.
This automated Docker Compose deployment streamlines the process by building a custom WordPress image (which includes tools like msmtp for email delivery) and configuring the necessary PHP settings, ensuring that your WordPress site is secure, scalable, and always up to date.
Features
- Automated provisioning: Configured by Ansible without manual steps.
Purpose
The goal of this deployment is to provide a production-ready, scalable WordPress instance with multisite capabilities and enhanced performance. By automating the custom image build and configuration processes via Docker Compose and Ansible, it minimizes manual intervention, reduces errors, and allows you to concentrate on building great content.
Multisite (requirement 005)
WordPress Multisite is opt-in. Set services.wordpress.multisite.enabled: true in the inventory to convert the deployed instance into a sub-domain Multisite network. Every entry in server.domains.canonical becomes a site in the network; the first entry is the network primary, subsequent entries are child sites.
RBAC under Multisite uses the hierarchical Keycloak group path:
- Per-site role:
/roles/web-app-wordpress/<canonical-domain>/<role> - Network-wide super-admin:
/roles/web-app-wordpress/network-administrator
Operator-facing instructions for assigning these groups live in Administration RBAC. The design contract is in RBAC design.
Playwright service dependencies
The Playwright suite in files/playwright/playwright.spec.js gates its scenarios on the following shared services (requirement 006). Scenarios that depend on a service report as skipped when the corresponding <SERVICE>_SERVICE_ENABLED=false in the staged .env:
oidc: baseline admin OIDC round-trip plus the three RBAC scenarios (subscriber/editor/administrator).ldap: the three RBAC scenarios additionally depend on LDAP group sync; disabling LDAP skips them alongside OIDC.discourse: the WP->Discourse post round-trip scenario (requirement 007). Disabling Discourse skips it; front-page reachability and CSP baselines stay active.
The front-page CSP + canonical-domain baseline is ungated and always runs.
Further Resources
- WordPress Official Website
- WordPress Multisite Documentation
- WordPress Plugin Repository
- WP Discourse Plugin
Credits
Developed and maintained by Kevin Veen-Birkenbach. Learn more at veen.world. Part of the Infinito.Nexus Project. Licensed under the Infinito.Nexus Community License (Non-Commercial).