What other plugins and theme do you use on the site?
Thanks for the reply.
Theme: Automotive By Theme Suite, Version: 11.9.8
Plugins: Numerous
Per standard practice…
- Deactivated all plugins and reverted to Twenty Twenty-One theme, and error message disappeared.
- Gradually restored all plugins, still no error.
- Restored Automotive theme, still no error.
- Reactivated page caching (via WP-Optimize), error returned.
- Deactivated page caching, no error.
- Reactivated page caching again, error returned.
Error occurs in:
/wp-content/plugins/contact-form-7/includes/js/index.js
On line 230 (via Pretty Print):
e.wpcf7.parent.querySelector('.screen-reader-response [role="status"]').innerText = '',
The querySelector returns null, so innerText throws an error.
For some reason, when page caching is turned off, this line is never called (breakpoint never reached)…
Any guess???
FYI, I have also tested the same installation, Automotive theme activated, all plugins activated, but using CF7 v.5.3.2, with page caching activated, and I do NOT get this error message:
https://dev.capitolmotors.com/contact/
Doesn’t the result mean just that WP-Optimize is causing the error?
Strictly speaking, yes, but also, why would a cached page break the plugin’s JS?
Also, same error when using WP Super Cache, which is another pretty common page caching plugin.
So far, WP Fastest Cache seems to be error free, will continue with that one for now.
Correction: WP Fastest Cache also throws the error, just not on page load as the other two do, but it does throw the same error once the “SUBMIT” button is clicked…
This is an issue, and I realize it is a conflict between plugins, but when one plugin starts conflicting with multiple plugins, the first plugin has to re-examined…
I hope I have provided enough debugging information to be helpful, but if not, happy to help some more.
Thanks.
-
This reply was modified 3 years, 1 month ago by
Aaron T. Grogg. Reason: Turns out WP Fastest Cache also breaks
The most direct cause of this TypeError is known that someone removes <p role="status" aria-live="polite" aria-atomic="true"></p> that should normally exist under <div class="screen-reader-response"></div>. I don’t know who does that and why, but from the result of your testing, it is likely to be the WP-Optimize plugin, in the case of your site.
Okay, apologies, this is NOT related to any caching plugin, but apparently the theme, and I was not seeing it earlier because, without a caching plugin, the error only appears after clicking Submit…
The difference appears to be the change from v5.3.2’s:
$( '[role="status"]', $response ).html( data.message );
to v5.4’s:
e.wpcf7.parent.querySelector('.screen-reader-response [role="status"]').innerText
As 5.3.2 uses a comma in the selector, it allows for [role="status"] to be missing, whereas 5.4 requires [role="status"] to be within .screen-reader-response.
And for some reason, when using our theme, the <p role="status" aria-live="polite" aria-atomic="true"></p> element is missing in the markup.
If you have any idea what might cause this, I would love to hear it, but if not, I will begin that investigation, and again, my apologies for wasting your time…
On the outside chance anyone else encounters this, it took a fair bit of tracking to find the culprit, but it boils down to the theme, maybe justifiably, removing empty paragraph tags, I guess trying to keep things clean?
Theme file:
/wp-content/themes/automotive/js/main.js
Line 7:
$('p:empty').remove();
I will try contacting the theme developer to ask if they can remove this in the future (though unlikely), but in the short-term, I have added a script to my template that adds a inside <p role="status" aria-live="polite" aria-atomic="true"></p> so it is no longer empty, so the theme script no longer deletes it…
Oh, really? I was almost blaming the wrong person. I have to apologize to the WP-Optimize devs.
Finally!
Thanks a bunch, Aaron. I was getting this error (ajax not working) on latests releases of CF7 en several sites, and now i see what is was causing the issue… The point is that the $(‘p:empty’).remove(); was on my own JS files (yeah, to keep things clean and avoid extra spacing on some wrong formatted -by client- texts).
Thanks again, and thanks Takayuki for such an incredible plugin.
Best regards from Madrid
Jesús
Anyone looking to keep removing empty p tags but need an exception, you can update to this:
$('p:empty:not([role])').remove()
@takayukister Because you know it’s a common issue, maybe you could just add a check before you attempt to access a property or method on a null type?
This will completely break everything if it’s null:
e.wpcf7.parent.querySelector('.screen-reader-response [role="status"]').innerText = ""
Having empty paragraph tags lingering in the markup is another issue. The reason people remove empty these tags is because they show margins, which throw off content.
A better solution would be to use a div and inject a paragragh, or just inject text into the div. That’s fine too.
Having this issue after everything got updated 🙁
We had the following built into our template. It’s a bit of a relic from days of yore when WordPress would add empty P tags in certain cases.
Removing it solved the issue.
$(‘p:empty’).remove()
Unfortunately, it’s impossible to find it in the crazy theme I’m editing 🙁 Does anyone know any other solution?
I can confirm that the removal of empty <p> tags causes this issue.
@takayukister – I’m curious, why is that empty tag needed for? Thanks.
