Recherche avancée

Sur d’autres sites (9151)

• nomenclature #3465 : Nouvelle balise : #LOGO

  6 juin 2015, par tetue tetue

  Comme actuellement, c’est-à-dire rien si l’article n’a pas de logo associé :)

  La balise #LOGO n’apporte par de nouveau fonctionnement : c’est un raccourci de saisie. Ce ticket a juste vocation à simplifier la nomenclature, faciliter l’écriture dans les squelettes, sans considération du comportement, qui reste inchangé.

  NB : les balises spécifiques #LOGO_OBJET restent pertinentes, pour, par exemple, pouvoir comme actuellement disposer de #LOGO_RUBRIQUE dans une boucle ARTICLES, où l’on aura affiché le logo de l’article (s’il existe, donc) simplement avec #LOGO.

• Anomalie #3462 (Nouveau) : Gestion des documents utilisés dans les rubriques - suppression impossi...

  5 juin 2015, par Pascal Verrier

  Bonjour,

  Je constate une modification liée à l’utilisation de documents/images au sein du texte explicatif d’une rubrique.
  Dans SPIP 2.1.27 l’édition de rubrique permet l’ajout de documents (bloc Ajouter une image à gauche), cette fonctionnalité a apparemment été supprimée dans la 3.0.19.

  Cela n’interdit pas de saisir des codes type (correspondant à des éléments de la médiathèque chargés auparavant) dans le texte de description de la rubrique, ce qui permet d’utiliser ces contenus dans la présentation d’une rubrique : ils sont bien affichés, mais contrairement à ce qui se passait sur les versions précédentes, on n’a pas en bas de page rubrique du backoffice (exec=naviguer&id_rubrique=N) le rappel des documents liés, or en regardant dans la médiathèque on peut constater que le lien a bien été réalisé (lors de l’enregistrement) entre les documents utilisés et la rubrique.

  Cela se complique lorsque l’on décide de supprimer une rubrique utilisant, ou ayant utilisé des documents.

  Si je reprends ma rubrique, j’en supprime ou déplace tous les articles, j’en supprime le contenu texte, je n’obtiens jamais le bouton "Supprimer cette rubrique". En fait les documents utilisés y sont liés et tant que ces liens existent la suppression est impossible. C’est le même comportement que sur les versions précédentes* à cela près que l’absence de la liste des documents liés (normalement affichés en bas de page, ou à gauche en édition) n’aide pas vraiment à comprendre pourquoi cette rubrique ne peut être supprimée. Seul indice, sous l’identifiant de rubrique est indiqué "N documents". Autre curiosité la rubrique est d’office considérée comme active, et elle apparaît sur l’espace public, même si elle ne contient aucun article. C’est ainsi que l’on se retrouve avec une rubrique vide, impossible à supprimer, et affichée dans les menus de l’espace public.

  En supprimant manuellement les liens document/rubrique depuis la médiathèque le lien "Supprimer cette rubrique" réapparaît.

  (* : je ne suis pas certain par ailleurs que le fait de ne pas pouvoir supprimer une rubrique à laquelle des documents sont liés soit réellement justifié)

  Ce choix de supprimer l’ajout de documents dans l’édition de rubriques est-il intentionnel ? Pourrait-on retrouver le mécanisme existant dans les articles et dans SPIP 2.1 ?
  Serait-il envisageable de pouvoir supprimer directement une rubrique vide sans avoir à se préoccuper de l’existence de ces liens avec les documents ?
  Merci.

• Anomalie #3386 (Nouveau) : Spip derrière Varnish : port non-standard dans l’URL ?

  13 février 2015, par Mathieu MD

  Spip ajoute intempestivement le port aux URL qu’il génère quand celui-ci est non-standard (ie. ni 80 ni 443). Ça pose un problème quand le serveur applicatif (Apache+PHP, Nginx+PHP, etc.) se trouve derrière un reverse proxy (Varnish) sur la même machine, et écoute donc non pas sur 80 mais sur 81 ou 8080, par exemple.

  Ça casse notamment l’URL de `spip_admin.css` et du SPIP-CRON en toute fin de page.

  Pour « corriger » sur mon installation, j’ai modifié la fonction `url_de_base()` du fichier `ecrire/inc/utils.php` en commentant ce bloc :
  

    if (isset($_SERVER[’SERVER_PORT’])
      AND $port=$_SERVER[’SERVER_PORT’]
      AND strpos($host," :")==false)
      if ($http=="http" AND $port !=80) $host.=" :$port" ;
      if ($http=="https" AND $port !=443) $host.=" :$port" ;
    
  

  Évidemment c’est un peu barbare... Pourquoi ne pas utiliser l’URL de base spécifiée dans l’interface d’admin (Configuration > Identité du site : Adresse (URL) du site public) ? Le commentaire de la fonction `url_de_base()` précise que c’est parce que `meta(adresse_site)` peut être fausse ; mais alors à quoi bon la demander et à quoi sert-elle ?

  Bref, il devrait être possible de servir Spip sur un port non-standard sans pour autant casser les URLs.

  Pour info :

  • L’architecture initiale (traditionnelle) : Client -> Nginx (port 80) -> PHP (Spip)
  • Nouvelle archi avec reverse proxy : Client -> Varnish (port 80) -> Nginx (port 81) -> PHP (Spip)

  Versions :

  • SPIP 3.0.17 [21515]
  • Nginx 1.2.1
  • Varnish 3.0.2
  • Debian 7.8 Wheezy