After 1.0.1 upgrade, error "Unexpected character in input: '\' (ASCII=92)"

10 Posts

pwalrath Reply #1, 16 years, 10 months ago

I upgraded my website from MODx 1.0.0 to 1.0.1. There were no problems or warnings encountered while performing the upgrade.

But since upgrading MODx, I’ve been seeing error messages. I think it’s happening every time I do a POST (ie. when making a configuration change and saving the form, or editing a page and then saving). The error messages are not fatal; the INSERT/UPDATE still seems to make it to the database. But I’m getting these warnings:

[tt]
Warning: Unexpected character in input: ’\’ (ASCII=92) state=1 in /home/myuser/public_html/manager/processors/cache_sync.class.processor.php on line 343

Warning: Unexpected character in input: ’\’ (ASCII=92) state=1 in /home/myuser/public_html/manager/processors/cache_sync.class.processor.php on line 343

Warning: Cannot modify header information - headers already sent by (output started at /home/myuser/public_html/manager/processors/cache_sync.class.processor.php:343) in /home/myuser/public_html/manager/processors/save_settings.processor.php on line 59
[/tt]

I’ve tried

clearing the cache
unzipping the file and re-running the install process

Details of my installation:

Apache 2.2.13
PHP 5.2.11
MySQL 5.1.30
Database charset: utf8
Database Collation Charset: utf8_unicode_ci

I’d appreciate any suggestions you may have. Thanks.

718 Posts

Paprikas Reply #2, 16 years, 10 months ago

http://modxcms.com/forums/index.php/topic,41650.0.html
Is this your issue?

10 Posts

pwalrath Reply #3, 16 years, 10 months ago

Quote from: Paprikas at Nov 02, 2009, 11:40 PM

http://modxcms.com/forums/index.php/topic,41650.0.html
Is this your issue?

Perhaps. Your issue also refers to the [tt]cache_sync.class.processor.php[/tt] file.

I checked my [tt]phpinfo()[/tt], and it says that Tokenizer Support is enabled. But if I understand your ticket correctly, that issue is about what happens if tokenizer support is not enabled.

So I’m not totally sure we’re talking about the same issue.

718 Posts

Paprikas Reply #4, 16 years, 10 months ago

If you don’t have errors during installation - I think it’s not tokenizer fault.

10 Posts

pwalrath Reply #5, 16 years, 10 months ago

I tried doing a fresh install of MODx 1.0.1 on my server, in a different area, using a newly-created MySQL database. Everything was installed correctly, and I’m not seeing the warnings I saw earlier.

At the moment, I’m left wondering if there’s something wrong with the upgrade procedure. My main installation was installed as a 0.9.6 and was upgraded to 1.0.0 and then 1.0.1.

Is there anything else that could possible affect this? Character set configuration for the database or something?

Is there a way of doing a fresh install and then importing all the MySQL data from the live site?

718 Posts

Paprikas Reply #6, 16 years, 10 months ago

Do you have errors after fresh install from svn?

10 Posts

pwalrath Reply #7, 16 years, 10 months ago

Quote from: Paprikas at Nov 04, 2009, 03:47 AM

Do you have errors after fresh install from svn?

Yes, the problems continue. I did the following:

[tt]svn export http://svn.modxcms.com/svn/tattoo/tattoo/branches/1.0.x[/tt]
make into tgz
uploaded to website and tried doing "upgrade" over existing 1.0.1 install

The problems continued.

Interestingly, when I do a fresh install of 1.0.1 (either the release zip file or the latest export from the 1.0.x branch), it works with the default data. But when I load in my MySQL data from my live website, then I see this backslash issue.

I’m wondering if something bad happened to my data during the upgrade. I’ve tried hunting through a database dump looking for strangeness and I didn’t find anything.

$ grep -o '\\.' 04_nov_09_database_backup.sql |sort|uniq -c
   6428 \'
   8556 \"
    422 \\
  12566 \n
  12566 \r

MODX Staff
12,272 Posts

Ryan Thrash Reply #8, 16 years, 10 months ago

You might try changing to a SET NAMES connection method using the advanced upgrade option. There’s a remote chance it’s actually a character set/collation mismatch on the existing database. The default server configuration now might be set to UTF-8, but that doesn’t always mean the specific databases were originally created that way, especially since you’re coming from 0.9.6 from WAY back when.

Ryan Thrash, MODX Co-Founder
Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me

2 Posts

cybersonix Reply #9, 16 years, 10 months ago

Ryan, I am suffering from exactly the same problem with this "invalid" character input" on two modx installation. The other 9 installations I take care of work perfectly fine. I tried reinstalling, using another set of Evo-101 sources but no chance. Even changing the connection method to "SET NAMES" doesn’t help. Really weird

10 Posts

pwalrath Reply #10, 16 years, 10 months ago

That solution doesn’t appear to have worked for me either. I’m still investigating.

For what it’s worth, here’s some of my MySQL server variables:
[table]
[tr][td]character set client[/td][td]utf8[/td][/tr]
[tr][td]character set connection[/td][td]utf8[/td][/tr]
[tr][td]character set database[/td][td]utf8[/td][/tr]
[tr][td]character set filesystem[/td][td]binary[/td][/tr]
[tr][td]character set results[/td][td]utf8[/td][/tr]
[tr][td]character set server[/td][td]utf8[/td][/tr]
[tr][td]character set system[/td][td]utf8[/td][/tr]
[tr][td]character sets dir[/td][td]/usr/share/mysql/charsets/[/td][/tr]
[tr][td]collation connection[/td][td]utf8_unicode_ci[/td][/tr]
[tr][td]collation database[/td][td]utf8_unicode_ci[/td][/tr]
[tr][td]collation server[/td][td]utf8_unicode_ci[/td][/tr]
[/table]