Recherche avancée

Sur d’autres sites (7465)

• Révision 21104 : Report de r21005 : Perf issue sur le lancement du CRON :

  11 janvier 2014, par cedric -

  sur certains serveurs le firewall est réglé pour DROP silencieusement toute requete http sortante : fsockopen attends alors 30s pour lancer la requete à chaque hit avant de rendre la main. cURL lui n’attends pas mais ne sait pas que sa requete echoue. Résultat le CRON ne tourne jamais et le site a un temps de réponse catastrophique.

  Fix :
  - limiter le timeout de fsockopen à 1s au lieu de 30s : si on a pas pu initialiser la connexion http en 1s c’est qu’il y a un soucis
  - lorsque fsockopen echoue, rien ne sert de lancer cURL qui n’aura pas plus de chance ; cURL est utilisé en fallback uniquement si fsockopen n’est pas disponible (cas rare)
  - du coup si fsockopen echoue on passe au lancement old-style avec HTML background (mais ça nous a couté 1s d’attente inutile)

  - si on sait qu’on est sur une telle configuration (et qu’on ne peut pas la changer) on peut inhiber le lancement du cron par fsockopen/cURL avec un
  define(’_HTML_BG_CRON_FORCE’,true) ;
  dans mes_options.php. Cela economisera l’attente inutile.

• Anomalie #3164 : Problème de sauvegarde en MySQL

  7 février 2014, par Franck Dalot

  En spip 2.1, avec comme prefix des table spipdev et avec uniquement dans mes_options :
  

  <?php
$table_prefix = 'spipdev';
?>

  Cela ne fait apparaitre dans la liste que des tables qui porteraient le nom de spip_xxx ET cela fait les sauvegardes avec le prefix spip_xxx au lieu de spipdev_xxx
  Et cela manque toujours des tables, puisqu’il n’y a de cocher que :
  spip_articles (0)
  spip_auteurs (2)
  spip_auteurs_articles (0)
  spip_auteurs_messages (0)
  spip_auteurs_rubriques (0)
  spip_breves (0)
  spip_documents (0)
  spip_documents_liens (0)
  spip_forum (0)
  spip_groupes_mots (0)
  spip_messages (0)
  spip_meta (91)
  spip_mots (0)
  spip_mots_articles (0)
  spip_mots_breves (0)
  spip_mots_documents (0)
  spip_mots_forum (0)
  spip_mots_rubriques (0)
  spip_mots_syndic (0)
  spip_petitions (0)
  spip_referers (0)
  spip_referers_articles (0)
  spip_resultats (0)
  spip_rubriques (0)
  spip_signatures (0)
  spip_syndic (0)
  spip_syndic_articles (0)
  spip_types_documents (164)
  spip_urls (0)
  spip_versions (0)
  spip_versions_fragments (0)
  spip_visites (0)
  spip_visites_articles (0)

  Alors que logiquement, il devrait y avoir :
  spipdev_articles (0)
  spipdev_auteurs (2)
  spipdev_auteurs_articles (0)
  spipdev_auteurs_messages (0)
  spipdev_auteurs_rubriques (0)
  spipdev_breves (0)
  spipdev_documents (0)
  spipdev_documents_liens (0)
  spipdev_forum (0)
  spipdev_groupes_mots (0)
  spipdev_messages (0)
  spipdev_meta (91)
  spipdev_mots (0)
  spipdev_mots_articles (0)
  spipdev_mots_breves (0)
  spipdev_mots_documents (0)
  spipdev_mots_forum (0)
  spipdev_mots_rubriques (0)
  spipdev_mots_syndic (0)
  spipdev_petitions (0)
  spipdev_referers (0)
  spipdev_referers_articles (0)
  spipdev_resultats (0)
  spipdev_rubriques (0)
  spipdev_signatures (0)
  spipdev_syndic (0)
  spipdev_syndic_articles (0)
  spipdev_types_documents (164)
  spipdev_urls (0)
  spipdev_versions (0)
  spipdev_versions_fragments (0)
  spipdev_visites (0)
  spipdev_visites_articles (0)

  Sans fichiers mes_options mais en changeant la ligne 320 par
  

  . preg_replace(',^spip_,', $GLOBALS['table_prefix'].'_', $t)

  
  c’est pareil que si l’on ne changeait pas la ligne.
  Les tables apparaissent en double et ne sont cocher que 26 tables spip_xxx alors qu’il devrait y avoir 33 tables et en plus avec le prefix choisi au moment de l’instal

  En spip 3.1, même avec
  

  
<?php
$table_prefix = 'spipdev';
?>

  
  Cela ne sauvegarde pas les tables avec un autre prefix que spip_XXX

• Anomalie #3227 (Nouveau) : Bug date de publication

  11 juin 2014, par Eric Camus

  SPIP 3.0.16 standard de base (pas de plugins ajouté).

  Si on change à la main (dans le champ) la date de publication en en donnant une erroné ex : 11/06/0014 (erreur sur le 2 de 2014).
  La date une fois validé affiche l’année 14 au lieu de 2014 mais c’est presque normal, la date affiché sur la page "accueil" est 1-1-1970 !! et l’article est toujours en première position.

  Par contre le paramètre "derniere_modif" et uniquement lui dans la base "spip_meta" change à chaque hit sur le site public. Il me semble que cela dé-valide le cache de façon permanente non ?