PIR Site Health & Plugins

Status: foundation only — most plugin entries below are placeholders, not documentation yet. Started 2026-09-21 while other work was in flight; the plan is to circle back and fill each plugin entry in properly once the current queue (see pending-tasks.md, FOOTER-RECONNAISSANCE.md) isn’t more pressing. Written for the PIR tech committee — assume the reader is a new tech-com member who knows WordPress in general but not this specific site’s setup.

Why this doc exists

Both PIR WordPress sites run dozens of plugins, most installed over time by different people for reasons that live in nobody’s memory anymore. As tech-com grows, “what does this plugin actually do for us, and can I touch its settings” shouldn’t require asking around — it should be written down once, here, in plain language.

How to fill this in (for whoever picks this up)

For each plugin, replace the placeholder with:

• Purpose — what it does, one or two sentences, no marketing copy.
• How PIR actually uses it — the specific thing this plugin is doing for our sites, not its general feature list. If nobody’s sure, say so — “installed, unclear if actively used” is a valid and useful entry, better than silence.
• Config notes — anything non-default that matters (a setting that was changed on purpose, a known quirk, something that broke once and why).
• Touch with caution? — yes/no, and why, for anyone about to change its settings.

Pull real settings via emcp-tools-list-plugins (returns version/active-status for both sites) and direct DB reads (emcp-tools-query against wp_options / wp_eup8um_options, read-only) for anything the MCP tools don’t expose directly — see FOOTER-RECONNAISSANCE.md for a worked example of that technique (the Astra footer-alignment investigation).

Known site-health items already found (head start, not placeholders)

Two separate cache layers on the main site — read before touching any live content fix

Confirmed directly, 2026-09-21: W3 Total Cache (plugin-level) and a separate WPX hosting-level (XDN) cache both sit in front of the live site, and purging one does not purge the other. A W3TC “Purge All Caches” plus a hard, no-cache fetch() from the browser still served stale HTML until the WPX-level cache was separately cleared from the hosting panel. If a live edit “doesn’t seem to have worked,” check both cache layers before assuming the WordPress-side change failed. Full incident writeup: FOOTER-RECONNAISSANCE.md.

Elementor + Elementor Pro (pro-elements) update available

Main site: Elementor 4.1.1 → 4.2.4 available. Not yet evaluated for breaking changes — do not blind-update given how much of the site’s layout (footer template, homepage, meetings pages) is hand-built in Elementor with specific container IDs referenced elsewhere (see FOOTER-RECONNAISSANCE.md’s implementation-details diagrams). Worth a changelog read and a staging test before updating, not a routine “just click update.”

emcp-tools update available (3.16.0 → 3.17.0, both sites)

This is the plugin providing the MCP connection itself (Alfred’s and Littlebird’s access to both sites). Worth checking the changelog before updating, in case tool names/schemas change between versions — an update here could affect both agents’ tooling, not just site behavior.

psychedelicsinrecovery.org (main site) — plugins

(Full list via emcp-tools-list-plugins, 2026-09-21. Placeholder entries — see “How to fill this in” above.)

service.psychedelicsinrecovery.org (service site) — plugins

(Full list via emcp-tools-list-plugins on the service-site MCP connection, 2026-09-21.)

This file is a working document — update it in place as entries get filled in, don’t let it go stale the way earlier archive/index files did before the fleet started cross-checking claims against live state. See pending-tasks.md for where this sits in the current priority queue.