Qual é a maneira correta de os plugins criarem tabelas com considerações especiais de charset / collation?

Question

Qual é a maneira correta de os plugins criarem tabelas com considerações especiais de charset / collation?

#1 resposta do WisdmLabs (1 votos)

4

Estou usando o WordPress > = 3.8. Os valores padrão de charset / collation em wp-config.php são

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

Estou em uma situação em que utf8_general_ci seria adequado , mas algo mais específico ( utf8_danish_ci ) sempre será capaz de descrever melhor meus dados. Também é o caso que os dados, que são obtidos de uma fonte externa, sempre serão UTF-8.

Estou desenvolvendo um plugin que cria alguma tabela

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

Qual é a maneira correta de lidar com charset e / ou collation?

Uma solução é usar a declaração acima, voltando à configuração global. Como mencionado, isso funcionará na minha situação e, do ponto de vista do desenvolvedor, acho razoável exigir que utf8 ou utf8mb4 seja especificado.

A outra solução é definir explicitamente as configurações de conjunto de caracteres / agrupamento:

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

Isso permitirá que eu configure a tabela da maneira mais apropriada para os dados que preciso armazenar e, nos testes, confirmei que a letra Å , que é tratada de forma diferente por utf8_general_ci e utf8_danish_ci , é comparado corretamente. Isso aparece para funcionar, mas não sei se é uma prática boa ou ruim, e, em particular, não sei se isso poderia causar complicações em outro lugar (por exemplo, eu deveria estar mudando as configurações quando consultando a tabela?).

Esta questão tem vários primos, mas isso não parece ser uma duplicata. A resposta mais próxima também menciona o método explícito acima, com um comentário que pode ser mais apropriado usar o valores padrão "para que o usuário possa substituí-los se tiverem um bom motivo".

Se eu fosse me esforçar para usar a configuração principal, seria bobagem especificar essas configurações em primeiro lugar.

É importante entender que nunca haverá uma "boa razão" para usar o não-UTF-8. Com relação ao agrupamento, a questão é menos clara.

A pergunta se resume ao seguinte: dada alguma configuração principal não-UTF-8, que seria considerada sem suporte, devo tomar medidas para fazer com que meu plugin se comporte corretamente?

plugin-development database

por Quail 28.04.2014 / 12:19

1 resposta

Tags plugin-development database

XML-RPC: Adicionar categoria para publicar dados Desabilitando notificações de pingback e trackback

score 1 · Answer 1

Acho que esse problema é tratado pelo WooCommerce em seu plug-in. Ele também cria suas próprias tabelas e é assim que elas cuidam da parte do Collation. (Refiro-me ao arquivo class-wc-install.php do WooCommerce). Eles escreveram o seguinte código na função 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";
    }
}

E, em seguida, essa variável $ collate é anexada no final de CREATE TABLE query.

Portanto, neste caso, a consulta pode ser assim:

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

Assim, eles descobrem o Agrupamento e o conjunto de caracteres do WordPress e os anexam.

Espero que ajude:)