Can closed comments in WordPress be reopened on demand?

Previously on the CogitActive Saga:
This project is not about inventing new routes; it is about reopening the original one, the comment section itself, even after the thirty‑day window has closed. But is this even possible?

Introduction

When I first floated the idea of reopening the comment section after its thirty‑day slumber, it felt almost like invoking a myth. A door that locks itself, a rule etched deep into WordPress’s machinery, a safeguard I had long accepted as immutable. “But is this even possible?” I asked—half in curiosity, half in challenge. The kind of question that seems simple until you try to answer it.

“How does one reopen comments?”

At first glance, reopening comments sounds trivial, the sort of task solved by a checkbox buried somewhere in WordPress’s settings. And yet, as I hinted in my introductory post, the matter is far from straightforward. WordPress happily lets you close comments after a set time—a sensible safeguard—but offers no obvious path to reopen them once the gate has swung shut. And so the question lingered, persistent and increasingly insistent: can that gate be opened again, not permanently, but deliberately—on demand?

Let’s step inside and see whether a closed comment section can, in fact, be coaxed back to life, on demand and on our terms.

Understanding the mechanism behind WordPress’s safeguard

Before any attempt to reopen comments can be made, the first step is to understand the mechanism that closes them. WordPress does not act on impulse; it follows rules — rules we configure, often once, then forget. The thirty‑day limit is one such rule, tucked away in the depths of the Discussion Settings, quietly doing its job long after the decision that enabled it has faded from memory. There, a single checkbox wields an outsized influence:

“Automatically close comments on posts older than X days.”

Once enabled, it becomes a global decree. WordPress does not ask which posts deserve an exception, nor does it consider whether a particular discussion still has life in it. It simply counts the days since publication and, when the threshold is reached, flips the switch without ceremony.

When the limit is reached (thirty days, in my case), the comment form disappears. The thread falls silent. Behind the scenes, WordPress updates the post’s comment_status to closed. But it does more than hide the form: it marks the post as no longer accepting new entries, adjusts its internal metadata, and alters how templates render the discussion area. The door doesn’t simply swing shut — it is deliberately latched.

A global setting applied at the database level, not per‑post.

And because the rule is global, reopening comments on a single post is not as simple as toggling a setting on that post alone 1. Even if you manually reopen it, WordPress will dutifully close it again the next time it performs its checks. This is the heart of the challenge: the closure is automatic, but the reopening is not. If WordPress is designed to close comments cleanly and permanently, can that behavior be reversed — not globally 2, not for every post, but selectively, when a reader genuinely needs the door unlocked? Remember, there is no built‑in mechanism to reopen comments automatically, temporarily, or on demand. The system assumes that if you wanted comments open, you would have left them open.

What I didn’t do (and should have)

To reopen comments on demand, one should begin with a clear understanding of what WordPress enforces, how it enforces it, and why a simple per‑post edit cannot override a global rule. Only then can one look for cracks in the mechanism — the places where an exception might slip through, where a global decree might yield to a more specific instruction. But that is not what I did.

I wish I could say I approached this challenge methodically, with time set aside and a proper plan in hand. The truth is far less elegant. Time was scarce, deadlines were loud, and the careful investigation this topic deserved simply did not happen. No step‑by‑step exploration of what WordPress exposes, what it hides, or what might be coaxed back into the light. No CogitActive principles applied; once again, they were sacrificed at the altar of work.

And yet, the bonus project has been lingering for more than half a year. The question — can comments be reopened on demand? — is not new. So how did it remain untouched for so long? Because the project waited. Patiently. Stubbornly. Through shifting seasons, through the hum of other obligations, through the quiet accumulation of tasks that always seemed more urgent. The question at its core settled like dust on a bookshelf: present, visible, but never addressed.

The truth is that when I first placed this project in my pipeline, I had already found a plugin that claimed to do exactly what I needed. Reassured that the idea was at least possible, I announced the project — and then moved on. As you may know, I am not a great fan of plugins; I prefer a line of code, a clever hook, a small, elegant solution 3. But time is not on my side. Not now. Not with work pressing hard enough to turn “The Long Walk” into “The Long Work,” or, to borrow the French title of Stephen King’s novel, “Marche ou crève” — walk or die, work or die.

So no, I did not explore code snippets promising to reopen comments programmatically. I did not test hooks that might intercept WordPress’s automatic closure, nor filters that could override the global rule on a per‑post basis. I did not dissect the aforementioned plugin to understand how it works, searching for hints of an override or a way to slip past the global decree. No reverse engineering. No additions to functions.php. Not today. Not this year. Not until the plugin fails me — as they all eventually do.

The plugin behind the promise

When I first conceived this bonus project — nine months ago now — I already had a plugin in mind (as alluded to earlier). I had stumbled upon it during an earlier bout of research, long before the project slipped into hibernation. It seemed to offer exactly what I needed: a ready‑made answer to the question of reopening comments on demand. But nine months is an eternity in the WordPress ecosystem, and I had no idea whether the plugin would still be maintained, still compatible, or even still available. So before dusting it off, I did a quick search, but Google (yep, Google, not the plugin repository, shame on me) turned up nothing useful.

WordPress is a vast ecosystem, and for nearly every limitation, someone somewhere has tried to outsmart it. But this particular challenge is niche, and plugins addressing it are not exactly legion. I don’t remember how I found this one in the first place, a plugin whose name felt almost too on‑the‑nose. A plugin that dares to override WordPress’s comment‑closing mechanism: Override Comment Options, by Jeff Starr.

Want to keep comments open on a few old posts? This plugin is for you. It does one thing and does it well: it overrides the WordPress setting, “Automatically close comments on articles older than x days”. So you can leave comments open for any individual posts that may have passed the deadline.Jeff Starr

In his article “WordPress plugin: Override Comment Options” on Perishable Press, Jeff Starr explains that he built the plugin to solve a very specific annoyance in WordPress: once the global setting “Automatically close comments on posts older than X days” is enabled, there is no native way to override it for individual posts. His plugin exists to fill exactly that gap. He describes it as intentionally minimal — around 80 lines of clean, API‑compliant code whose only job is to let you keep comments open on selected older posts. He also notes that he originally wrote it for his own site, where most posts close after 90 days, but a handful still attract meaningful discussion. Sound familiar?

When a post has passed the comment‑closing threshold, the plugin adds a small meta box to the editor sidebar; checking it forces comments to remain open indefinitely, until you uncheck it or uninstall the plugin. It has no settings page, no extra configuration, and removes all its data on uninstall. It is free, open‑source, lightweight, translation‑ready, and designed to do one thing and do it well.

On paper, it aligned perfectly with what I needed: a way to reopen the original comment section, on demand, without dismantling the spam‑protection safeguard that closes comments automatically. Naturally, I was skeptical. Plugins often promise more than they deliver, and the idea of selectively reopening comments on posts long past the thirty‑day mark felt almost too convenient. But what truly gave me pause was the 10+ active installations. Ten. Plus. I have made mistakes before by trusting plugins with numbers like that (my reaction plugin 3: emergency post comes to mind). Ten active installs are not exactly a vote of confidence.

Yet Jeff Starr is a name I’ve seen before — a reputable developer, not a random entry in the plugin directory. And the plugin had just been updated to match the latest WordPress release, which reassured me. And again, I didn’t have the time to hunt for alternatives. So I took a leap of faith.

The moment of truth

It had been so long since I last installed a plugin that I almost felt like an impostor wandering through my own dashboard. Long‑time readers know my stance on plugins: the fewer, the better. A lean WordPress is a happy WordPress. But here I was, about to break my own rule in the name of this bonus project. The first hurdle came embarrassingly early. I was staring at my blog’s admin panel, clicking around like someone who had forgotten where the light switch was in his own house. It took me a moment—longer than I care to admit—to remember that plugin management lives not in the site dashboard, but in the Network Admin. That’s how long it has been since I last tinkered with CogitActive’s underpinnings.

Once I finally reached the right place, I hit the Add Plugin button with a mix of hope and resignation. I typed “override,” expecting the plugin to appear instantly. Nothing. I added “comment.” Still nothing. Only after typing the full name—“options”—did it finally show up, buried far enough down the list that I had to scroll to find it. Not a reassuring start. Could its 0 stars and 10+ active installations be the reason it was hiding so far down? Possibly.

Normally, those are red flags I’ve learned—painfully—to respect. But this is a niche tool, after all, and niche plugins rarely enjoy the comfort of thousands of installs. And unlike the random plugins I once trusted to my detriment, this one comes from Jeff Starr, a developer whose name carries weight. The plugin had also been updated very recently, which is more than can be said for many others. And realistically, I didn’t have much choice. As I scrolled, I kept an eye out for alternatives, but nothing else even attempted to solve this particular issue. In the end, whether I liked it or not, this plugin was the only contender.

So I took a breath, ignored the warning signs, and clicked Install Now. The installation completed, the plugin appeared in the list with a description so concise it felt like a promise: “Enables override of ‘Automatically close comments on posts older than’ option in the WP Discussion Settings.” Exactly what I needed, right? There was no reason to network‑activate it—I only needed it for my blog—so I went straight to the site’s plugin page and activated it there. And… nothing exploded.

Other than the reassuring little banner—Plugin activated—and the fact that it now appeared in the list, nothing else seemed to happen. But that was expected. The plugin page had been clear enough:

For any post that is past the comment deadline, this plugin will display a small meta box on the “Edit Post” screen. There you can check the box to enable comments on the post. Comments will then remain open indefinitely, until the box is unchecked or the plugin is uninstalled.

My first stop was a recent post. Illogical, perhaps. But consider it a negative control: if the comments were still open, the plugin shouldn’t show anything. And indeed, it didn’t. No new box, no mysterious meta panel, nothing resembling the screenshots. So far, so good. Next, I headed to an older post—one whose comment section had long since vanished behind the thirty‑day wall. Before diving into the full Edit screen, I checked Quick Edit, just in case the plugin had slipped something in there. It hadn’t. A detour for nothing. Onward to the main Edit screen. And that’s when the real surprise hit.

Nothing. Absolutely nothing. No “Override Close Comment” box on the right. No meta box hiding somewhere below the fold. No trace of the plugin at all. At that moment, I could almost hear the static crackle of a failing transmission: “Houston, we have a problem.”

I told myself I wasn’t panicking. Of course, I was. Memories of The milkmaid and her pail came rushing back—the moment when a single misstep sends the whole dream crashing to the floor. Bye‑bye plugin, bye‑bye bonus project. Well… not quite bye‑bye, but the alternative would be hard‑coding a solution I absolutely did not have time for. So I forced myself to breathe, to think, to search again.

After all, the plugin’s screenshot still showed the old WordPress editor, not Gutenberg. Maybe the meta box had simply moved. Maybe it was hiding somewhere less obvious. I checked the Post tab—where I had looked first. Nothing. I checked the Block tab—obviously not. I opened the Options panel—still nothing.

Fortunately, the post I was testing was short—not one of the marathon entries I’ve inflicted on readers recently. (By the way, you can still share your thoughts on that in my poll about post length.) And so, as I scrolled down—almost by accident—I saw it. There it was. At the very bottom of the post.

Override Close Comments plugin
All right reserved

I checked the box—Leave Comments Open—and went to see the result. Nothing. I refreshed the page. Still nothing. Back to the editor. I hit Save, just as the instructions demanded. Returned to the post. Nothing. Refreshed again. Nothing. At this point, the déjà‑vu was unsettling. I opened a recent post to make sure I hadn’t somehow broken the entire comment system. Thankfully, the comments were still there, alive and well. So what was I missing?

Caching. Of course. The most annoying of invisible gremlins. I hate caching! I opened my blog on my phone, only to be greeted by a cached page so old it didn’t even show my latest post. Right—caching. But even after navigating to the post I had supposedly “fixed,” the comment section was still nowhere to be found. I went back to the editor, closed it, reopened it… and that’s when things got truly bizarre. The checkbox was unchecked. How? Why? By whom? I had no answers. I repeated the exact same steps—check the box, save, view the post—and this time, inexplicably, it worked. Still not on my phone, by the way; I really do hate caching!

Mission accomplished? Not so fast. This was only the first piece of the puzzle, the opening move in a bonus project that still had several steps ahead.

To be continued…


1 And yet, you would not believe how often this non‑solution is offered as a quick fix: Go to Posts > All Posts, hover over the title, click Quick Edit, check “Allow Comments,” and click Update. If I were to trust certain AI tools, “manually checking the ‘Allow comments’ box forces the post to remain open regardless of age.” Not even close. That box is checked on all my posts, no matter how old they are. ^
2 Another so‑called solution, often delivered with great confidence by our artificial geniuses (yes, that’s sarcasm), is to “just uncheck the box that says ‘Automatically close comments on posts older than X days.’” I am not making this up. ^
3 And no, changing the post’s publication date to today is not a clever workaround. At best, it might function as a workaround — I haven’t tested it, and frankly, I don’t intend to — but it is anything but elegant. More importantly, it goes against my principles. I have long criticized those who “update” their posts by simply bumping the publication date to game SEO. That kind of sleight of hand has no place here. No cheating on this blog. ^