Não foi possível selecionar uma data antiga no wordpress

Não consigo definir o ano abaixo de 1899 para uma publicação. Se eu definir um ano abaixo de 1899, ele é definido como o ano atual automaticamente.

captura de tela

Comprei o tema Timeline e perguntei no seu fórum de suporte. Eles responderam:

Isso soa como uma limitação criada pelo seu provedor de hospedagem. Nada no tema está impedindo a data que você atribuir – como você pode ver, a demonstração tem postagens usando datas no 1400. Tente entrar em contato com seu provedor de hospedagem e ver se eles têm alguma visão sobre como abordar isso.

Solutions Collecting From Web of "Não foi possível selecionar uma data antiga no wordpress"

Esta não é realmente uma resposta, apenas uma tentativa de encontrar o contexto específico para esse problema. Instale o seguinte plug-in no seu site, tente definir as três datas e adicione seu resultado ao segundo


na tabela abaixo.

 /* Plugin Name: WPSE Sysinfo */ add_action( 'admin_footer', 'wpse_sysinfo' ); function wpse_sysinfo() { $bit = 4 === PHP_INT_SIZE ? 32 : 64; // PHP version, not OS! $php_version = PHP_VERSION; $db_version = $GLOBALS['wpdb']->db_version(); print "
$bit | $php_version | $db_version

"; }

Gist of the Plugin pode ser verificado aqui .

 SO |  Bit OS |  PHP |  PHP Bit |  MySQL |  999 |  1899 |  2020 |  2039 |  do utilizador
 WIN7 |  64 |  5.4.4 |  ??  |  5.5.25 |  ✘ |  ✘ |  ✔ |  ✘ |  toscho
 Linux |  ??  |  5.3.18-nmm1 |  ??  |  5.1.70 |  ✔ |  ✔ |  ✔ |  ✔ |  toscho
 CentOS 6 |  64 |  5.5.4 |  ??  |  5.0.95 |  ✔ |  ✔ |  ✔ |  ✔ |  toscho
 WIN7 |  64 |  5.4.15 |  32 |  5.5.31 |  ✘ |  ✘ |  ✔ |  ✘ |  rarst
 Ubuntu 12.04 |  64 |  5.3.10-1 |  64 |  5.5.32 |  ✔ |  ✔ |  ✔ |  ✔ |  Pille
 CloudLinux |  64 |  5.2.17 |  64 |  5.0.96 |  ✔ |  ✔ |  ✔ |  ✔ |  Pille
 Ubuntu 12.10 |  64 |  5.4.6 |  64 |  5.5.32 |  ✔ |  ✔ |  ✔ |  ✔ |  Michael Ecklund
 CENTOS 5.9 |  32 |  5.3.27 |  32 |  5.5.32 |  ✘ |  ✘ |  ✔ |  ✘ |  Michael Ecklund
 WIN7 |  64 |  5.4.7 |  64 |  5.5.27 |  ✘ |  ✘ |  ✔ |  ✘ |  kaiser
 OSX 10.7.5 |  64 |  5.3.6 |  64 |  5.5.9 |  ✔ |  ✔ |  ✔ |  ✔ |  GhostToast
 Centos 6.4 |  64 |  5.4.17 |  32 |  5.1.59 |  ✘ |  ✘ |  ✔ |  ✘ |  birgire
 Debian 6 |  64 |  5.4.19 |  64 |  5.1.66 |  ✘ |  ✘ |  ✔ |  ✘ |  birgire
 WIN7 |  64 |  5.5.0 |  64 |  5.5.22 |  ✘ |  ✘ |  ✔ |  ✘ |  GM
 OSX 10.7.4 |  64 |  5.3.6 |  64 |  5.5.9 |  ✔ |  ✔ |  ✔ |  ✔ |  brasofilo
 CentOS 5 |  64 |  5.3.22 |  64 |  5.1.68 |  ✔ |  ✔ |  ✔ |  ✔ |  brasofilo
 Mac 10.8.5 |  64 |  5.3.26 |  64 |  5.5.25 |  ✔ |  ✔ |  ✔ |  ✔ |  flentini
 WIN7 |  64 |  5.3.27 |  64 |  5.5.31 |  ✔ |  ✔ |  ✔ |  ✔ |  Sascha Krause
 Win7SP1 |  64 |  5.3.8 |  64 |  5.5.28 |  ✔ |  ✔ |  ✔ |  ✔ |  Manuel Sychold
  1. Crie uma nova postagem. Salve isso.
  2. Defina a data para 01 de janeiro de 0999 , clique em Atualizar . É salvo ou alterado para a data atual?
  3. Repita as configurações de data para 1899 , 2020 e 2039 .
  4. Pegue as informações da saída do plugin no seu rodapé de administrador e atualize a tabela.

Pergunta e expectativas

Embora a forma literal desta questão seja prática em contexto (ano de 1899) é um pouco vago no sentido teórico. Quantos anos tem de idade? Quão longe no passado queremos ir? E o futuro?

Uma vez que o WordPress tinha começado como motor de blogs, nesse sentido contextual , ele evoluiu para lidar com o período de tempo seguinte:

  • datas WP existiram (obviamente para poder usá-lo)
  • variedade de possíveis postagens históricas (implicitamente, tanto quanto a Internet existia)
  • até o futuro, sem esforço especial (trabalho até quebrar)

À medida que o uso do WordPress evoluiu para aplicações não blogueis, tais projetos (geralmente história e arte como eu vi de relatórios) começaram a atingir problemas variados com datas fora desse período.

Para a minha pesquisa, formulei as seguintes questões:

  1. Quais são os dois primeiros anos civis mais antigos e mais recentes, que podem ser usados ​​com as datas da publicação do WordPress de forma nativa e confiável?
  2. Quais são as frutas penduradas baixas (se houver) para estender a extensão disponível além do alcance nativo?

Limitações da plataforma

Como o WordPress é uma aplicação PHP e usa o MySQL para armazenamento de dados, está sujeito às suas limitações.

MySQL

O WordPress armazena as datas da post_date na coluna post_date do tipo DATETIME no MySQL.

De acordo com a documentação, esse tipo suporta anos 1000 a 9999 :

O tipo DATETIME é usado para valores que contêm partes de data e hora. O MySQL recupera e exibe os valores DATETIME no 'YYYY-MM-DD HH:MM:SS' . O intervalo suportado é '1000-01-01 00:00:00' para '9999-12-31 23:59:59' .

No entanto, também diz que valores anteriores podem funcionar, sem menção de valores posteriores:

Para as descrições de faixa DATE and DATETIME , “suportado” significa que, embora os valores anteriores possam funcionar, não há garantia.

Embora empiricamente tenha observado valores fora do alcance, esta é anedótica e cai fora de nossa condição de confiabilidade.

PHP

Na programação PHP, a representação de data e hora do Unix é amplamente utilizada. De acordo com a documentação para nossos propósitos (PHP 5.2+ e ambiente genérico de 32 bits), ele suporta anos (na totalidade) 1902 a 2037 :

O intervalo válido de um carimbo de data / hora é normalmente de Fri, 13 Dec 1901 20:45:54 UTCFri, 13 Dec 1901 20:45:54 UTC a Tue, 19 Jan 2038 03:14:07 UTC . (Estas são as datas que correspondem aos valores mínimos e máximos para um inteiro assinado de 32 bits.) Além disso, nem todas as plataformas suportam timestamps negativos, portanto, seu intervalo de datas pode ser limitado a não antes da época do Unix. Isso significa que, por exemplo, datas anteriores a Jan 1, 1970 , não funcionará no Windows, algumas distribuições Linux e alguns outros sistemas operacionais. No entanto, o PHP 5.1.0 e versões mais recentes superam essa limitação.

Além do tratamento mais recente baseado em Date/Time é de 64 bits e tem um alcance de -292 bilhões a 292 bilhões de anos , o que provavelmente excede as necessidades da humanidade neste momento.

Limitações do WordPress

O WordPress introduz e herda alguma limitação adicional em sua base de código.

Fluxo de dados

Do ponto de vista básico do stream de trabalho do usuário, há dois processados ​​relacionados à data:

  • a input de data no formulário de edição pós deve ser processada corretamente e salva no database
  • A data salva no database deve ser corretamente lida e mostrada na interface

Note-se que estes são processos tecnicamente completamente diferentes e independentes. Como explicado ainda mais, suas gamas não se sobrepõem e salvar a data correta não é igual a capacidade de lê-lo corretamente no ambiente WordPress.

Limites explícitos

  • O editor de postagens do WordPress em admin permite um intervalo de anos, que pode ser enviado como data de publicação, de 100 a 9999
  • _wp_translate_postdata() processa o ano (enviado como número distinto do formulário) e:
    • sanitizá-lo para não-negativo > 0
    • valida usando wp_checkdate() , que chama checkdate() nativo do PHP checkdate() , que impõe limite de 1 a 32767

Limites implícitos

  • strtotime() function PHP strtotime() é usada várias vezes e está sujeita ao carimbo de data / hora Unix acima mencionado, no nível mais baixo em mysql2date() que afeta todas as leituras de datas do database, faixa 1902 a 2037 herdada
  • O WordPress retorna à expressão regular para a análise da data em get_gmt_from_date() , que espera que o ano seja ([0-9]{1,4}) , limitando-o de 1 a 9999 , forte possibilidade de processamento semelhante em outras funções que exigirão mais auditoria completa do código a ser enumerada

Possibilidade de soluções alternativas

  • wp_checkdate() possui o filtro wp_checkdate , que permite replace esta verificação de validação
  • O resultado apontado para o usuário final passa por date_i18n() que tem o filtro date_i18n , teoricamente, permite interceptar completamente e re-processar a saída das datas para a interface, no entanto, é desafiador se a function for passada já fora do alcance ( false ) da input do timestamp

Conclusões

Para fins práticos e portabilidade de dados, o período de exibição do WordPress parece ser igual ao do timestamp de Unix de 32 bits e consta dos anos 1902 a 2037 inclusive .

Para qualquer operação de data de publicação fora deste ambiente de alcance, deve ser auditada (intervalo de 64 bits de timestamps Unix, funcionamento de fato do MySQL ou armazenamento alternativo de database para os valores). Para intervalos mais longos ( abaixo de 1000, acima de 9999 ) é provável que sejam necessárias quantidades consideráveis ​​de código personalizado.

Para qualquer implementação de datas arbitrárias, faz sentido:

  • guarde-os no MySQL em formato não sujeito a limitações do database
  • processo em PHP usando o código personalizado com Date/Time e / ou as funções do WordPress auditadas para não serem afetadas pelos limites do timestamp do Unix

Cama de teste de código

O código a seguir e o grupo de anos escolhido manualmente foram utilizados para pesquisa acima e teste de conclusões:

 require ABSPATH . '/wp-admin/includes/post.php'; $timestamp_size_info = array( 'PHP_INT_SIZE' => PHP_INT_SIZE, 'PHP_INT_MAX' => number_format( PHP_INT_MAX ), 'min timestamp' => date( DATE_ISO8601, - PHP_INT_MAX ), 'zero timestamp' => date( DATE_ISO8601, 0 ), 'max timestamp' => date( DATE_ISO8601, PHP_INT_MAX ), ); r( $timestamp_size_info ); // hand picked set of years to test for assorted limits $years = array( 'negative' => - 1, 'zero' => 0, 'one' => 1, 'wp min' => 100, 'mysql first' => 1000, 'before unix' => 1899, 'unix first' => 1902, 'current' => 2013, 'unix last' => 2037, 'after unix' => 2039, 'mysql last, wp max' => 9999, 'after checkdate' => 33000, ); // simulates form submission data $post = array( 'post_type' => 'post', // shut notice 'edit_date' => 1, 'aa' => 1, 'mm' => '01', 'jj' => '01', 'hh' => '00', 'mn' => '00', 'ss' => '00', ); // add_filter( 'wp_checkdate', '__return_true' ); foreach ( $years as $name => $year ) { $post['aa'] = $year; $translated = _wp_translate_postdata( false, $post ); if ( is_wp_error( $translated ) ) { // wp_checkdate() failed r( array( 'year' => $year . " ({$name})", 'translated valid' => false ) ); } else { $post_date = $translated['post_date']; $post_date_gmt = $translated['post_date_gmt']; $translated_valid = (string) $year == substr( $post_date, 0, strpos( $post_date, '-' ) ); $mysql2date = mysql2date( DATE_ISO8601, $post_date ); $mysql2date_valid = (string) $year == substr( $mysql2date, 0, strpos( $mysql2date, '-' ) ); r( array( 'year' => $year . " ({$name})", 'post_date' => $post_date, 'translated valid' => $translated_valid, 'post_date_gmt' => $post_date_gmt, 'mysql2date' => $mysql2date, 'from sql valid' => $mysql2date_valid, ) ); } }