Implemented ochri error in Hikashop login and more

Hi Ruud,

I have a site with hikashop installed. When checking out of the cart if I login in with a working user profile, or submit a coupon code (I have only tried non-existing codes) I get this error on the screen:

0: DOMDocument::loadHTML(): Argument #1 ($source) must not be empty

It corresponds to this error in the logs:

File: /home/[myaccount]/public_html/stageit/plugins/system/ochresponsiveimages/helpers/responsiveimages.php
Line: 331
Error: DOMDocument::loadHTML(): Argument #1 ($source) must not be empty

Here is a video showing the issue and also the login info for troubleshooting and remember it is a staging site so no worries about playing around with things.



Thanks!

Tim

 

Good morning Tim,

thanks for reaching out and bringing this to my attention.
I have found the 'issue': you have configured in advanced setting 'Clean HTML' = Yes. This uses the DOM to search and replace the images. But it can also wreck havoc when the HTML it receives to parse has errors in it.

This turns out to be the issue:
ochResponsive images runs on the Joomla Core event: onAfterRender(), it expects a rendered page: a page holding the HTML for the rendered page.

Now what happens is that with HikaShop / the coupon code, the onAfterRender() is triggered with NO HTML content (which makes absolutely no sense to me: why render 'nothing')
This results in ochResponsiveImages trying to query the DOM where the DOM is actually empty / non-existing.

So the quick work-around here is to disable clean HTML in advanced setting
The 'fix' here is to have ochResponseImages check if onAfterRender is having an actual page rendered (so not empty). I have implemented this fix on your statig site for you to test.

As your provided FTP credentials didn't work (the server blocked my IP so I was unable to connect), I needed to install ochLogFiles to see the log files for ohResponsiveImages.
I needed to change your sites global log path as that was pointing to a non existing site / directory (it was: ..../public_html/administrator/stageit/logs where it should be ..../public_html/stageit/administrator/logs)

ochLogFiles is still installed, maybe you / me need in in the future

So if you can test if everything is working that would be great!

regards,
Ruud.

Thanks for that work around! I have changed the setting on my live site and it is working. (I actually don't even know if I need that setting on or off as I'm not entirely sure what it is for.)

Sorry about the FTP access. Phocacommander is always a good extension workaround when I need file access to a client site and there is an ftp issue.

And that is so weird about the log path. I do support for Stageit so I will look into that!
 

Hi Tim,
thanks for following up: will push a new release one of these days.

as for the HTML cleanup: there are two ways you can search for text in a document:

1. just see the document as text and then do a search with a regex.
2. read the document into a DOM (HTML Document Object Model) and use the tools that this DOM object offers to do queries on its content.

The first is simple, when looking for an image you just look for "<img .... >" and with some magic you can specifally look for the src part (because that is what we need), but it becomes complex as there are multiple way to write an <img> element, several attributes can be in there (width, height, alt, etc.) and these can be in different order. then there are sites that close the image element not with > but with /> and it is also possible to use " or ' as delimiters (and a combination of). This makes using a regex complex (what started out as simple) and sensitive to errors.

So when you read the HTML text into the DOM, the HTML is parsed (just like your browser does) and every element in it (like <img> is now structured and can be queried very simple.

but... and there is always a but
when you replace a malformatted element in the HTML and parse it via the DOM and then save the search and replace you did on it, then the DOM will rewrite the HTML completely into (what i call) clean HTML. So that is a good thing....
unless you are using a template or module or whatever that outputs 'faulty' HTML: e.g. a <div> without a </div> or wrong nesting <span> etc.

Where the browser is very 'forgiving' when it comes to these errors: it just displays the page as is, the DOM parser fixes these errors as good as possible: sometimes resulting in the page displaying wrong.

So at first I started out with the DOM as search / replace mechanism, but due to all the 'bad' templates and modules out there I soon found myself in 'support' hell, so I decided to also build in the regex search and make that as 'robust' as possible: basically working around bad templates :S

The advanced setting Clean HTML switches between the DOM (yes) and regex search / replace (no).

To make a long story even longer: I will release a new version in the next couple of days, need to finish up on some other things first.

Regards,
Ruud