Recherche avancée

Sur d’autres sites (11613)

• Evolution #3791 : Driver generic acces base de données

  7 juin 2016, par Alain G.

  Je retiens un encouragement à poursuivre mon projet.

  Je me suis fixé comme objectif d’être le plus possible compatible ascendant avec la version actuelle. Il devrait donc être possible à terme de conserver la gestion de plusieurs bases de données simultannement via la variable globale $GLOBALS|’db’]

• Evolution #3479 (Nouveau) : Documents liés implicitement empêchant la suppression d’une rubrique

  10 juin 2015, par Pascal Verrier

  (requalification en demande d’évo du ticket https://core.spip.net/issues/3462)

  Bonjour,

  Demande concernant l’établissement automatique et implicite de liens entre les documents et leurs utilisations.

  Cas d’utilisation (vécu) :

  • SPIP 3.0 ;
  • Dans Configuration > Contenu du site (ecrire/?exec=configurer_contenu) > bloc Documents joints, Rubriques n’est pas coché (c’est ainsi par défaut sur SPIP 3) ;
  • Je crée une rubrique et y insère (Texte explicatif) le code d’un ou plusieurs documents déjà utilisés ailleurs (articles), via <docn></docn> ou autre modèle ;
  • Lors de l’enregistrement SPIP tisse implicitement les liens entre cette rubrique et ces documents ; la fonctionnalité "téléchargement pour les contenus" n’étant pas active sur les rubriques, les documents liés ne sont pas affichés en bas de page rubrique dans l’espace privé (seule la mention "N documents", sous l’identifiant de rubrique, révèle ces liens) ;
  • Le site vit sa vie et après un certain temps les articles de la rubrique sont supprimés ou déplacés, la rubrique ne contient plus aucun article, et sera supprimée.

  Les problèmes rencontrés :

  • La rubrique continue d’être affichée dans le système de menus, or elle ne contient plus aucun article ; il semble que ce soit voulu, la boucle RUBRIQUES considérant comme active une rubrique dès l’instant où elle contient des documents joints (Cf. http://www.spip.net/fr_article904.html) (1) ; comme nous n’avions pas compris que ce lien existait, impossible de comprendre pourquoi cette rubrique continuait à être affichée dans les menus...
  • La rubrique ne peut pas être supprimée : le lien de suppression n’est en effet pas affiché tant que ces documents liés existent...
  • Seul indice pour comprendre ce qui se passe, la mention "N documents" sous l’identifiant de rubrique... pas très clair. (2)
  • En supprimant le contenu du Texte explicatif, en réenregistrant, ces liens persistent ; la rubrique semble pourtant totalement vide et il est toujours impossible de la supprimer, et elle remonte toujours dans les menus...
  • Enfin, il a fallu supprimer un à un, depuis la médiathèque, les liens existants entre les documents utilisés et la rubrique : c’est gérable avec très peu de documents, ça devient impossible avec beaucoup de documents surtout si on a supprimé les shortcodes dans le Texte explicatif, car comment savoir quels documents sont liés avec cette rubrique ?...

  Les évos potentielles proposées :
  (1) Ne plus considérer une rubrique comme active si elle ne contient que des documents joints (sans articles directement ou indirectement rattachés) => résoudrait l’apparition dans les menus d’une rubrique sans aucun contenu réel (si on considère, c’est mon cas, qu’une rubrique est un élément d’organisation et non pas de contenu comme le sont les articles).
  (2) Dans la capture jointe on peut voir dans le cadre rouge l’élément ajouté dans l’affichage d’une page rubrique dans l’espace privé, lorsque l’option de téléversement de documents est activée ; lorsqu’elle n’est pas activée, aucun rappel des documents utilisés => on pourrait envisager de conserver cet affichage dans tous les cas, excepté le bouton "Ajouter un document" (étant donné que l’ajout n’est pas activé). L’intérêt est que l’on peut ici défaire facilement ces liens, et que la présence de ces éléments permet de comprendre de manière plus intuitive que si la rubrique ne peut être supprimée, c’est probablement à cause de ces éléments...

• Révision 24590 : Fix petite salade autour de la suppression des resultats de recherche trop vieux :

  29 mai 2020, par cedric@yterium.com

  - on utilise le champ maj comme indice de peremption qui est au format timestamp
  - sous mysql, le champ maj est donc rempli avec la date mysql equivalente a NOW, mais la compairaison issue de spip_mysql_date_proche() se faisait sur la date php
  - sous sqlite, le champ maj est donc rempli avec la date sqlite, non equivalente a NOW qui est fourni par php
  - dans la recherche on faisait une fois la comparaison avec NOW avant recherche et une fois la comparaison avec la date php
  On remets donc tout d’equerre :
  - dans preparer_recherche on utilise toujours sql_date_proche() pour la comparaison
  - dans req/mysql on utilise NOW si sql_date_proche concerne un champ maj (c’est un peu un hack mais bon)
  - sous sqlite on emule le format timestamp avec une date php qui est bien coherente avec le NOW fournit lui meme par une date php