MODx 0.9.6 Issues

315 Posts

BBloke Reply #71, 19 years, 4 months ago

If you’ve been having trouble with the Show/Hide technique then I got it sorted here:

http://modxcms.com/forums/index.php/topic,15317.msg98853.html#msg98853

BBloke

242 Posts

stefan Reply #72, 19 years, 4 months ago

Hello opengeek,

you wrote

And all of my UTF-8 and latin1 sites are working flawlessly with 0.9.6.

mmmh i start an new project in 0.9.6 as well and somthing is going wrong with the charset. I found the utf8 characters instead the german specialchars in the content Table( like öüä ). On the homepage they displayed well. I install modx with charset uft8.

Database settings:
MySQL charset: UTF-8 Unicode (utf8), MySQL connection collation: utf8_general_ci and also the modx Database and its tables.
Settings in modx: charset= utf8", tinyMCE input Format = raw

i found a new parameter in the config file "$database_connection_charset" it was empty by default. If it fill it with "utf8_general_ci" nothing happen.

i am a little afraid of it. Have you any idea whats up with my installation?

thank you.

ciao, Stefan

MODX Staff
10,725 Posts

opengeek Reply #73, 19 years, 4 months ago

It should be setting the default charset (not collation) in $database_connection_charset (i.e. utf8 or latin1, not utf8_general_ci or latin1_swedish_ci) on upgrade from 0.9.5. If you installed an 0.9.6 RC release, then this likely got set improperly to a blank value which is now causing you problems; in 0.9.6 final, it should now be setting that variable properly if it does not yet exist in your config file. Without this variable being set properly, you are at the mercy of the database server and PHP mysql client configurations with regards to character sets and collations.

You can rerun the upgrade in advanced mode to edit the database settings manually to correct this, or you can just edit the config.inc.php file.

Another thing to watch out for is ultimately, each individual table, and even each column that contains textual data, defines the collation (and thus the charset), so make sure your tables are not residing in a database with a utf8 charset/collation but specifying a different collation on the actual tables/columns.

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

☆ A M B ☆
427 Posts

W. Shawn Wilkerson Reply #74, 19 years, 4 months ago

I’m getting 500 errors with clean installs as well as over the top of .95 (which installed in about a minute flawlessly).

Logs keep yelling about "Premature end of script headers: php-script"

Memory is set to 30Megs in php.ini

Don’t see anything else that should need to be messed with.

Permissions are set per install instructions.

Any other ideas?

.95 works/installs flawlessly

PHP 4.4.4 (cgi)
Red Hat Enterprise Linux ES release 4 (Nahant Update 4)
Firefox 2.0.0.4, Konqueror 3.5.6, Internet Explorer 7 (if you can call it a browser)
Apache/2.0.52
Mysql server version: 4.1.20

Get your copy of MODX Revolution Building the Web Your Way http://www.sanitypress.com/books/modx-revolution-building-the-web-your-way.html

Check out my MODX || xPDO resources here: http://www.shawnwilkerson.com

242 Posts

stefan Reply #75, 19 years, 4 months ago

Hello opengeek

Thanks a lot for your hint!
All collations and charsets of database, tables and rows was already set to uft8.
I change the parameter "$database_connection_charset" to "utf8" in the config file and it work fine now.

Thank you!
ciao, Stefan

addendum: i am really confused about the writing style utf8, utf-8, uft8_gerneral_ci.... jesus, i am not clever enough....

1 Posts

NeutralizeR Reply #76, 19 years, 4 months ago

I found MODx yesterday from Google by typing "seo cms" then I tested the demo web site before installing and it was definetely looking what i’d been looking for.

To be honest, i’m a little dissappointed because of the bugs i’ve been trying to fix since the last 24 hours.

I thought i’d be able to edit the contents and made the web site live immediately... The reason i want to use MODx is simple as i already have a vBulletin (with vBSEO) + CMS + custom HTML pages: "the extra plain SEOed pages for the search engines".

Anyway, maybe the dissappointment just comes from being completely new to MODx...

Document’s alias is not sticking, keeps going blank after you save

I also have this problem. Hope it’s fixed asap and i keep editing my fresh MODx installation.

At least, i colored the template to match my web site’s skin

http://messenger.msxlabs.org

Btw, i downloaded the translation-kit to build a proper Turkish translation of MODx.

Regards,
NeutralizeR

MsXLabs Organization

66 Posts

bkvernst Reply #77, 19 years, 4 months ago

Quote from: robb01 at May 29, 2007, 10:59 AM

No, that´s not...

now following error (really the same as before):

Warning: strtr(): The second argument is not an array. in .../manager/processors/save_content.processor.php on line 859

Warning: Cannot modify header information - headers already sent by (output started at .../manager/processors/save_content.processor.php:859) in .../manager/processors/save_content.processor.php on line 563

after change the save_content.processor.php with the old one of 0.9.5. there are no errors - but i didn´t go into the deap...

I got the same problem... What could be wrong? It happens when I’m saving documents.

24,544 Posts

BobRay Reply #78, 19 years, 4 months ago

Quote from: OpenGeek at Jun 02, 2007, 04:03 PM

It should be setting the default charset (not collation) in $database_connection_charset (i.e. utf8 or latin1, not utf8_general_ci or latin1_swedish_ci) on upgrade from 0.9.5. If you installed an 0.9.6 RC release, then this likely got set improperly to a blank value which is now causing you problems; in 0.9.6 final, it should now be setting that variable properly if it does not yet exist in your config file. Without this variable being set properly, you are at the mercy of the database server and PHP mysql client configurations with regards to character sets and collations.

You can rerun the upgrade in advanced mode to edit the database settings manually to correct this, or you can just edit the config.inc.php file.

Another thing to watch out for is ultimately, each individual table, and even each column that contains textual data, defines the collation (and thus the charset), so make sure your tables are not residing in a database with a utf8 charset/collation but specifying a different collation on the actual tables/columns.

I upgraded from 095 to 096 (final, not rc) and the line in my config file is Latin1, the host settings are UTF-8 (charset) and utf8-unicode_ci (connection collation), but if I look in the database, individual tables are still set to latin1_swedish_ci and
latin1_general_ci. Is this a problem?

Bob

Did I help you? Buy me a beer
Get my Book: MODX:The Official Guide
MODX info for everyone: http://bobsguides.com/modx.html
My MODX Extras
Bob's Guides is now hosted at A2 MODX Hosting

MODX Staff
10,725 Posts

opengeek Reply #79, 19 years, 4 months ago

Quote from: BobRay at Jun 03, 2007, 06:18 PM

I upgraded from 095 to 096 (final, not rc) and the line in my config file is Latin1, the host settings are UTF-8 (charset) and utf8-unicode_ci (connection collation), but if I look in the database, individual tables are still set to latin1_swedish_ci and
latin1_general_ci. Is this a problem?

No, it is not a problem if that’s the encoding/collation you want to store the data in. The behavior of SET CHARACTER SET is to read the actual collation from the database which MODx resides in, and these same values are used to auto-detect this during upgrade from any previous release that did not specify a $database_connection_charset value. If your config file specified $database_connection_charset = ’utf8’; and the actual tables had a latin1 collation, then it would be a problem.

One thing to keep in mind in the character set/collation stuff is that it is database specific. In other words, this new feature controls only the PHP/MySQL client connection, and has absolutely nothing to do with the character set with which you are presenting your site in, although those should match to avoid problems with presenting characters outside of the encoding your pages are indicating. I always create my databases using utf8 and utf8_general_ci, and present them using UTF-8 to avoid any problems; generally, this is the easiest way to ensure you can handle the widest number of possible languages.

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

1,131 Posts

Bravado Reply #80, 19 years, 4 months ago

Quote from: islander at Jun 02, 2007, 04:58 AM

One problem I have found is inside of the Manager, "Tools/Configuration/Site & Interface", changing the language and or TinyMCE front end, TinyMCE doesnt change to the selected language, ie. if I select Spanish for everything, the editor is still in English, even though the lang. file exists in the editors folder.

Are you sure you set the "Front-end Editor Language" setting? I just tested it and it worked dandy for me. I’ll do a little more testing on this though.

Jeff

Jeff Whitfield

"I like my coffee hot and strong, like I like my women, hot and strong... with a spoon in them."