get_option () não está funcionando, mesmo o db contém o nome da opção e o valor da opção correspondentes

Em primeiro lugar, isso não é um problema específico do plugin. Pergunto-me por que isso pode acontecer? Estou usando a Tax Meta Meta da bainternet para salvar o Taxonomy Meta usando a tabela de options . Coloquei meu conteúdo no localhost (ambiente XAMPP Windows 5.5.19), encontrei meus dados na tabela de opções. Tudo estava funcionando bem.

Agora eu coloquei o meu site no servidor (Linux | PHP 5.2.17) e está falhando ao recuperar os dados da tabela de opções.

 $type_icon_array = get_tax_meta( $type->term_id, 'offer_type_icon' ); var_dump( $type->term_id ); //showing the id nicely var_dump( $type_icon_array ); //showing null 

A function falhou ao recuperar dados. Como a function é:

 //get term meta field public function get_tax_meta($term_id,$key,$multi = false){ $t_id = (is_object($term_id))? $term_id->term_id: $term_id; $m = get_option( 'tax_meta_'.$t_id); if (isset($m[$key])){ return $m[$key]; }else{ return ''; } } 

Eu ignoro as funções Meta do imposto e tentei o rudimentar do WP:

 $tst1 = get_option( 'tax_meta_6' ); var_dump($tst1); //showing null 

Como você pode ver, o database tem o valor na tabela de options :
db tem valor de opções

Mas você pode ver o que aconteceu:
mostrando nulo

Em seguida, carreguei uma imagem (enquanto estou no servidor remoto) em Taxonomy ID # 2, e você pode ver a imagem está mostrando lá.

O que poderia acontecer aqui, que o valor está em db, mas get_option() não está tendo esse valor? (Mas está funcionando enquanto estou atualizando o campo nesse ambiente particular ) Eu até tentei:

 get_option( 'tax_meta_6', array() ); 

sem sorte! 🙁

Eu sei que o requisito mínimo do WordPress é o PHP 5.2.4, mas pode aquele dev perdido. a versão causa tal massacre?


Editar

Eu encontrei uma razão pela qual isso PODERIA / PODERIA acontecer: Verifiquei os dados serializados locais e de servidor e encontrei um pouco de incompatibilidade lá, suponho que meus dados locais sejam:

 a: 1: { s: 15: "offer_type_icon"; a: 2: { s: 2: "id"; s: 3: "428"; s: 3: "url"; s: 61: "http://localhost/example/wp-content/uploads/2015/04/image.png"; } } 

Quando eu estou carregando para o servidor que substitui todo o URL de base, os dados de separação se tornam:

 a: 1: { s: 15: "offer_type_icon"; a: 2: { s: 2: "id"; s: 3: "428"; s: 3: "url"; s: 61: "http://example.com/wp-content/uploads/2015/04/image.png"; } } 

O URL está mudando, mas a contagem de seqüências de caracteres para o URL alterado permanece igual à do localhost. Mas deve ser 44 porque o novo URL de base tem menos 17 caracteres.

Se esta é a causa, como posso resolver essa migration WP enquanto o db possui dados serializados com o URL do site?

EDITAR 2

SIM, esse é o motivo.

Os dados de URL serializados estão sendo alterados, mas sua contagem de cadeias não é.

Solutions Collecting From Web of "get_option () não está funcionando, mesmo o db contém o nome da opção e o valor da opção correspondentes"

Ok, finalmente descobriu que, os dados serializados, onde existe um site_url, estão causando o problema enquanto eu estou migrando os dados do localhost para o servidor, substituindo o URL local pelo URL do servidor.

Encontrei duas soluções, ambas ainda não foram testadas:

  • Fixação de Serialização PHP para Migrações do WordPress (e outras aplicações como o Expression Engine) por David Coveney
  • Fix-Serialization (Script para corrigir atributos de comprimento em cadeias serializadas) – por Pau Iglesias

Não precisa dizer isso, experimente-os com seu próprio risco .

EDITAR

ANTES DE TUDO
BACK UP YOUR DATABASE FIRST

Tudo bem, eu encontrei a primeira tabela apenas específica para options e não muito flexível e também não confiável (WTFLicensed: p). Então fui com o segundo de Pau Iglesias .

Eu achei que funcionava bem. Mas como eu sou um usuário do Windows, não poderia usar o script do shell, então eu pedi seu retomado e fiz meu próprio caminho usando o mesmo script:

  • serialization-fixer – Raw PHP way – github

Usar o meu é um pouco sever-specific. Você precisará colocar o arquivo .sql substituído por string exportado na mesma pasta onde o serialization-fixer.php é. Então você precisa abrir o arquivo e alterar a linha # 21 com o nome do arquivo do arquivo .sql . Depois disso, você pode simplesmente executar o arquivo do seu navegador.

Obrigado a Pau Iglesias por seus bons scripts.