0 Fork 0

mirror of https://github.com/kevinveenbirkenbach/computer-playbook.git synced 2026-11-08 11:46:35 +00:00

Files

T

kevinveenbirkenbachandClaude Opus 4.7 d03db7f73e test(web-svc-css): own consumer CSS-indexing assertion + close variants/playwright gates

Adds the web-svc-css provider Playwright spec that mirrors the
dashboard/prometheus SPOT-provider pattern: emits CSS_TARGET_ROLES_JSON
via roles_with_service('css') and asserts every consumer's canonical
surface indexes a <link rel="stylesheet"> pointing at the shared CSS
asset host (CSS_BASE_URL / CDN_BASE_URL). The baseline test exercises
CDN reachability first so per-consumer failures unambiguously point
at the consumer's sys-front-inj-css wiring, not at the provider.

Suppresses the per-role playwright env-services-match guard above each
consumer's `css:` key with the canonical `# nocheck:
playwright-service-flag — verified by web-svc-css provider spec`
marker. web-svc-css/meta/services.yml gets the self-provider nocheck
on `css:` and `provider role; no consumer surface to gate` nochecks on
`cdn:` / `matomo:`.

Adds css.{enabled,shared} true/false pinning to every variants.yml
that declared the dynamic flag without coverage so
test_every_dynamic_flag_has_true_and_false_variant passes. Unifies
the css service declaration across espocrm / mediawiki / openproject
(was static enabled: false, shared: true) so the matrix matches the
rest of the consumer fleet.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-18 01:09:02 +02:00

files

refactor(playwright): centralize dashboard-tile mechanics in web-app-dashboard SPOT; move specs into files/playwright/ subdir

2026-05-16 23:24:55 +02:00

README.md

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

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