We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 20407
    • 82 Posts
    Been getting this error fairly regularly in my MODX Error Log (Revo 2.2.15):

    [2014-11-18 22:13:18] (ERROR in xPDO::getValue @ /[...]/public_html/core/xpdo/xpdo.class.php : 1096) Error HY000 executing statement: 
    Array
    (
        [0] => HY000
        [1] => 1267
        [2] => Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '='
    )
    


    Anything I should be concerned about?
    • It means that your database is most likely a different collation than MODX is asking for. If you're only using the English-based characters it probably won't hurt anything, but you might want to look into your database charset and collation, make sure its character set matches the collation, which matches the connection properties in config.inc.php.

      http://bobsguides.com/convert-db-utf8.html
      http://stackoverflow.com/questions/1008287/illegal-mix-of-collations-mysql-error

        Studying MODX in the desert - http://sottwell.com
        Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
        Join the Slack Community - http://modx.org
        • 17284
        • 54 Posts
        I also saw this error, and it turned out the url parser in modx was being fed malicious urls.

        I added an .htaccess rule to block the various characters they used.

        GET /something%e2%c3%af%c2%bf%c2%bd%a6something


        I found this by searching through the apache logs for the time stamp of the modx error, and realized really all that was happening was that modx was rejecting the bad input, correctly, and then sending the modx 404 error page back. This generated the warnings in the error log.

        http://krypted.com/utilities/html-encoding-reference/ gives a fine list of translating the special html characters into ones you can recognize.

        Note that the advice to use the right db and db table character encoding is correct, but in our case, all our users and input match the swedish default which I accidentally made the db with initially, so there's not actually any problem with valid input in our case.

        You have to be careful constructing the blocking rules, because there are many valid %xx type characters, %20 for space for example, but you'd want to check all your GET urls with something like this (run on an apache log file in this case, set to cut off everything after the 3rd ", then to refilter it because referers can also have %xx in their urls):

        zgrep -Ei '%[0-9a-f]' site.20180621.gz | cut -d '"' -f 1-3 | grep '%'
        [ed. note: lizardx last edited this post 5 years, 10 months ago.]
          • 46886
          • 1,154 Posts
          interesting info. what was feeding them in? [ed. note: nuan88 last edited this post 5 years, 10 months ago.]