We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 7231
    • 4,205 Posts
    I was just wondering if it would not be a good idea to include collation/charset settings for tables during install.

    From what I have noticed when setting up a new database no collation info is included for the table and in some cases the individual fields remain showing as set to the default (normally latin1_swedish_ci). Currently, I guess for reverse compatibility, setup.sql builds the tables passively according to the database default, there is no collation/charset being recorded.

    Why not add this info to the CREATE TABLE query to "make sure" that the correct settings are set. I did it manually as a test and it worked great, all my tables and fields all matched with the same settings.

    I am not sure what all is required to do this. I am guessing that a new collation input field will be needed in the install setup (maybe a select box would be ideal like in phpmyadnin). For reverse compatibility the mysql version can easily be checked with:
    if ( version_compare(mysql_get_server_info(), '4.1.0', '>=') ) {...
    Note: this is directly from the WP db install file...but is just straight php straight from the php manual.

    Anyway, just thought I would throw this into the mix since there have been so many recent post concerning charset/collation issues that maybe this would help.

    To illustrate the change, added the info to the bottom of the querry (which has been reduced for illustration purposes only):
    CREATE TABLE IF NOT EXISTS `site_content` (
    `id` int(10) NOT NULL auto_increment,
    `type` varchar(20) NOT NULL default ’document’,
    `contentType` varchar(50) NOT NULL default ’text/html’,
    .....
    `privatemgr` tinyint(1) NOT NULL default ’0’ COMMENT ’Private manager document’,
    `content_dispo` tinyint(1) NOT NULL default ’0’ COMMENT ’0-inline, 1-attachment’,
    `hidemenu` tinyint(1) NOT NULL DEFAULT ’0’ COMMENT ’Hide document from menu’,
    PRIMARY KEY (`id`),
    KEY `id` (`id`),
    KEY `parent` (`parent`),
    KEY aliasidx (alias),
    FULLTEXT KEY `content_ft_idx` (`pagetitle`,`description`,`content`)
    ) CHARACTER SET utf8 COLLATE utf8_unicode_ci TYPE=MyISAM COMMENT=’Contains the site document tree.’;

    I don’t know enough about MySQL to know what ill effects this could cause, but I can’t think of any besides the reverse compatibility issue.
      [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]
      • 22303 MODX Staff
      • 10,725 Posts
      Since the database collation and associated charset are what is used by MODx to do a SET CHARACTER SET, it is not necessary to do this. The problem occurs when you choose a utf8 collation during MODx installation, and install into an existing database that is already set to the server default, which for MySQL is latin1_swedish_ci (don’t ask). If you let MODx create the database, there is no problem, otherwise, you must alter the database to have a utf8 collation/charset before installing the MODx tables using the now established utf8 database_connection_charset value (set when you selected a utf8 collation). So essentially, we want the tables to get created with the database charset/collation settings rather than specify them explicitly.

      An alternate idea would be to simply confirm that the database, if already existing, matches the user selected value, presenting a warning if not.
        • 3749
        • 24,544 Posts
        Quote from: OpenGeek at Feb 19, 2008, 10:14 PM

        Since the database collation and associated charset are what is used by MODx to do a SET CHARACTER SET, it is not necessary to do this. The problem occurs when you choose a utf8 collation during MODx installation, and install into an existing database that is already set to the server default, which for MySQL is latin1_swedish_ci (don’t ask). If you let MODx create the database, there is no problem, otherwise, you must alter the database to have a utf8 collation/charset before installing the MODx tables using the now established utf8 database_connection_charset value (set when you selected a utf8 collation). So essentially, we want the tables to get created with the database charset/collation settings rather than specify them explicitly.

        An alternate idea would be to simply confirm that the database, if already existing, matches the user selected value, presenting a warning if not.

        I’m fairly new to the charset issue, but couldn’t the install just do this before writing to the DB (assuming that the user asked for utf8):

        ALTER DATABASE db_name CHARSET utf8;


        That would set the database character set to utf8 and its default collation (utf8_general_ci) and all tables would end up with a utf8_general_ci collation.

        MODx could then do this on startup:

        SET NAMES 'utf8';


        That would set the client, results, and connection charsets to utf8 and its default collation.

        I don’t know if these would still be necessary:

        httpd.conf:
        AddCharset UTF-8 .utf8
        AddDefaultCharset UTF-8
        
        php.ini
        default_charset = "utf-8"
        
        my.cnf
        character-set-server=utf8
        default-collation=utf8_general_ci


        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
          • 22303 MODX Staff
          • 10,725 Posts
          MODx uses SET CHARACTER SET already, not SET NAMES, on purpose; this ensures that the database collation/charset is always respected, regardless of what you tell the MySQL client connection to translate queries and result sets to (this is not lossless translation mind you, and don’t expect that just because you say utf8 is the database_connection_charset, it will be able to convert characters from utf8 to latin1 that don’t exist in one or the other).

          And running the ALTER DATABASE assumes the dbuser has permission to ALTER the database, so no, but we could make it an option in the installer interface.

          I think everyone gets mixed up trying to display their database content stored as latin1 (or whatever) using UTF-8 on the site. This will simply never work properly; if you expect content encoded as UTF-8, then use utf8 in the database from the start or you will end up having to convert content when you decide to switch.
            • 3749
            • 24,544 Posts
            Quote from: OpenGeek at Feb 19, 2008, 11:08 PM

            I think everyone gets mixed up trying to display their database content stored as latin1 (or whatever) using UTF-8 on the site. This will simply never work properly; if you expect content encoded as UTF-8, then use utf8 in the database from the start or you will end up having to convert content when you decide to switch.

            Right. This is what my snippet was meant to fix. I wanted to convert all my existing MODx installs to all UTF-8, do all UTF-8 installs in the future, and stop thinking about it.

            Once that’s done, is there still an issue with settings in httpd.conf, php.ini, or my.cnf?

            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
              • 22303 MODX Staff
              • 10,725 Posts
              Quote from: BobRay at Feb 19, 2008, 11:44 PM

              Once that’s done, is there still an issue with settings in httpd.conf, php.ini, or my.cnf?
              I never mess with those settings myself; I don’t think they are necessary, at least not in most situations.
                • 7231
                • 4,205 Posts
                Since the database collation and associated charset are what is used by MODx to do a SET CHARACTER SET, it is not necessary to do this.

                OK, I see.

                I just went through the install/upgrade process a few times and discovered that who is triking me is actually phpMyAdmin. I have the impression that I have set the default to be UTF8 by setting the "MySQL charset:" and "MySQL connection collation:" to UTF. So I expected that when creating a new db that it would default to those settings. However they still default to latin1_swedish_ci regardless. So even if you set those settings you still need to set the collation of the new database when creating.

                Either I have misunderstood the purpose of "MySQL charset:" and "MySQL connection collation:", or it is misleading. But now I understand why this was happening.

                Sorry to open up this can of worms, but knowledge is power grin

                EDIT: I am ashamed to say that I never considered to let MODx create the database and it did it perfectly (not surprised). I know that this worked for my local install since I have root access and permissions but in a shared server and with cPanel environment this will never be a possibility since you need to attach a user to a database on creation. I guess that is why I am conditioned to always do it myself.

                Maybe this statement in the install instructions page could be ammended (and made more visible) to include warnings of charset and collation...or is this something for the wiki?

                Database Note: MODx uses a MySQL database. You will need the username and password to your database to install MODx. If your database user does not have database creation permissions on the server, you will also need to have a database already created for MODx to use.
                  [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]
                  • 3749
                  • 24,544 Posts
                  This is about the best description I could find:

                  http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html

                  If you go into PhpMyAdmin and, on the main screen, click on "Show MySQL System Variables," you can see the full horror of how many different settings there are for character sets and collations.

                  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
                    • 22303 MODX Staff
                    • 10,725 Posts
                    Quote from: dev_cw at Feb 20, 2008, 05:55 AM

                    Either I have misunderstood the purpose of "MySQL charset:" and "MySQL connection collation:", or it is misleading. But now I understand why this was happening.
                    Right, these are PHPMyAdmin’s version of MODx’s settings; they are setting the MySQL client information used by the phpMyAdmin web application, just like MODx does. They likely use it in a similar way, to make sure the data going in and out gets converted for the actual database/table charset/collations from the web interface.
                      • 3749
                      • 24,544 Posts
                      The more I mess with this, the more I wonder if we shouldn’t advise people check their server settings and their database permissions before making a decision.

                      I’ve found that on one old site of mine, I can only create a databse using their cPanel wizard, which doesn’t allow you to set any charsert stuff. Every db I create there will end up with latin1 and latin1_swedish_ci for the database setting, although I can set *tables* to have anything I want. In a case like that, wouldn’t it make more sense to do everything in latin1 unless there was some compelling reason for using UTF-8?

                      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