fix(wordpress): remove add_filter from wp-config, route xmlrpc through the gate #493

2026-08-16T20:11:40Z

claude-bot commented

2026-08-16 20:11:40 +00:00

First deploy of #492 returned 500 on every request.

PHP Fatal error: Uncaught Error: Call to undefined function add_filter()
in /var/www/html/wp-config.php(128) : eval()'d code

WORDPRESS_CONFIG_EXTRA is eval'd inside wp-config.php, which runs long before wp-settings.php loads the plugin API. add_filter() does not exist yet, so the call was fatal on every request.

Removing it exposed the worse half. The comment justified the filter by claiming xmlrpc.php was "blocked at the ingress". It was not — the public router matches / as a prefix, so xmlrpc.php was served like any other path. That claim was written without being checked, and it sat in the merged PR body too.

An Ingress has no deny verb, so xmlrpc.php now routes to the Authentik gate alongside /wp-admin and /wp-login.php: anonymous callers meet Authentik instead of the XML-RPC endpoint. Nothing here uses it — no Jetpack, no mobile app, no pingbacks worth keeping.

Verified in the live cluster (from the #492 follow-ups)

kubectl get svc -n wordpress → wordpress-mariadb exists; the hardcoded WORDPRESS_DB_HOST is correct.
kubectl get pvc -n wordpress -l app.kubernetes.io/name=wordpress,app.kubernetes.io/component=content → matches exactly wordpress-content, so Velero will not sweep the database volume. (The operator does set app.kubernetes.io/instance on its PVC, so the original exclusion would have worked — but it was an assumption, and the inclusion selector does not depend on it.)

🤖 Generated with Claude Code

https://claude.ai/code/session_014giKN9N6e5J2DF8QZmVh98

First deploy of #492 returned 500 on every request. ``` PHP Fatal error: Uncaught Error: Call to undefined function add_filter() in /var/www/html/wp-config.php(128) : eval()'d code ``` `WORDPRESS_CONFIG_EXTRA` is `eval`'d inside `wp-config.php`, which runs long before `wp-settings.php` loads the plugin API. `add_filter()` does not exist yet, so the call was fatal on every request. Removing it exposed the worse half. The comment justified the filter by claiming `xmlrpc.php` was *"blocked at the ingress"*. It was not — the public router matches `/` as a prefix, so `xmlrpc.php` was served like any other path. That claim was written without being checked, and it sat in the merged PR body too. An Ingress has no deny verb, so `xmlrpc.php` now routes to the Authentik gate alongside `/wp-admin` and `/wp-login.php`: anonymous callers meet Authentik instead of the XML-RPC endpoint. Nothing here uses it — no Jetpack, no mobile app, no pingbacks worth keeping. ## Verified in the live cluster (from the #492 follow-ups) - `kubectl get svc -n wordpress` → `wordpress-mariadb` exists; the hardcoded `WORDPRESS_DB_HOST` is correct. - `kubectl get pvc -n wordpress -l app.kubernetes.io/name=wordpress,app.kubernetes.io/component=content` → matches exactly `wordpress-content`, so Velero will not sweep the database volume. (The operator does set `app.kubernetes.io/instance` on its PVC, so the original exclusion would have worked — but it was an assumption, and the inclusion selector does not depend on it.) 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_014giKN9N6e5J2DF8QZmVh98

claude-bot added 1 commit 2026-08-16 20:11:41 +00:00

fix(wordpress): remove add_filter from wp-config, route xmlrpc through the gate

ci/woodpecker/pr/ci-manifests-test Pipeline was successful

Details

ci/woodpecker/pr/ci-scripts-test Pipeline was successful

Details

ci/woodpecker/pr/pr-review Pipeline was successful

Details

faf79549ac

The first deploy returned 500 on every request:

  PHP Fatal error: Uncaught Error: Call to undefined function add_filter()
  in /var/www/html/wp-config.php(128) : eval()'d code

WORDPRESS_CONFIG_EXTRA is eval'd inside wp-config.php, which runs long before
wp-settings.php loads the plugin API. add_filter() does not exist yet at that
point, so the call was fatal on every request.

Removing it exposed the second, worse half: the comment justified the filter by
claiming xmlrpc.php was 'blocked at the ingress'. It was not. The public router
matches '/' as a prefix, so xmlrpc.php was served like any other path — the
claim was written without being checked.

An Ingress has no deny verb, so xmlrpc.php now routes to the Authentik gate
alongside /wp-admin and /wp-login.php: anonymous callers meet Authentik instead
of the XML-RPC endpoint. Nothing on this site uses it — no Jetpack, no mobile
app, no pingbacks worth keeping.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014giKN9N6e5J2DF8QZmVh98

k.renner merged commit 8d1c4eb7ca into master

2026-08-16 20:13:32 +00:00

k.renner referenced this issue from a commit

2026-08-16 20:13:33 +00:00

Merge pull request 'fix(wordpress): remove add_filter from wp-config, route xmlrpc through the gate' (#493) from fix-wordpress-config-extra into master

review-bot reviewed

2026-08-16 20:13:48 +00:00

review-bot left a comment

🤖 Automated review — model CLI default (complexity: complex), commit faf79549acd135414a1f15bb3f9ac0bdda079d40.

Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.

Summary

Follow-up fix for the #492 regression: removes the add_filter('xmlrpc_enabled', '__return_false') call from WORDPRESS_CONFIG_EXTRA (which fataled on every request because it's eval'd before wp-settings.php loads the plugin API), and replaces the ingress-level protection it was relying on — which the PR body correctly notes never actually existed — with a real /xmlrpc.php route on the wordpress-admin Ingress, gated by the same Authentik outpost already used for /wp-admin and /wp-login.php. Both changes are small, correct, and verified against the surrounding config. No blocking issues.

🟡 Suggestions

kubernetes/apps/wordpress/ingress.yaml:79-92: The new /xmlrpc.php rule relies on Traefik's rule-length-based router priority (documented in the file header comment at lines 10-11) to win over the public Ingress's PathPrefix(/). That's the same mechanism /wp-login.php already depends on, so the pattern is proven, but it's worth a one-time check after deploy (curl -I https://www.renner.uno/xmlrpc.php should return an Authentik redirect/401, not a WordPress XML-RPC response) to confirm both Ingress objects merged as expected rather than assuming priority ordering holds.

Tests

No automated tests exist for this config (it's a GitOps manifest repo, not application code), which matches the repo's existing pattern — the PR body substitutes live-cluster verification (kubectl get svc, kubectl get pvc) from the #492 follow-up for the DB host and Velero exclusion claims, though those checks are for unrelated lines not touched by this diff. The one claim central to this diff — that xmlrpc.php was previously unprotected — is explained but not shown via a captured curl/log output; a post-deploy check as noted above would close that loop.

Recommendation

Looks reasonable — no blocking issues; comments above are optional.

🤖 **Automated review** — model `CLI default` (complexity: complex), commit `faf79549acd135414a1f15bb3f9ac0bdda079d40`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary Follow-up fix for the #492 regression: removes the `add_filter('xmlrpc_enabled', '__return_false')` call from `WORDPRESS_CONFIG_EXTRA` (which fataled on every request because it's `eval`'d before `wp-settings.php` loads the plugin API), and replaces the ingress-level protection it was relying on — which the PR body correctly notes never actually existed — with a real `/xmlrpc.php` route on the `wordpress-admin` Ingress, gated by the same Authentik outpost already used for `/wp-admin` and `/wp-login.php`. Both changes are small, correct, and verified against the surrounding config. No blocking issues. ## 🟡 Suggestions - `kubernetes/apps/wordpress/ingress.yaml:79-92`: The new `/xmlrpc.php` rule relies on Traefik's rule-length-based router priority (documented in the file header comment at lines 10-11) to win over the public Ingress's `PathPrefix(`/`)`. That's the same mechanism `/wp-login.php` already depends on, so the pattern is proven, but it's worth a one-time check after deploy (`curl -I https://www.renner.uno/xmlrpc.php` should return an Authentik redirect/401, not a WordPress XML-RPC response) to confirm both Ingress objects merged as expected rather than assuming priority ordering holds. ## Tests No automated tests exist for this config (it's a GitOps manifest repo, not application code), which matches the repo's existing pattern — the PR body substitutes live-cluster verification (`kubectl get svc`, `kubectl get pvc`) from the #492 follow-up for the DB host and Velero exclusion claims, though those checks are for unrelated lines not touched by this diff. The one claim central to *this* diff — that `xmlrpc.php` was previously unprotected — is explained but not shown via a captured `curl`/log output; a post-deploy check as noted above would close that loop. ## Recommendation Looks reasonable — no blocking issues; comments above are optional.

claude-bot referenced this pull request

2026-08-16 20:22:50 +00:00

fix(wordpress): route the outpost OAuth path so the gate is a gate, not a dead end #494

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: konairius/homelab#493