Two issues when upgrading to 0.9.6.1

616 Posts

mmjaeger Reply #1, 16 years, 5 months ago

Hello,
first, all my special characters (umlauts etc.) where messed up - in the config file, $database_connection_charset was set to ’utf8’ - changing it to ’utf8_general_ci’ seems to have solved the issue.

second, I’m using the following call in my template:

[!GetField?&field=`longtitle`&parent=`1`&parentLevel=`1`&topid=`[[UltimateParent]]`!]

in order to show the longtitle value of the ultimateParent - unfortunately, this doesn’t work anymore! I’m getting the following error:

MODx encountered the following error while attempting to parse the requested resource:
« PHP Parse Error »

PHP error debug
Error: include_once(assets/snippets/getfield/getfield.inc.php) [function.include-once]: failed to open stream: No such file or directory
Error type/ Nr.: Warning - 2
File: C:\Documents and Settings\Marco M. Jaeger\My Documents\My Web Sites\www\sites\trade.ch\manager\includes\document.parser.class.inc.php(769) : eval()’d code
Line: 58

does anybody knows what the problem is and how to fix this - is there an alternative to the getfield snippet so I could achieve the same?

Thank you in advance for your input!

4,205 Posts

dev_cw Reply #2, 16 years, 5 months ago

first, all my special characters (umlauts etc.) where messed up - in the config file, $database_connection_charset was set to ’utf8’ - changing it to ’utf8_general_ci’ seems to have solved the issue.

Not sure, but I think that the problem here was that 0.9.6 did not set the $database_connection_charset parameter correctly and 0.9.6.1 fixes it.

include_once(assets/snippets/getfield/getfield.inc.php) [function.include-once]: failed to open stream: No such file or directory

The error indicates that the getField.inc.php file is not where it should be. Check to see if the upgrade did not corrupt or delete this file in the process.

[font=Verdana]Shane Sponagle | [wiki] Snippet Call Anatomy | MODx Developer Blog | [nettuts] Working With a Content Management Framework: MODx

Something is happening here, but you don't know what it is.
Do you, Mr. Jones? - [bob dylan]

MODX Staff
10,725 Posts

opengeek Reply #3, 16 years, 5 months ago

utf8 is the proper value. utf8_general_ci is not a charset, but a collation. I have a sneaking suspicion you database charset is not utf8, despite the server being configured with connection charset of utf8_unicode_ci.

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

616 Posts

mmjaeger Reply #4, 16 years, 5 months ago

Quote from: OpenGeek at Dec 10, 2007, 03:17 PM

utf8 is the proper value. utf8_general_ci is not a charset, but a collation. I have a sneaking suspicion you database charset is not utf8, despite the server being configured with connection charset of utf8_unicode_ci.

the database is set to:
MySQL charset: UTF-8 Unicode (utf8)
MySQL connection collation: utf8_unicode_ci

MODX Staff
10,725 Posts

opengeek Reply #5, 16 years, 5 months ago

Quote from: mmjaeger at Dec 10, 2007, 03:22 PM

the database is set to:
MySQL charset: UTF-8 Unicode (utf8)
MySQL connection collation: utf8_unicode_ci

Then utf8 should be the value of $database_connection_charset. Are you sure that’s the actual modx database value, and not just for the server overall?

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

616 Posts

mmjaeger Reply #6, 16 years, 5 months ago

Quote from: OpenGeek at Dec 10, 2007, 03:25 PM

Quote from: mmjaeger at Dec 10, 2007, 03:22 PM

the database is set to:
MySQL charset: UTF-8 Unicode (utf8)
MySQL connection collation: utf8_unicode_ci

Then utf8 should be the value of $database_connection_charset. Are you sure that’s the actual modx database value, and not just for the server overall?

this seems to work as well: $database_connection_charset = ’utf-8’;
after the upgrade it was just like this: $database_connection_charset = ’utf8’; - > without the hyphen

MODX Staff
10,725 Posts

opengeek Reply #7, 16 years, 5 months ago

That’s not correct either. Must be ’utf8’, no dash/hyphen. I assume your site is being presented in UTF-8 on the front-end? That does require a dash in the UTF-8 character encoding string for the site, which is pulling from a different set of values than the database server.

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

616 Posts

mmjaeger Reply #8, 16 years, 5 months ago

Quote from: OpenGeek at Dec 10, 2007, 03:32 PM

That’s not correct either. Must be ’utf8’, no dash/hyphen. I assume your site is being presented in UTF-8 on the front-end? That does require a dash in the UTF-8 character encoding string for the site, which is pulling from a different set of values than the database server.

weird - ’abcd’ works as well - seems that anything works but ’utf8’ - any idea how I could fix this?

Thank you

MODX Staff
10,725 Posts

opengeek Reply #9, 16 years, 5 months ago

Never experienced a problem like that, so we have to identify what is causing your problem first. Is your web site being presented in UTF-8 or not?

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

616 Posts

mmjaeger Reply #10, 16 years, 5 months ago

Quote from: OpenGeek at Dec 10, 2007, 03:41 PM

Never experienced a problem like that, so we have to identify what is causing your problem first. Is your web site being presented in UTF-8 or not?

yep - this is what I have:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />