J'utilise un plugin sitemaps qui, de manière très complexe, définit le fuseau horaire de <lastmod>
(c'est-à-dire l'heure de la dernière modification) pour les publications au format GMT.
Temporairement, jusqu'à ce que le développeur du plugin le corrige, je dois appliquer un fuseau horaire personnalisé sur le plugin . Le moyen le plus simple et le plus simple que j'ai trouvé est d'ajouter quelque chose comme date_default_timezone_set( 'America/New_York');
juste après le premier <?php
du fichier chargé de générer les sitemaps.
Cela fonctionne et cela ne semble pas affecter les horodatages affichés sur le reste du site. Alors, je peux y aller avec ça? Ou bien y a-t-il une meilleure solution?
http://codex.wordpress.org/Function_Reference/get_gmt_from_date } _
Remplacez toutes les instances de get_the_date
ou the_date
par echo get_gmt_from_date(get_the_date('Y-m-d H:i:s'))
. Ce n'est pas une solution miracle, c'est un moyen de corriger vos sitemaps.
MODIFIER:
WordPress SEO exécute ses dates brutes depuis MySQL via une fonction WP appelée mysql2date
, qui à son tour appelle date_i18n
. date_i18n
possède un filtre pratique auquel vous pouvez vous associer pour changer la date:
<?php
add_filter('date_i18n', 'wpse57195_filter_date', 10, 4);
/**
* Changes the date on WordPress SEO's sitemaps
*
* @return string The Date
*/
function wpse57195_filter_date($date, $format, $timestamp, $gmt)
{
// if this isn't a sitemap page, bail
if(!get_query_var('sitemap'))
return $date;
// W3C Time format with -05:00 for central time
// NOTE: this doesn't account for daylight saving time
$f = 'Y-m-d\TH:i:s-05:00';
return $gmt ? gmdate($f, $timestamp) : date($f, $timestamp);
}
Dans la fonction accrochée, vous pouvez rechercher la variable de requête du plan Sitemap et modifier l’heure selon vos besoins. Pour conserver les plan du site , vous devez utiliser le format de date W3C , qui inclut un champ +/- pour le fuseau horaire. -05: 00 est le nombre correspondant à l'heure avancée du centre. Vous pouvez envelopper dans un plugin ci-dessus et l'activer jusqu'à ce que le plan du site puisse être corrigé.
Actuellement, la fonction intégrée current_time()
s'attend à ce que la fonction date_default_timezone_set()
ne soit jamais utilisée.
L’inspection du code de current_time()
a confirmé cette hypothèse, car cette fonction formate le résultat à l’aide de la fonction PHP intégrée date()
(affectée par le fuseau horaire); en fait, il semble que Wordpress réinitialise toujours le fuseau horaire sur UTC (une echo date_default_timezone_get()
placée en haut et en bas de wp-config.php
dans une installation propre de WordPress le prouvera).
Non. (bon, vous pouvez immédiatement le changer une fois que vous avez terminé, mais c'est sujet aux erreurs.)
De plus, quoi que vous fassiez, ne remplacez pas date_default_timezone_set () dans votre wp-config.php
; wp-settings.php
définit ceci sur UTC
et vous ne devez pas le changer.
Le réglage Europe/Londres, par exemple (qui a une heure d'avance sur l'heure GMT en été), donnera à l'heure GMT une heure d'avance sur ce qu'elle devrait être - vous pouvez vérifier via /wp-admin/options-general.php
Cela signifie essentiellement que les valeurs du fuseau horaire système /etc/timezone
et de la valeur date.timezone
ini de PHP sont ignorées par WordPress.
IMHO, il devrait y avoir une sorte d'avertissement dans le noyau WordPress s'il est défini sur une valeur autre que UTC, mais il n'y en a pas, alors méfiez-vous.