Recherche avancée

Sur d’autres sites (14276)

• Revision 37011 : Un petit test pour voir si ffmpeg2theora est dispo sur le serveur (pour ...

  6 avril 2010, par kent1@… — Log

  Un petit test pour voir si ffmpeg2theora est dispo sur le serveur (pour l’utiliser au cas où plus tard)

• 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 #3630 : Logo d’auteur et fonction de recherche de logo

  13 août 2016, par b b

  Je dépose ici la discussion qui a eu lieu à ce sujet sur IRC pour en garder une trace :

  < marcimat‎ >  dans id_table_objet() je vois que ça fait un traitement même si on passe ’id_auteur’
  < marcimat‎ >  du coup, je me dis que quête logo
  < marcimat‎ >  pourrait tester si substr($type, 0, 3) !== ’id_’
  < marcimat‎ >  appeler id_table_objet($type)
  < marcimat‎ >  non ?
  < marcimat‎ >  c’est peut être un compromis
  < marcimat‎ >  ou un strcmp
  < phenix_spip‎ >  Pourquoi faire un test ?
  < marcimat‎ >  parce que je vois des calculs dans id_table_objet() systématiques
  < marcimat‎ >  même si on envoie déjà id_truc
  < phenix_spip‎ > ?
  < phenix_spip‎ >  Ha je vois
  < marcimat‎ >  @id_table_objet()
  < Edgard‎ >  Hop http://code.spip.net/@id_table_objet - Hop (sinon) http://code.spip.net/spip.php?page=recherche&recherche=id_table_objet
  < marcimat‎ >  https://core.spip.net/projects/spip/repository/entry/spip/ecrire/base/objets.php#L1066 donc
  < marcimat‎ >  mais effectivement, je pense que ça doit pas gêner si quête_logo est simplifié
  < phenix_spip‎ >  marcimat : ce serai plus logique que le test soit dans id_table_objet non ?
  < marcimat‎ >  enfin modifié pour accepter un vrai type
  < marcimat‎ >  certes, mais c’est déjà plus sensible ^^
  < phenix_spip‎ > ?
  < marcimat‎ >  ok
  < marcimat‎ >  en fait objet_type() teste déjà en enlevant id_
  < marcimat‎ >  donc, y pa pas spécialement besoin
  < phenix_spip‎ >  Ben voilà :)
  < marcimat‎ >  donc là https://core.spip.net/projects/spip/repository/entry/spip/ecrire/base/objets.php#L1070
  < marcimat‎ >  objet_type(’id_auteur’) doit ressortir ’auteur’
  < marcimat‎ >  oui, voilà :)
  < marcimat‎ >  all is fine