specialchars error

As I'm running a relatively fresh install of OC I'm monitoring error logs.
I found one that resurfaces from time to time:

PHP Warning: htmlspecialchars(): Invalid multibyte sequence in argument in /home/maxmini/opencart/system/library/request.php on line 33

Any ideas what may cause that and howto fix it?

you might have corrupted data or something: http://stackoverflow.com/questions/3803 ... n-argument

ok, so any ideas how should I approach the problem?

is there any specific place you see the error?

I'm trying to figure it out. I have a suspicion that it may be Blog module that generates those, but I'm not sure.

I'm not sure what is the best way to identify the culprit

OC version? Blog name, version?

The "htmlspecialchars" refers to ampersands, copyright and registered trademark symbols, typesetters' formal endashes and emdashes (hyphens, dashes), and other sorts of characters that are expressed in code as html gibberish rather than as you see them on keyboards and monitors. It may be telling you to MAKE them into the required gibberish (for example, a simply typed ampersand, &, without its special & will predictably misfire in several contexts that require the & part to be followed by the amp; part). All things considered, it might be fussing about exactly one ampersand appearing as only "&" in exactly one place that accordingly fires the error just sometimes, coinciding with when the naughty page is summoned.

Przemas wrote:I'm trying to figure it out. I have a suspicion that it may be Blog module that generates those, but I'm not sure.

I'm not sure what is the best way to identify the culprit

Try viewing each of your blog posts one by one, and see which one is generating the error. Then proceed to your admin and edit that post, and copy the data to a notepad, and paste it back from the notepad to the text box.

You can also try looking at documentation for the blog software, for information on "special characters" such as use them, do not use them, etc..

thx guys.
I'm using OC 1.5.5.1 on nginx , for blog I use this module http://bit.ly/140BELZ.

I have a feeling that the issue is slightly more tricky. All the articles usually have a step with notepad, or are being written in Notepad++ with UTF-8 as a charset. Also in general the articles look good when I view them in the web browser.

But the charset seems to be a problem in other parts of the site as well.
First of all PayPal standart gives me IPN email mismatch error as during the request @ is being changed to %40; .
Also when I've added Disqus o the site I've noticed it messes up links as it changes & to amp; . The funny thing is that when I use echo command to display variable that tells disqus what the links are the link is displayed correctly, without html entities.
As I haven't meddled with a code for quite a time I have to admit I'm pretty confused at this point.

try checking with your web host if they made any changes to your server. it might have an impact on your website too

We have five things going on here along with the html special characters: 1.5.5.1, module http://bit.ly/140BELZ, nginx, %, Disqus.

(1) OC 1.5.5.1 itself is not causing the problem. If yours deviates by way of theme or vqmod, they could give rise to the problem but that is still unlikely.

(2) Your module http://bit.ly/140BELZ is one of those, probably not at fault, but from his list (*, ^, ~) of fixed, etc., it appears that you should ask the author about the problem with html special characters, primarily so that he'll be aware of it even in the likely event that his module is not contributing to the problem.

(3) The nginx might well be contributing, if only by way of (over)reacting to another source of the problem. Its behaviors can be odd enough that I will not knowingly connect or stay connected to it. Probably my first contact with it just happened to be infected but, infected or not, it instantly triggered my machine's array of defenses; lesson learned, I won't have anything to do with it, won't visit it and certainly won't install it. Turn to server support, read up on nginx.

(4) The "%mumbo%jumbo%" raises another thing to look at, spaces in filenames.extensions or directorynames, use "_" or interposed caps or some way to make "words" without spaces. If that nonsense is forcing its way into the very reading and rendering of special characters (or of anything in any character set), then your website is self-detonating strings. You don't want a payment gateway saying to find it, fix it, then we'll let you back in. Try server support.

(5) Ditto, Disqus, check its documentation and support, try server support.

Note this one: http://forum.opencart.com/viewtopic.php?f=19&t=104822

However, html special characters are not a prevalent, rampant problem in 1.5.5.1 or prior or subsequent OC, and accordingly I still do not see the problem as a "bug" in OC itself. If there is a "bug" at that point by way of mistaken typing or transcription or file corruption, then so be it, but that differs from a flaw in core logic or syntax, which in the main do not throw errors over html special characters.

thx butte.

The thing that really made me confused is I think we're having this html entities issue in a couple of places and the behaviour is strange.
I know I'm repeating myself, but really I'm trying to understand what's going on.
First module that made me aware there's some kind of problem was PayPal Standart. I've noticed IPN email address mismatch erros in the log. They have been caused because example@exmaple.com in the request has been changed to example%40example.com.

Then when I added Disqus to the blog module by a simple edit of the code (pasted code from Disqus and added extra variables that help Disqus organize comments) I've noticed the thing again. The comments are displayed correctly, but when you try to click links to other discussions you quickly notice they are broken as "&" in the links are being converted to html entities.
And here's the part that confused me - I've added a simple line that displays the variable that goes to Disqus (in my case it was <?php echo $link; ?> ). To my surpise the variable displays without entities. So unless the variable gets sent with entities and while I "echo" it html entity decode happens somewhere on the site it makes no sense.

As mentioned I'm not into web programming (haven't done any in past couple of years) so figuring it out is tricky.....
From the beggining language on site has been set to EN and I'm doing my best to avoid spaces and other messy things in file names etc.

Two little things come to mind, and may be a tad silly but might give you an idea of where to look for what.

(1) Here oversimplified for intuitive point, in "batch" files (executable .bat) run on the command line (C:\), which are still usable today, one minds single- and double-echoing by way of turning on or off part of what makes it display. That does not arise in php but escaping certain characters serves to keep the machine's attention on whether a text string is meant as a text string or as a command. For example, \ before ' or " prevents all-white screens (or not). That does not appear in your echo $link; but look at $link to see the syntax where it is defined or triggered. Something is causing % that seems restricted to a couple of contexts (payment, Disqus).

(2) The special characters arise routinely in "international" alphabets and in such basics as ampersands, copyrights, and trademarks. They also arise in one way of spelling out punctuation marks. IF, for example, an ampersand is shown as & rather than as & in code, there is an instantly elevated risk that the machine will do something unexpected. Much as when a file saved in ordinary Notepad needs to be saved in unicode in order to retain characters that are not ordinary English, you may need to look through code involving payment and involving Disqus for something as simple as a bald & that should be converted to & (ditto others, even the other way, such as " or ' or backtics). The point is merely to look for those, and see whether they are consistent in code in those places. Might be strewn among several files that feed iterations of index.php; might be maddeningly simple.