nurtsio Posted August 17, 2011 Share Posted August 17, 2011 Hi! I've just begin using ProcessWire. Because my site is written in Finland, it contains lots of ä's (a with dots) and ö's. The problem occurs in every field where I use these characters, it cuts the field content right there. E.g. "hyväntekeväisyys" cuts to "hyv". You see, that's a problem. Is it the default template, UTF-8 or what? Thank you for your assistance, Akseli Link to comment Share on other sites More sharing options...
jbroussia Posted August 17, 2011 Share Posted August 17, 2011 The default template files are ANSI encoded, maybe they should be converted to UTF8 for it to work (I have no idea !) ? Link to comment Share on other sites More sharing options...
Adam Kiss Posted August 17, 2011 Share Posted August 17, 2011 Hi Akseli and welcome to the forums. I'm inclined to say it's utf problem – somewhere along the lines of php <=> mysql communication, since we have another scandinavian active here on the forums and in the few examples he posted, all special scandinavian characters work OK. Is your database set to UTF? If your DB has UTF-8 set, your templates are UTF-8 (important!), you might want to try this: In your /site/ directory, there is config.php. Locate line 137 and uncomment this: $config->dbSetNamesUTF8 = true; If it doesn't help, we'll move on to different solutions Link to comment Share on other sites More sharing options...
apeisa Posted August 17, 2011 Share Posted August 17, 2011 Moro Aleksi ja tervetuloa! PW should be all the way UTF-8 and I have had no issues with special chars at all. Template encoding doesn't matter (only if want to write special chars directly to the template files). So agree with Adam, problem probably lies between php & mysql. Is your db tables UTF-8? Link to comment Share on other sites More sharing options...
ryan Posted August 17, 2011 Share Posted August 17, 2011 It definitely sounds like a UTF8 issue. Here's another possible solution: http://processwire.com/talk/index.php/topic,138.msg2406.html#msg2406 I'm thinking about just placing that 'AddDefaultCharset UTF-8' to the default htaccess file so that this doesn't come up for anyone else. Though I'm not certain that's the problem here. If this solution doesn't do it, I'm guessing Akseli may be running an older 2.0 version that still had some latin1 tables in it and need to be converted to utf8. Akseli what version are you running? Thanks, Ryan Link to comment Share on other sites More sharing options...
nurtsio Posted August 20, 2011 Author Share Posted August 20, 2011 Hi, and thanks to everyone! Ryan's link to htaccess-edit worked. Everything is working properly now! I'm using the latest stable version, meaning 2.0. By the way, is 2.1 currently safe to use on production site? Link to comment Share on other sites More sharing options...
Adam Kiss Posted August 20, 2011 Share Posted August 20, 2011 It's very close to stable, and Ryan & Antti are running sites on it for weeks (if not months already). Me however, as a quite heavy user of niche functions, found few nasty bugs (though not critical), although majority of the has been fixed. I'll be using this as a production version once my latest project goes live, that is in 5-7 days. Use this information as you will Link to comment Share on other sites More sharing options...
ryan Posted August 21, 2011 Share Posted August 21, 2011 If you are starting a new site I would go ahead and use 2.1. But since we're still wrapping up some details, you would just want to test any changes locally (stage them) before pushing to your production server. However, that workflow applies regardless of version or CMS, so if you are using best practices with your workflow then use 2.1. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now