Jump to content

Maybe useful to check in installroutine of PW the PHP-default_charset ?


Recommended Posts


I have had some (more) trouble to get started with PW  :-(

In my php.ini the default_charset was set to 'ISO-88591' or something similar.

So, as the DB uses utf8 and the pages are delivered in utf8, php is required to use it too.

If not you can run into errors when try to save strings with e.g. german umlaute: äöü ÄÖÜ

     Incorrect string value: '\xFCchte ...' for column 'data' at row 1

I'm not sure if this was checked with the install routine, but I have seen only green lines :-)

Maybe this could be done to avoid some hassle to users with a setup other than utf8.

Or it maybe an option to add "ini_set('default_charset','utf8');" somewhere at the top of index.php,

and to be very very sure (also for paranoics like me :-) ) one can set and check it:

    $php_use_utf8 = strtolower(trim(ini_get('default_charset')))=='utf8' ? true :  false;

Ok, now I can start try out that wonderful CMS :-)

  • Like 2
Link to comment
Share on other sites

I deal with servers set for iso-8859-1 quite regularly, and have never had an issue. PHP isn't exactly UTF-8 native, so we basically treat everything as if it were UTF-8 even if PHP doesn't. But there must be some instances where it does matter, as you've found. I will add the init_set('default_charset', 'utf8') to our initialization. Thanks for pointing this out. 

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Similar Content

    • By tibs
      MySQL's utf8 encoding can only represent a tiny (though useful) subset of the full 31-bit range of Unicode; it's not UTF-8 at all. To fix what never should've been broken, they came up with utf8mb4. It's "of course" (i.e. UTF-8 is some properly designed piece of stuff) upwards compatible with the broken utf8 type. Well, not exactly, but more on that later.
      Would it be possible to default to the real UTF-8 type, when available? (MySQL 5.5.3+) (even wp did it! nudge nudge)
      And here comes that "later" you've all been waiting for. This important(ish) change would require the noble sacrifice of cutting some of the core (YES, CORE!) fields down to 250 characters to satisfy MySQL's sad-pathetic-deplorable limitation on index sizes. I know, that's 5 precious characters lost, but think about all those suffering emojis and suddenly you'll feel all fuzzy and warm, right?
      Anw, just a suggestion, because i18n and l10n and all the like.
      Edit: It seems a cruel RFC took away much of UTF-8's expressive beauty, and it is now valid only up to 4-byte lengths and values of 0x10FFFF, whichever smaller; I'm gonna go and cry myself to sleep now, goodbye.
    • By alanp
      I have a PW site where I had been successfully uploading png and jpeg files. Recently the file and image file fields don't save. The upload status bar completes (100%) without error but when the page with the file field is saved the uploaded file name is missing from the refreshed page.
      This must be due to a site hosting change but I need more specific info like error details before I raise it with them.
      The php v5.4 config has file uploads enabled and safe mode is off. 
      I have tried the following to fix this without success:
      I have read and tried the fixes to the similar posting from Soma:  can't upload image/files problem Upgraded the PW site from 2.3 to 2.5.3. (no change) Turned on debug in config.php with no obvious error messages showing. Debugged core\WireUpload.php where I found that the recommended fixes from 1. wouldn't work because the file field is not using Ajax. Have you got any other suggestions?
    • By anowitz
      I'm moving a PW site from a local environment to a dev site for a client hosted by register.com.  I've followed Ryan's directions here (thanks, Ryan - very clear and helpful!) and am getting an "internal server error" when I go to the root (found here) and am also getting this error when I try to access the admin page:
      "Apache/2.2.22 (Unix) mod_ssl/2.2.22 OpenSSL/0.9.8e-fips-rhel5 DAV/2mod_auth_passthrough/2.1 mod_bwlimited/1.4FrontPage/ Server at dev.callicoonfinearts.com Port 80"
      I created a test.php file that executes phpinfo, among other things (test.php file can be found here.)  From what I can gather, mod_rewrite is not currently enabled.
      I uncommented the "RewriteBase" line in .htacess so that it reads
      RewriteBase /process/
      and have tried placing the .htacess file in both my dev folder and in the site's public_html folder.
      When none of these worked, I called register.com and was advised to enable mod_rewrite through a php.ini file that I should place in the public_html folder.
      My question is - is it possible to enable mod_rewrite using a php.ini file?  (All the research I've done seems to .htaccess or httpd.conf as places where mod_rewrite should be enabled - some comments I've read have specifically said that because mod_rewrite is an apache module it has nothing to do with php or a php.ini file.)  Was I misinformed by the person at register.com, or am I missing something?
      Thanks!!  Many frustrating hours spent on this already....
  • Create New...