PHP error – DOMDocument::loadHTML():

Hey @toniko33 – thank you for reaching out!
Can you please share the PHP version you use, as well as which version of our plugin?
And does it appear on all of your sites or only on a specific one?
Thank you already a lot!

HI @ironikus – thank you for answer.

My PHP version is 7.3.24.
I use the free version of the plugin version 2.1.0.
I have only one site. And it appears on all the pages (even those without email or phone number that I also protect with your plugin) of the site.

Thank you

Hey @toniko33 – Thank you for coming back to me.
I tried to replicate the issue, but without luck – the plugin just works fine from my end.
I can also see a message within the log you sent me about the Smartslider plugin that closes an output buffer. To make sure it’s not related to any third-party plugin, can you please deactivate them and try if the issue continues to exist?
Thank you already a lot.

If you want to fix that issue temporarily, you can also turn off the attribute validation within the advanced settings (Email Encoder -> Advanced Settings -> Protect.. -> html attributes without soft encoding.)

Thank you already very much.

Hi @ironikus !

You are right. When i disable Smart slider, there is no issue !

Should i try your solution to fix the issue temporarly ?

Thank you !

Hi @toniko33

I’m Ramona from Smart Slider 3. I was able to reproduce this problem and I reported it to our developers to look into. We’ll keep you posted.

Hi @toniko33

Our developer checked the error, and here’s what he found. These errors you see are thrown by the DOMDocument class. They’re not caused by Smart Slider. The Smart Slider 3’s codes appear in the call stack because it closes the output buffer, but that shouldn’t really be relevant to the DOMDocument errors.

We suspect the reason Query Monitor reports these problems is because Smart Slider closes the output buffers, not PHP, so Query Monitor can capture these messages.

HI @nextend_ramona

Thank you for reply. Your plugin is so cool !
What does it mean for me ? Should I do something ? Or finally these errors are not very important ?

@ironikus should I apply your temporary solution as a permanent solution ? Or it’s not recommended.

Thank you both for the details

Hey @nextend_ramona – thank you for reaching out, as well as for all of your support and details.
Since we are also buffering our output, Query Monitor should also throw the errors at this point.
After investigating the issue, the only thing I can think of is a broken HTML that can’t be parsed using DOMDocument class.
While parsing, inline javascript that contains closing and opening tags, might break the logic since it doesn’t know that Javascript must be treated as a string, which leads to broken HTML entities that might cause this issue.
Since you can reproduce this issue: Can you please check if there are any scripts loaded that contain HTML tags within the inline scripts? In case there are, please also check if they are written with <!-- --> and the beginning and end. This will tell the DOM handler not only to not validate tags within the string but also allows our Email Encoder (and every other browser) to encode HTML entities within the code.

@toniko33 – in regards to your question: Using the alternative fix, our email encoder will not soft-encode emails that occur within HTML attributes (e.g. <div attribute="[email protected]">Some Text</div>). – If you know you don’t use any plugin that adds emails as an attribute (except of mailto links), you are good to go. I suggest just deactivating it and taking a look if all sites are still looking great. If that’s the case, the temporary fix can be applied permanently.

If you have any further questions, please let me know.

Hey @ironikus

Thank you for support and help !

Unfortunately, whether I check or uncheck the option “html attributes without soft encoding” the problem stays the same.

For the moment and while waiting for @nextend_ramona to look at your request, it will remain like this.

Have a great day

Hi @ironikus, @toniko33,
I checked this issue with WordPress 5.5.3 + Email Encoder 2.1.0 + Smart Slider + Query Monitor + Twenty Twenty theme.

The DOMDocument parser throws the warnings for the custom tags in this theme. If Smart Slider not activated, Query Monitor won’t show these errors as Email Encoder’s output buffer is closed after Query Monitor done with the processing. As Smart Slider closes the buffers, it results that the Email Encoder’s output processing happens right before Query Monitor, so it is able to inform you about these warnings.

In my opinion DOMDocument is not the right tool for this kind of use. As I red, it do not properly support HTML5 for example. This is why it throws these errors for valid custom tags.

The minimal effort solution would be to disable the libxml’s internal error reporting while you processing the HTML. It will properly suppress these warnings.

$dom = new DOMDocument();
$internal_errors = libxml_use_internal_errors(true);
@$dom->loadHTML($content);
libxml_use_internal_errors($internal_errors);

Hi @nextendweb @ironikus

Sorry for the delay in answering.
Thanks for the feedback.
What this means to me. Sorry, I’m not a developer.
Is it up to me to apply this patch? If so, how do I proceed ?

Thank you in advance

Hey @toniko33 – thank you for coming back to me – I’m happy to inform you that we will correct this issue from our end. There’s no further steps you have to do from here.

@nextendweb – thank you for the detailed explanation – we will take care of it from our end.

If you should have further questions, feel free to reach out at any time.

HI @ironikus

Thanks for reply.
Unfortunately, my issue is still there, with the same php error message (the one I posted in my first message).
Actually, this does not prevent the proper functioning of the site; but it still there.

Thank you for your involvement.

Hey @toniko33 – Thank you for coming back to me. Due to the complexity of it, we haven’t just involved a temporary solution, but currently working on a full integration for HTML5.
Please ignore the notices so far – you can expect a fix for that with our next version release.
In case you have any further questions, feel free to reach out again.