Previously on the CogitActive Saga:
I followed Gemini’s instructions […], clicked Save, flushed SiteGround’s cache, and refreshed the page. And there it was […]. It worked. The whole bonus project was now a reality — not just a theoretical detour or a clever idea scribbled in a notebook, but something tangible.
Introduction
When I first received an email from a reader (T.S.) apologizing for contacting me through my work address, I didn’t expect it to spark a months‑long project. His issue seemed trivial at first glance: he had tried to comment on a post, but the comment section had already closed 1. But that message made something clear: while posts remain accessible indefinitely (hopefully), their conversations do not. And so began what I eventually called the Bonus Project—a journey to restore the possibility of discussion, even long after a post’s publication.
This post retraces that journey—bringing together the many chapters that documented it—covering the search for a solution, the unexpected obstacles, and the final implementation of a system that allows readers to request the reopening of comments. What started as a small idea grew into a surprisingly intricate undertaking, shaped by trial, error, and more than a few detours. Today, at long last, the Bonus Project comes full circle.
How it began — a reader at the door
The Bonus Project did not start with a grand idea or a planned feature request, but with something far more ordinary: a reader who found the door closed. When T. S. reached out to me directly—bypassing the comment section entirely and apologizing for using my professional email—his/her message exposed a limitation I had long taken for granted. That message — unexpected, persistent, and oddly touching — became the seed of the Bonus Project.
His email made the consequences of that rule impossible to ignore. The post he wanted to discuss— My OneNote GTD setup 2.0—had been published months earlier, yet it continued to attract readers trying to understand or replicate my GTD setup. The content lived on, but the conversation did not. That disconnect—between enduring relevance and artificially limited dialogue—was the spark that set this entire project in motion. What I had treated as a simple anti‑spam measure had quietly become a barrier to genuine engagement.
In hindsight, the situation was almost symbolic: a reader standing at the threshold, willing to engage, but with no mechanism left to do so. He/she climbed the wall; most would not. And so the Bonus Project began as an attempt to address that imbalance—to preserve the protection against spam without silencing legitimate readers who arrive after the thirty‑day window has closed. It was a small question at first, almost trivial: could comments be reopened on demand? But as is often the case, the simplest questions lead to the most intricate investigations.
Could comments be reopened on demand?
When I first asked myself whether comments could be reopened on demand, I assumed the answer would also be straightforward. After all, WordPress lets you toggle comment status per post—how complicated could it be? As it turns out, far more complicated than expected. The thirty‑day auto‑close rule is not a simple switch but a global directive woven deep into WordPress’s discussion settings. Once that threshold is reached, the platform does more than hide the form: it updates metadata, adjusts templates, and quietly enforces closure again during its next scheduled check. Even if you reopen a post manually, WordPress will simply shut it down again the moment it performs its routine housekeeping.
Once that window passes, WordPress provides no built‑in mechanism for readers to initiate new comments on older content.
To make a long story short, after exploring several non‑solutions—including the tempting but ultimately pointless idea of simply extending the 30‑day window—I returned to a lead I had bookmarked months earlier but never properly tested. Override Comment Options, a lightweight niche plugin by Jeff Starr, offered exactly what the situation required: a way to bypass WordPress’s global auto‑close rule on a per‑post basis. No settings page, no clutter, just a single meta box that instructs WordPress to keep comments open indefinitely. It was almost suspiciously simple, but simplicity was precisely its strength. And crucially, it worked.
The plugin proved that reopening comments on demand was not only possible, but achievable without rewriting core behavior or compromising the anti‑spam safeguard. It was the first step toward a system that could restore dialogue without dismantling the protections that keep the site usable. And with this first piece in place, the path forward—toward a complete, reader‑driven reopening mechanism—finally began to take shape.
Designing a way for readers to “knock”
But unlocking a door is meaningless if no one can knock. Once I knew that comments could be reopened on demand, the next challenge became obvious: readers needed a way to ask. I needed a mechanism that would let visitors signal their interest in commenting on a closed post — a small, intentional request channel that preserved the thirty‑day rule while still allowing genuine engagement to surface. Something simple enough to use, but intentional enough to filter out noise.
The doorbell idea
How can readers request a reopening? The technical feasibility was no longer the obstacle; the challenge had shifted to workflow design. I needed a mechanism—a small, intentional signal—that would let a reader announce their presence without undermining the very safeguard that had prompted this project in the first place. In other words, if the comment section were a locked door, what I needed now was a doorbell.
The difficulty was not in imagining possible channels, but in evaluating them against the principles that guide this blog. Readers should not have to play detective, nor should they be given a tool that bypasses the thirty‑day rule entirely. Email works, but it exposes an address and risks becoming a parallel comment system. A contact form is convenient, but it creates a new communication channel rather than restoring the original one. Leaving a comment on an unrelated post is technically possible, but philosophically messy. And an automatic “reopen comments” button—no matter how tempting—would invite spam and defeat the purpose of the safeguard altogether.
What I needed was something more deliberate: a small request form placed exactly where the comment form would normally appear, requiring just enough effort to filter out bots and casual clicks, yet simple enough for any motivated reader to use. Something that preserved the integrity of the thirty‑day rule while still allowing genuine engagement to surface. Of course, turning that concept into a working prototype proved more complicated than expected.
Turning a rating plugin into a doorbell
Before I could turn the doorbell concept into something real, I needed a tool capable of powering it. A plugin? Another plugin! And here, my long‑standing philosophy — the fewer plugins, the better — shaped the search more than anything else. Months earlier, when I rebuilt my reaction buttons, I had installed TotalRating, a plugin that seemed to offer more than simple reactions. I had noticed something in it back then, a feature I couldn’t quite name but hadn’t forgotten either. Rather than explore alternatives or compare options, I simply assumed this existing tool might be able to do the job. It was far from ideal 2—it was a pragmatic shortcut, born of limited time and an overflowing to‑do list, but it was also the only lead I had.
Transforming a rating widget into a miniature request form.
TotalRating was a gamble — but it offered a hint of the required‑comment feature I needed: the ability to force a short message before submitting a rating. That single capability made it a plausible foundation for the doorbell, or at least that is what I naively thought. The reality was far less straightforward.
Finding the feature was one thing; coaxing a rating system into behaving like a request form was another. A rating widget is designed to collect stars, likes, reactions — not structured messages. It has no concept of “reopening comments,” no built‑in workflow for signaling intent. Turning it into a miniature request form would require bending it far beyond its original purpose. Enabling the “Require comment” switch was only the beginning.
A playful twist
Before any technical work, the voice came first. Inspired by Tolkien — “The way is shut…” — I shaped a heading that acknowledged the closed state of the comments without sounding dramatic or discouraging. The description beneath it went through several iterations as well: too formal, too vague, too theatrical. Eventually, I found the right balance — an invitation, not a challenge, guiding readers to explain what their future comment would be about and why it mattered. Designing the buttons proved even trickier. My first instinct was to create two options: one to keep comments shut, and one to request reopening. Each had its own tone, its own personality. But the more I tested the widget, the clearer the flaw became. A door cannot have two bells. With that breakthrough, the widget finally took shape.
A stubborn shadow
I disabled every rating‑related feature — no scores, no tallies, no results — until the widget behaved less like a rating system and more like a surrogate comment form. A rating widget, repurposed into a single‑purpose doorbell that lets readers request the reopening of comments. I thought the essential transformation was complete — still…
Visually, it needed to blend seamlessly with the existing comment workflow. I adjusted colors, spacing, and typography, removed the default background, and added custom CSS to match the surrounding elements. The only unresolved issue was a stubborn grey shadow — a grayscale filter the plugin insisted on applying to the button.
No matter what I tried, the shadow refused to fade. Or more specifically, I could not turn it into “my blue”. What should have been a trivial styling fix turned into a long chase through CSS filters and browser tools. I turned to AIs for help — confident, eloquent, and utterly wrong. Their “perfect blues” were anything but. In the end, I resorted to the only method left: slow, manual tuning. Adjusting brightness, saturation, hue‑rotate; switching from HEX to RGB; nudging values one by one while checking the result with the DevTools eyedropper. It was tedious, imprecise, and frankly a little pathetic — but it got me close. Close enough to see the blue I wanted, but not close enough to keep the text readable.
And still, I didn’t give up. A better understanding of the filter() property sparked a new attempt. For a moment, it felt like a breakthrough. But the “perfect blue” came at the cost of accessibility. In the end, I accepted the shadow. Not every battle needs to be won — especially when winning breaks accessibility. The doorbell worked, the message field worked, and the button remained readable. That was enough.
A doorbell out of place
Suddenly, a rating widget could behave like a miniature request form. The doorbell existed. It worked. It spoke. But it did not appear where or when it should. It showed up even when comments were open, and it appeared in the wrong place — embedded inside the post content instead of standing guard where the comment form should be. The metaphor collapsed. A doorbell only makes sense when the door is closed—and it must be placed at the door, not in the middle of the living room.
The plugin was behaving exactly as a reaction plugin should — rendering its widget unconditionally, oblivious to whether the comment form was open or closed. Diagnosing the situation was the easy part; accepting the implications was harder. The elegant fix, a simple conditional rule that would have displayed the widget only when comments were closed, did exist, but it lived behind a paywall. Fortunately, the plugin offered the possibility to insert the widget manually, through PHP integration — a method that would let me control both timing and placement with precision. Except… I am not a coder. I hadn’t touched PHP since the summer of 2020, back when CogitActive slipped into what I now call “survival mode,” a period in which even maintaining a weekly post felt like threading a needle in a storm. With no time to (re)learn the language, no energy for trial‑and‑error debugging, and no margin for breaking my theme, I did the one thing I keep telling myself not to do. I turned to Copilot for help — and hoped it wouldn’t lead me astray.
Time was the one resource I had none of. That’s why I turned to AIs — reluctantly — hoping for a shortcut. What I got instead was a masterclass in overconfidence. What followed was a long sequence of experiments: unsuccessful attempts, verbose non‑solutions, and suggestions that circled back on themselves like déjà‑vu. Copilot was consistently wrong. It proposed hooks that didn’t exist, conditions that couldn’t work, and PHP snippets that grew longer and more unhinged with every iteration. Its confidence made each failure more frustrating. I wasn’t just fighting PHP; I was fighting hallucinated solutions. Switching to Gemini didn’t help much. It understood the constraints better, but the loop continued.
Now, the task itself wasn’t simple to begin with. I refuse to override templates — a hard constraint born of experience, not stubbornness — which meant the usual escape hatches were off‑limits. Everything had to live in the functions.php of my child theme, cleanly, safely, and without freezing the theme in time. But the PHP challenge wasn’t just that constraint; it lay in my theme’s logic. Twenty Seventeen loads the comment template only if comments_open() || get_comments_number(). Meaning: if comments are closed and there are zero comments, the comment template never loads. The hooks never fire. Every clean solution collapsed under this condition.
“So how do you place the widget exactly where the comment form normally appears — and show it only when comments are closed — when the theme doesn’t load the comments area at all under those exact conditions?”
The very location where the doorbell must appear simply isn’t there. No hook. Nothing. In other words, the “simple” solution required threading a needle through a space that didn’t exist. No wonder the AIs kept hallucinating hooks that weren’t real and proposing template overrides I explicitly couldn’t use. The problem wasn’t just their overconfidence — the problem was that the challenge itself sat at the intersection of WordPress behavior, theme architecture, and plugin limitations. A perfect storm for confidently wrong answers.
But my own attempts weren’t much better. My first idea was to hijack the “Comments are closed.” message — to replace that line with the widget itself. It seemed clever enough: the message appears exactly where the form would be, and only when comments are closed. Except… it only appears when comments are closed AND there is at least one comment. On posts with zero comments, the message never appears at all. The perfect location vanished the moment I needed it most. Worse, I realized I had misread the logic in single.php — confusing || with && — which meant the entire approach was built on a faulty assumption. A dead end.
The second attempt was even more misguided: forcing the comment template to load by faking the comment count. If WordPress believed there was “1” comment, it would dutifully load comments.php, giving me the hook I needed. But this would have broken everything. Another collapse. And yet, somewhere in the middle of these failures, a strange idea emerged — a hack, really, but a clever one. With AI assistance, I stumbled onto a “self‑destructing” filter: a function that lies once by returning a fake comment count of 1, just long enough to trick the theme into loading the comments template. Then, the filter removes itself immediately, so the rest of the page sees the real count. This would finally expose the hook I needed — comment_form_comments_closed — the one hook that fires exactly when the form is blocked.
After weeks of circling the same dead ends with Copilot and the AI mode version of Gemini — both confidently wrong, both trapped in their own loops — I was on the verge of testing that risky hack. A workaround I didn’t trust. A lie I didn’t want to tell WordPress. I typed one last question into Gemini Flash, a final sanity check before crossing a line I wasn’t comfortable with. And then fate intervened.
After hours of conversation and the growing confidence that my self-destructive lie was not such a good idea, a login pop-up slammed into the screen, blocking everything. Annoying, but harmless — or so I thought. I logged in, expecting the conversation to resume. Instead, the entire chat vanished. Hours of work gone. The session reset to zero. A catastrophe. But also… a blessing.
Because logging in unlocked something I didn’t have before: Gemini 1.5 Pro, not Flash. Not the lightweight, confused version. A real model. A capable one. A version that didn’t hallucinate hooks, didn’t contradict itself, didn’t propose impossible conditions or irrelevant workarounds. When I pasted the lost conversation back into it — yes, I had copied everything into a Word document out of pure paranoia — Gemini Pro responded like a completely different being. No flattery. No circular logic. No invented WordPress behavior. Just reasoning.
Gemini Pro identified the real internal logic at play. It warned me about the risks of the “self‑destructing” filter and mapped out every trap the earlier models had fallen into. But more importantly, it provided the cleanest possible solution under my constraints — a surgical trick that would open the template for a millisecond and nothing more. I tested it. It worked instantly. The impossible became possible. The widget appeared exactly where it should. Months of struggle ended in a single, elegant solution — delivered not by persistence alone, but by a glitch, a pop-up, and a forced login. A divine PHP intervention indeed.
The Bonus Project complete
It took far more effort than expected, but the result is clean, stable, and fully integrated — a doorbell finally placed at the right threshold. Only when comments are closed, exactly where the comment form would normally be, without modifying theme templates, and without interfering with WordPress’s existing comment rules. No shortcuts. No lies. Just a mechanism that behaves exactly as it should.
The Bonus Project lives.
The door can be unlocked — not automatically, not carelessly, but deliberately, when someone truly has something to say. The system indeed follows a simple, deliberate rhythm. I will check the doorbell once a week, every Monday. If your request convinces me, I will reopen the comments for one week, from Monday to Monday — a fixed, intentional window. If the comments do not reopen, it means your request did not persuade me. This is not meant to be harsh; it is meant to preserve the spirit of the comments: useful, informative, and valuable for my audience. The doorbell is not a shortcut to attention — it is a signal of intent.
What began with a single reader’s determination has become a fully functional system that restores the possibility of conversation on older posts. Readers can now request that comments be reopened, and I can respond to those requests deliberately and selectively. This wasn’t just a technical fix—it was a way to preserve the spirit of discussion that this blog was built on. Posts may age, but the desire to engage with them does not. The Bonus Project was about preserving the possibility of conversation, indeed. Whether it succeeds now depends entirely on how readers use it.
The Bonus Project is complete. A closed comment section is no longer a tombstone. A reader arriving late is no longer met with silence. The door is built. The door can open again—when someone truly wishes to speak. The bell is hung. Whether it rings — that part is up to you.
1 The comment form quietly expires after 30 days, leaving no mechanism for readers to re‑engage with older content. I had enabled this behavior years ago as a practical defense against spam, never imagining it would one day become an obstacle. ^
2 When I finally returned to the plugin repository to refresh my memory, the situation was far from reassuring. TotalRating hadn’t been tested with the last three major WordPress releases, and its own website greeted me with an “Error establishing a database connection.” Every best‑practice guide warns against relying on unmaintained plugins — they drift out of sync with WordPress core, accumulate incompatibilities, and leave security holes unpatched. I know this. I’ve lived this. And yet, here I was again, staring at a plugin that hadn’t been touched in years and still considering building something on top of it. It was a decision driven not by idealism but by necessity: I simply didn’t have the time to search for a better alternative. For a proof of concept, pragmatism had to win. ^