Recherche avancée

Sur d’autres sites (13640)

• Anomalie #3087 (Nouveau) : contenu mixte http/https dans le CSS

  7 novembre 2013, par Severo Lipari

  Je viens de tomber sur le problème décrit ici : http://thread.gmane.org/gmane.comp.web.spip.devel/61095/focus=61094.

  Actuellement, la propriété suivante, dans un CSS à compresser,

  background : url(../prive/images/fond-gris-anim.gif) ;
  

  sera convertie en

  background:url(http://www.domaine.tld/prive/images/fond-gris-anim.gif) ;
  

  Si j’ai bien compris la réponse dans le thread de spip-dev, il faudrait plutôt remplacer par

  background:url(//www.domaine.tld/prive/images/fond-gris-anim.gif) ;
  

• Anomalie #4482 (Nouveau) : Passer définitivement Bigup sur la forge communautaire

  30 avril 2020, par RastaPopoulos ♥

  Bigup n’a plus rien à faire sur Github : il est officiellement dans la dist, donc maintenu par l’équipe noyau, pas sur un truc privé. Donc :
  - le dépôt sur la forge communautaire n’a plus à être un miroir du Github
  - la description git-svn externals ".gitsvnextmodules" des plugins-dist ne doit plus du tout pointer sur Github, mais sur le vrai dépôt du core

  Et ça devrait être fait avant la sortie 3.3.

  (Conséquemment yavait une bidouille pour checkout pour dire que "celui de Github" on l’excluait de spip-3.2, etc, mais à partir du moment où ça devient une source comme les autres, ce ne sera plus possible. Donc va bien falloir savoir comment réellement décrire que tel plugin est dans telle branche de SPIP, pas avec des hacks comme ça. Là en fait toutes les branches récupèrent uniquement la liste du master, ça va pas… Si on décide de virer Brèves ou ce genre, faut toujours que ça le prenne pour les précédentes.)

• Evolution #2173 : Date de création / publication

  3 juillet 2017, par tcharlss (*´_ゝ｀)

  Je reporte ici le ticket #3966 qui fait doublon : l’idée pourrait être étendue à tout type de contenu.

  ---

  Il n’y a pas longtemps j’ai eu besoin de faire des statistiques éditoriales : on voulait connaître l’évolution du nombre d’articles publiés chaque année.
  Mais les données ne sont pas fiables : les utilisateurs avaient pour habitude de faire des « remises en avant » en changeant la date de publication de vieux articles pour les refaire apparaître en page d’accueil. Donc un article écrit en 2014 mais remis en avant en 2017 se retrouve compté comme ayant été publié en 2017.

  Et c’est valable pour tout les objets éditoriaux en fait : on ne conserve pas leur date de création / 1ère publication.
  Certains objets ont une date de publication, mais elle peut être changée. Et d’autres objets n’ont tout simplement pas de date (hormis maj).

  Donc je me demandais s’il ne serait pas pertinent d’avoir cette information de façon générique pour tous les objets éditoriaux, un champ date_creation par exemple qui serait rempli soit à la création, soit à la 1ère publication, et qui ne bougerait pas ensuite.

  Ci-dessous, un tableau récapitulatif de ce qu’on a actuellement pour les principaux objets.

  Objet	Champ de date	Date pérènne ?
  Articles	date	Non : peut être modifiée manuellement
  Brèves	date_heure	Non : peut être modifiée manuellement
  Rubriques	date	Oui
  Auteurs	X	X
  Mot-clé	X	X
  Groupe de mots-clés	X	X
  Document	date	Oui
  Forum	date_heure	oui
  Pétition	X	X