computer-playbook/roles/web-app-wordpress

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

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 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.

Addons

Every plugin and mu-plugin is declared in meta/addons/ under the unified addon contract. The OIDC and WP-Discourse runtime config lives in each addon's config: block. Both install paths read those declarations: a required addon that fails to install stops the deploy, an optional one warns and is skipped.

Addon	Mechanism	Default state	Bridges
daggerhart-openid-connect-generic	plugin	enabled with the sso service	sso → web-app-keycloak
wp-discourse	plugin	enabled with the discourse service	discourse → web-app-discourse
activitypub	plugin	enabled in variant 0 (Fediverse federation); off in later variants	none
infinito-oidc-rbac-mapper	mu_plugin	required (always installed, vendored)	sso → web-app-keycloak
infinito-http-ca-trust	mu_plugin	required (always installed, vendored)	none
s3-uploads	plugin	enabled with the seaweedfs service	none
infinito-s3-uploads	mu_plugin	enabled with the seaweedfs service	none

The OIDC login + RBAC paths are covered by test-admin-oidc-login.js / test-rbac-roles.js, the Discourse round-trip by test-discourse-roundtrip.js.

Playwright service dependencies

The Playwright suite in files/playwright/playwright.spec.js gates its scenarios on the following shared services. 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. Disabling Discourse skips it; front-page reachability and CSP baselines stay active.
• seaweedfs: the media-library upload scenario in test-seaweedfs.js, which lists the role's bucket over the S3 API before and after the upload.

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
• Corporate design review: screenshots in light, dark, desktop and mobile

Persona contract opt-outs

WordPress's canonical surface is the public blog front page. The OIDC round-trip fires on /wp-login.php, which the daggerhart-openid-connect-generic addon auto-redirects to Keycloak (login_type: auto, see meta/addons/daggerhart-openid-connect-generic.yml); the shared personas enter at the site root and never visit that path. templates/playwright.env.j2 therefore declares PERSONA_BIBER_BLOCKED=true and PERSONA_ADMINISTRATOR_BLOCKED=true. The journeys themselves are not dropped: test-admin-oidc-login.js drives the admin login, logout and landing assertion, and test-rbac-roles.js drives the Keycloak-group-to-WordPress-role mapping over the same entry point.