Previously on the CogitActive Saga:
And, with this, I switch the widget from Disabled to Enabled and…
“Houston, we have a problem.”
Introduction
It all started with a person who wanted to leave a comment on a post where comments were closed 1. That request was the trigger, the reason behind the bonus project, and it raised a simple question: could comments be selectively reopened when someone had a legitimate reason to contribute? That question became the opening chapter of what would unexpectedly grow into a mini‑series. From that point on, the closed comment section was treated as “the door” in the story: something that could be closed or locked. But could it be reopened?
The first question — whether WordPress could reopen comments on demand — turned out to be the simplest part of the entire project. The unlocking mechanism was there — dormant — and I didn’t need to reverse‑engineer the lock to make use of it. Actually, I didn’t even bother to pry into the mechanism itself. Thanks to a niche plugin, the technical ability to reopen comments — to unlock the door — existed out of the box, a deceptively easy first step.
But reopening a door is only half the story. A door that can be opened is still a door that looks closed from the outside. Readers had no way of knowing they could knock; that was what chapter three was about. So I went searching for a way to add a kind of doorbell — a small, unobtrusive signal that would let visitors request access without me having to keep every comment section permanently unlocked.
Then I tried to repurpose a reaction plugin into a doorbell, bending a tool built for quick emoji‑style feedback into something far more deliberate than its original design ever anticipated. To make a long story short, aside from the fun part — an opportunity to add a playful Tolkien‑inspired touch to an otherwise utilitarian feature — the whole attempt felt less like adapting a plugin and more like wrestling with one. It worked, eventually, but only after a tug‑of‑war with a system that had never been designed to behave this way. The result functioned, yes, but it was far from the effortless transformation I had imagined.
After all this groundwork, I genuinely believed the hardest part was behind me. The pieces aligned: the door could be unlocked, the bell could be rung, and the visual presentation, while imperfect 2, was at least consistent and technically sound. All that remained was to activate the widget. I switched it from Disabled to Enabled and…
What I had not anticipated, however, was that the widget appeared on posts where comments were still open, which defeated the entire purpose of my request‑only mechanism. That unexpected behavior was the source of my “Houston, we have a problem.” cliffhanger at the end of the previous post. But I soon realized that the issue was not a single malfunction but two: the widget was also not showing up exactly where the comment form would normally be 3. This chapter is about untangling those two failures and figuring out how to bring both its timing and its location under control.
Diagnosing the two issues
I had framed the above paragraph with a “What I had not anticipated,” but the truth is more nuanced. In fact, the first one — the widget appearing on posts where comments were still open — is something I should have anticipated from the start. And I certainly shouldn’t blame the plugin for behaving exactly as a reaction plugin is designed to behave. It cannot guess that I am using it as a doorbell rather than as a feedback tool, and the blame, if any, lies with me for not being smart enough to foresee that 4. As for the second issue, I was not entirely blindsided — I knew, at least in theory, that placement might become a problem — so it makes sense to begin there.
The placement constraint
I actually knew about this limitation long before the “Houston, we have a problem.” When I set the plugin’s settings, there were only two Emplacement options — “before content” and “after content” — and I even joked, Sadly, there is no ‘place it where the comment form should be’ option.
Then, when it came time to fill the Title field, which would be rendered as an H4, I explained that, unlike with my reaction buttons, where I skipped that H4 title, I didn’t mind the skipped heading level here because this time, the widget wasn’t meant to live inside the post at all. It was meant to sit exactly where the comment form would normally appear — outside the content.
The problem, of course, is that “after content” means after the post content, not after the the_content (i.e., the <article> element), where the comment section normally goes. These are two entirely different regions. The plugin was doing exactly what it had been instructed to do (hook the_content to add the widget at the end); it was my expectations that were misaligned. Fully aware that this limitation wasn’t a bug but a structural constraint of the tool I had chosen to repurpose, I selected “after content,” hoping it would be close enough, and moved on — only to discover later that this small compromise on placement would not meet my standards. My only concern back then was:
But what I really wanted to know — and what TotalRating never makes entirely clear — was where this new widget would appear in relation to my existing reaction buttons. Above? Below? Somewhere unexpected? And more importantly, would I be able to control that placement?
So, unexpected? Far from it. I knew the limitation, and yet I let it slide. But now, with the other, bigger concern in play, I can no longer look the other way.
Controlling when the widget appears
If the placement constraint was something I knew about from the start, the timing issue was the one that truly caught me off guard — or rather, the one I should have anticipated but didn’t. In hindsight, it feels almost embarrassingly obvious: a reaction plugin has no reason to check whether comments are open or closed. Its job is simple and literal. It renders its widget wherever it is instructed to render it, without attempting to interpret my intentions or the metaphor I am trying to construct.
And yet, I had assumed — somewhat wishfully — that there would be a way to display the widget only when the door was closed. That assumption was the real mistake. The entire purpose of this little “doorbell” experiment was to provide an alternative when comments were unavailable, not to clutter posts where the comment form was already present and functioning.
Now, there is a place in the plugin where this problem could have been solved elegantly — a simple conditional rule that would allow the widget to appear only when comments are closed. The WordPress plugin repository even advertises this feature explicitly: Conditional Logic: Create dynamic rating experiences with conditional rules.
In theory, that functionality should live under the Workflow tab. But, as the “part 1” in the title of this post may have already hinted, things were not going to be that straightforward. When I opened that tab, the message waiting for me was anything but welcoming:
Pro Feature
This feature is available only in TotalSuite Pro.
First, the conditional logic feature is listed on the WordPress plugin repository page for the free (or freemium) version of the plugin. Yes, there is a link to the TotalRating Pro pricing page, but the feature list itself makes no distinction between what is free and what is premium. And if I understand the repository correctly, its purpose is to catalog free and freemium plugins — that is the default expectation. Worse, the plugin’s own website states, No feature limits. Use any feature without usage restrictions, and we won’t do that, never.
A bold promise, and one that does not align with what I encountered.
So yes, the feature exists — but it sits behind a paywall. No warning on the WordPress repository, no asterisk in the feature list, no indication that “conditional logic” is premium‑only. Just a quiet upsell appearing at the exact moment when the solution seems finally within reach.
The fix is technically there. But no, I cannot use it.
Could there be a fix?
With the obvious fix locked behind a paywall, I found myself staring at the interface with a familiar mix of resignation and stubbornness. If the straightforward path was blocked, then the only reasonable next step was to look for another one — not because I expected a miracle, but because abandoning the project at this stage was not an option. I had diagnosed the issues; now I needed to examine whether the plugin offered any other mechanism that could be repurposed into a workable solution.
Until now, I had been relying on the plugin’s Auto Integrate feature. Convenient, yes — this method automatically injects the widget into the post (or the page, if you select that entity instead). But its convenience comes with two major limitations: placement is restricted to “before content” or “after content,” as explained earlier, and timing cannot be conditioned on the comment status without access to the Pro‑only conditional logic.
Auto Integrate
Automatically display the rating widget for the selected entities.
By enabling this, the widget will be displayed automatically in entities’ pages. For instance, if you choose the “post” entity, this rating widget will appear automatically below or above the content of the post.
Fortunately, the plugin does offer alternatives — three of them, in fact, and none hidden behind a paywall — each representing a different way to embed the widget manually. The first is a simple shortcode, which allows you to place the widget directly inside the post content. The second is an integration through the plugin’s REST API, giving you a programmatic way to trigger the widget wherever you see fit. And the third is a more technical option: inserting the widget via PHP, which would allow me to hook it into the theme at a specific location.
On paper, these three methods seemed promising — not because they guaranteed a solution, but because they at least offered the possibility of controlling both placement and timing. Whether any of them could actually be adapted to my “doorbell” logic was another question entirely. But after the disappointment of the Pro‑only conditional logic, simply having alternatives to examine felt like progress.
Shortcode
The first alternative is the simplest: a shortcode you can drop directly into the post content. It works with the Block Editor 5, and there is no theme editing required. In theory, this gives you precise control over placement — wherever the shortcode appears, the widget appears. But in practice, this option collapses under the weight of my requirements.
First, I would have to insert the shortcode manually into every post where comments eventually close. That alone makes it impractical. Second, and more importantly, the shortcode renders inside the content, because it is processed as part of the_content. That is not where I want the widget to appear. My “doorbell” needs to sit in the comment area, not in the middle of a paragraph or tacked onto the end of the text like an afterthought.
So while the shortcode is easy to use, it is also the first method I can confidently rule out.
REST API
The second option is to call the widget through the plugin’s REST API. This is, on paper, the most flexible approach: you can trigger the widget programmatically, load it dynamically, or integrate it into a custom block or template.
But flexibility is not the same as accessibility. I am not a developer, and the plugin’s API documentation assumes a level of JavaScript and REST familiarity that I simply do not have. Even if I were comfortable writing the necessary code, the API alone would not solve the core issue. It still needs a wrapper — something that checks the comment status and decides whether to call the API at all.
In other words, the API is powerful, but it is not a shortcut. It is a tool for someone who already knows how to build the missing logic. And that someone is not me. So the API joins the shortcode on the “not for this project” list.
PHP
The third option is to integrate the widget via PHP. This is the most technical method, but also the only one that aligns with how WordPress actually works. With PHP, I can hook into the theme at a precise location — for example, right after the comments template — and wrap the widget in my own conditional logic: if comments are closed, show the widget.
This is exactly the behavior I need. PHP gives me access to WordPress conditionals like comments_open(), lets me choose the placement independently of the content, and avoids the rigidity of Auto Integrate. It is not as convenient as clicking a checkbox, but it is the only method that offers the control required for my “doorbell” metaphor to function.
Whether I can actually make it work is another matter. I haven’t touched any PHP since 2020 — back when I was wrestling with the Protected Excerpt feature. Six years of “survival mode” already for CogitActive. Oh my!
To be continued…
1 Comments on my site close automatically after thirty days as a basic spam‑prevention measure. ^
2 The last phase was purely aesthetic — or so I thought. The plugin applies a grey shadow on the button (my doorbell) and removes it on hover (or when clicked). An aesthetic choice that I didn’t share. I wanted my button to be the same blue as I have for all my other buttons. But it was not about recoloring a button, because the button is not a button, but an icon. That battle unfolded in two rounds: the first lost to accessibility concerns, the second to stylistic constraints. In the end, the shadow remained grey, and I had to accept that some visual compromises were unavoidable. ^
3 I had envisioned the perfect solution as one where the request mechanism should live at the very spot where the closed door is felt.
In other words, exactly where the comment form would normally be.
^
4 I may have been a little harsh with myself in calling it “not smart enough.” The truth is less dramatic and far more mundane: an oversight born from accumulated strain. Weeks of pressure at work had left me mentally threadbare, the kind of chronic exhaustion that dulls even the simplest reasoning. Under that kind of cognitive fatigue, it becomes surprisingly easy to miss what should have been obvious. I am no Navy SEAL, trained to perform flawlessly under stress; I am just a person trying to keep too many plates spinning at once. In that state, even a small lapse in foresight can slip through unnoticed. ^
5 Shortcodes were extremely popular before Gutenberg, and they remain fully supported today. Shortcodes were the way to embed dynamic content inside posts and pages. They were everywhere: galleries, forms, sliders, maps, ratings, you name it. And yet, I have never used them. Gutenberg introduced blocks, which are: more visual, more structured, easier for non‑technical users, and more flexible in layout. Now, shortcodes are still used today — but their role has changed. They are no longer the preferred method. They now exist mostly for backward compatibility and plugins that haven’t built blocks. ^