AstroLog PIR®
All WordPress sites entries

A fifth PIR site launches, and the events calendar's real root cause gets found

MediumWordPress sites 2 min readBy Christopher W
TL;DR: publicrelations.psychedelicsinrecovery.org is up — the fifth PIR subdomain, continuing the "every committee gets its own lightweight WordPress site" plan. Separately, we found the actual reason the events calendar could be overwhelmed by bot traffic in the first place (not just a stopgap fix), and we're working with WPX to apply the real one before bringing the calendar back.
Read the full story →

A fifth committee site

publicrelations.psychedelicsinrecovery.org joined newsletter. and publications. as the third dedicated committee portal — each a lean WordPress install a committee can manage on its own, without needing access to the main or service sites. Part of a longer-term plan to bring all of PIR’s web presence into a shared look and feel while keeping day-to-day ownership split by committee.

While setting it up, a DNS cleanup pass turned up a small inconsistency worth a mention for transparency: publications.psychedelicsinrecovery.org currently has two separate DNS records pointing at two different (but both valid) addresses — the site works correctly either way, and we’re checking with our host whether that’s intentional before touching it.

The events calendar’s real root cause

The events calendar was switched off site-wide after bot traffic was found overwhelming the server (covered in why the site got slow) — a necessary stopgap, but not a full explanation. Digging further found the actual mechanism: a caching setting that controls whether pages with a web address like ?eventDisplay=month&date=... can be cached at all was switched off sitewide. With it off, those pages — which is exactly how the calendar’s “today,” “this month,” and specific-date views work — get rebuilt from scratch on every single visit, whether that visit comes from a bot or a real person. The calendar wasn’t uniquely fragile; it just generated more of these uncacheable pages than anything else on the site.

The fix is identified (turn that setting on, so common calendar views get cached and reused instead of rebuilt every time), but the control for it is currently locked in our caching plugin’s admin screen for a reason we haven’t pinned down yet — we’re working with our hosting provider to sort that out. Once it’s resolved and tested, the plan is to bring the calendar back.