Recherche avancée

Sur d’autres sites (8904)

• Conférence sur Piwik le samedi 24 novembre à Supinfo Paris

  5 novembre 2012, par Piwik team

  Le samedi 24 novembre à Supinfo Paris, Ronan CHARDONNEAU, auteur de Piwik, l'alternative Open Source en web analytique aux éditions Eni, donnera une conférence sur Piwik.

  L'objectif de cette conférence est de présenter la communauté Piwik, de montrer les risques d'utiliser Google Analytics pour son site Internet. L'accent sera également mis sur les différences entre Google Analytics et Piwik.

  Cette conférence s'inscrit dans un cycle de conférences dédiées au webmarketing : http://www.boite2.com/emarketing-event-24-novembre-2012/

  Il s'agit d'un événement ouvert à tous.

  Lieu : 23 rue du château Landon 75010 Paris.

  Date et heure : 24 Novembre, la présentation sur Piwik est à 13h30 mais l'événement dure toute la journée avec d'autres conférences intéressantes.

  N'hésitez pas à faire tourner cette invitation autour de vous. Inscription gratuite mais obligatoire via le lien précédent.

  De la part de l'équipe Piwik, merci à Ronan d'aider Piwik à se faire connaître en France. Si vous lisez ceci et que vous êtes un fan de Piwik, n'hésitez pas vous même à présenter Piwik à une conférence ou dans votre entreprise.

• 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
  

• 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