Previously on the CogitActive Saga:
But while that part was easy, figuring out what changed—not in my template, but within WordPress itself—and understanding why this <div> made the difference was an entirely different story. Or two, actually!
For years, I relied on a simple yet effective method to protect my images from casual theft. By overlaying a transparent image atop the original, I made right-click saving impossible—an elegant workaround that seamlessly integrated into my blogging workflow. Implemented through CSS and structured within a reusable WordPress block, this system worked flawlessly, deterring unauthorized use without interfering with accessibility or usability. It was a quiet safeguard, unnoticed by readers yet essential to preserving my content.
That was until one day when I stumbled upon a strange issue—one that would soon unravel into something far more significant. As detailed in the first installment of this story, I discovered that my transparent overlay wasn’t just preventing unauthorized image downloads—it was blocking text selection, tooltips, and even internal links across multiple posts. At first, I dismissed it as a browser quirk, a temporary glitch, something that would resolve itself. But as I dug deeper, it became clear—this wasn’t an isolated problem. My protection method had gone rogue, affecting usability in ways I had never anticipated. The fix seemed simple enough—adjusting the HTML structure to restore proper functionality—but patching the problem alone wasn’t enough. I needed to understand why it had happened in the first place.
The issue was fixed—but something still didn’t add up. Now, it’s time to dig deeper. What changed? And why?
Uncovering the turning point
Up until August 2022 (or possibly earlier—my limited use of images made an exact timeline tricky), my protection worked as intended. The last post with such properly working protection was published in April 2022. I now had a timeframe. Somewhere between those dates, something had shifted—and it wasn’t me, since I had been using the same template all along. The answer had to lie in WordPress itself. To confirm, I checked the WordPress update log, cross-referencing release dates with my timeline. And there it was—WordPress 6.0, released in May 2022.
Historically, the image block with left, right or center alignments used to have an extra div wrapper around the figure tag to help with alignment styling. In WordPress 6.0, for themes that support the layout feature, this wrapper has been removed.Riad Benguella
The goal was to simplify markup and make block alignments more consistent across different elements. By moving all classes directly to the <figure> tag, WordPress ensured that the markup for images matched the frontend output more precisely, reducing unnecessary wrappers and improving styling flexibility.
A subtle tweak, easy to overlook—until it caused unexpected consequences.
With the culprit identified, the next challenge was understanding why this change had disrupted the overlay’s behavior.
A workaround, not the solution
While I could have left it at that, simply patching things up and moving on, that’s not how I approach things. Fixing a bug is one thing, but understanding why it happened is just as important. Grasping the reasoning behind WordPress’s change was as crucial as resolving the issue itself. Equally crucial was ensuring that my fix wasn’t merely a quick workaround, but a true improvement—one that aligned with best practices rather than resisting progress. If WordPress had adjusted its code structure, there was likely a valid reason for it.
In other words, reverting my implementation to its old form just to make things work again wasn’t necessarily the smartest approach. Instead, staying true to CogitActive’s principles—and my ongoing commitment to usability and accessibility—I aimed to refine my solution properly. That meant diving deeper, exploring the mechanics behind the change, and developing a method that adhered to best practices. But time, as always, was in short supply. So, to ensure precision and clarity in this pursuit, I turned to my trusted editor—Copilot—who usually remains behind the scenes, quietly refining my words.
Copilot to the rescue—Or was it?
From experience, I’ve learned that blindly trusting AI is never a wise approach. While I rely on Copilot for refining my English—albeit with a careful eye to review and tweak behind him—when it comes to code, my trust is far more reserved. Beyond the well-documented issue of AI hallucinations, I’ve discovered that these systems aren’t always as intelligent as they appear. Of course, the quality of the prompt plays a role—garbage in, garbage out—but even with careful phrasing, AI reasoning can sometimes falter.
Given my limited expertise in HTML and CSS, I decided to run a little experiment before taking Copilot’s advice at face value. Instead of assuming that its guidance would be foolproof, I wanted to test its capabilities first. Would it provide an elegant solution, or expose its own shortcomings? I structured my experiment in two simple steps: first, assess whether Copilot could correctly interpret the purpose of my code—an easy test; then, determine whether it could identify the underlying bug.
“I’ll share some code with you—CSS followed by HTML. Can you analyze it and explain its intended purpose?”
Copilot correctly identified the purpose of the code—it overlays a secondary image (likely a watermark or copyright notice) on top of a primary image to deter unauthorized use. It explained the mechanism behind the setup and confirmed that the overlay ensures protection by preventing simple right-click saving.
“Well done—this code is indeed designed to protect my images from being easily saved via right-click. However, there’s a bug—something doesn’t quite align with your statement: ‘This makes the protection image cover the entire area of the containing <div>, aligning it exactly over the primary content.’ Can you identify what’s wrong and explain why it’s happening?”
Copilot responded with its analysis of the problem. The overlay wasn’t aligned perfectly with the primary image because the image was wrapped inside a <figure> element, which browsers and WordPress styles often modify with extra margins, padding, or spacing. This causes the protection image to extend beyond or fall short of its intended coverage. To remedy this, Copilot suggested two possible solutions: either eliminate the unwanted spacing by adjusting the <figure> styling or reposition the overlay inside the <figure> itself, ensuring a direct overlay on the image without interference from surrounding elements.
“Almost.”
Thirteen exchanges, thousands of words, and multiple failed attempts—yet the bug remained unfixed. Every response seemed promising, every adjustment a potential breakthrough. Yet none addressed the core issue. I repeated explanations, refined my wording, and tried to steer Copilot in the right direction. But no matter how many times I gave it more information, it kept misdiagnosing the problem. I wasn’t debugging anymore—I was chasing bad advice.
Copilot confidently proposed fixes that simply didn’t work.
Blind trust in AI can lead to wasted time, incorrect assumptions, and ultimately, disappointment. And after hours of debugging and frustration, that’s exactly what happened—I wasted my time!
What about Gemini?
Clearly, the lesson hadn’t sunk in. Instead of accepting defeat and diving into HTML and CSS myself, I turned to another AI—Gemini. If Copilot couldn’t solve it, perhaps Gemini would crack the mystery where its rival had failed. Hoping for a miracle, maybe.
Gemini started strong, correctly identifying the purpose of the code: overlaying a copyrighted image with a watermark for protection. It provided a detailed explanation of how the CSS and HTML worked together, mirroring the logic Copilot had previously outlined. However, just like Copilot, Gemini faltered when diagnosing the bug. Its proposed fixes—nesting the protection image inside <figure> or adjusting the <figure> styling—were nearly identical to those Copilot had suggested earlier. And, just as before, these solutions did not work.
You’ve provided crucial information that narrows down the exact cause of the bug! The fact that the protection image is sizing to 502.18 x 502.18 px while the main image is 502.18 x 118.23 px clearly indicates that the height of the .first container is the problem.Gemini
Unlike Copilot, however, Gemini ultimately identified the root cause of the bug—but only after I provided additional details (just as I had with Copilot, but without success). Once armed with this crucial information, it adjusted its approach and correctly pinpointed the real issue: the .first container was failing to inherit its height from the image it was meant to overlay. This was a step forward compared to Copilot’s failed attempts. Yet, just like Copilot, Gemini confidently proposed fixes that simply didn’t work—again!
At this stage, I shared my workaround code, asking Gemini to analyze why it worked and whether it could be improved. Gemini quickly recognized that introducing an intermediary <div> allowed .first to correctly derive its height from the image, effectively resolving the misalignment problem. However, it also cautioned that while my solution functioned as expected, it wasn’t the most semantically ideal or robust in terms of CSS.
To be continued…