web-dev-qa-db-fra.com

Quelle est la bonne manière pour les plugins de créer des tables avec des considérations spéciales sur les jeux de caractères/collation?

J'utilise WordPress> = 3.8. Les valeurs par défaut de jeu de caractères/classement dans wp-config.php sont

define('DB_CHARSET', 'utf8');
define('DB_COLLATE', ''); // Becomes utf8_general_ci

Je suis dans une situation où utf8_general_ci serait adéquat , mais quelque chose de plus spécifique (utf8_danish_ci) sera toujours en mesure de mieux décrire mes données. Il est également vrai que les données extraites d'une source externe seront toujours au format UTF-8.

Je développe un plugin qui crée une table

CREATE TABLE plugin_table(
    some_id INT NOT NULL,
    some_data VARCHAR(100) NOT NULL,
    PRIMARY KEY  (some_id)
) ENGINE=InnoDB;

Quelle est la bonne façon de gérer charset et/ou collation?

Une solution consiste à utiliser l'instruction ci-dessus, en recourant à la configuration globale. Comme cela a été mentionné, cela fonctionnera dans mon cas, et du point de vue du développeur, je pense qu'il est raisonnable d'exiger que utf8 ou utf8mb4 soit spécifié.

L’autre solution consiste à définir explicitement les paramètres charset/collation:

...) ENGINE=InnoDB [DEFAULT CHARSET=utf8] [COLLATE utf8_danish_ci];

Cela me permettra de configurer la table de la manière la plus appropriée pour les données que je dois stocker. Lors de tests, j'ai confirmé que la lettre Å, traitée différemment par utf8_general_ci et utf8_danish_ci, est comparée correctement. Ceci semble fonctionner, mais je ne sais pas si c'est une bonne ou une mauvaise pratique, et en particulier, je ne sais pas si cela pourrait entraîner des complications ailleurs (par exemple: Je vais changer les paramètres lors de la requête de la table?).

Cette question a plusieurs cousins ​​mais cela ne semble pas être un doublon. La réponse la plus proche mentionne également la méthode explicite ci-dessus, avec un commentaire selon lequel il peut être plus approprié d'utiliser les valeurs par défaut "afin que l'utilisateur puisse remplacer eux s'ils ont de bonnes raisons ".

Si je devais utiliser la configuration de base de manière très différente, il me semblerait alors ridicule de spécifier ces paramètres.

Il est important de comprendre qu’il n’y aura jamais une "bonne raison" d’utiliser du non-UTF-8. En ce qui concerne la collation, la question est moins claire.

La question se résume à ceci: étant donné la configuration de base autre que UTF-8, qui serait considérée comme non prise en charge, devrais-je prendre des mesures pour que mon plug-in se comporte correctement?

plugin-developmentdatabase
4
Quail

Je pense que ce problème est traité par WooCommerce dans son plugin. Il crée également ses propres tables et c’est ainsi qu’elles s’occupent de la partie Collation. (Je fais référence au fichier class-wc-install.php de WooCommerce). Ils ont écrit le code suivant dans la fonction create_tables

global $wpdb;

$collate = '';

if ( $wpdb->has_cap( 'collation' ) ) {
    if ( ! empty($wpdb->charset ) ) {
        $collate .= "DEFAULT CHARACTER SET $wpdb->charset";
    }
    if ( ! empty($wpdb->collate ) ) {
        $collate .= " COLLATE $wpdb->collate";
    }
}

Et puis cette variable $ collate est ajoutée à la fin de la requête CREATE TABLE.

Donc, dans ce cas, la requête peut ressembler à ceci:

CREATE TABLE plugin_table(
    some_id INT NOT NULL,
    some_data VARCHAR(100) NOT NULL,
    PRIMARY KEY  (some_id)
) $collate;

Alors, ils découvrent Collate et charset de WordPress et les ajoutent.

J'espère que ça aide :)

1
WisdmLabs