Recherche avancée

Sur d’autres sites (9689)

• Anomalie #3779 : Erreur ""Un dossier temporaire est manquant pour télécharger les fichiers"

  7 mai 2016, par Franck Dalot

  Buenos dias, :-)
  necesito mas informaciones para tratar de reproducir el problema
  version de PHP ?
  Version de spip 3.1.x ; 3.0.x ; 2.1.x ?
  Se trata de una version NATIVA o de un sitio que ,por ejemplo paso de una version 3.0.x a una version 3.10x ?
  tipo del’magen ?jpeg ?gif ?...

• Evolution #3361 : Tri par défaut des entrées des menus du bandeau de l’espace privé

  6 décembre 2014, par tcharlss (*´_ゝ｀)

  Voilà ma petite proposition de patch et mes explications (un peu verbeuses, mais ça m’aide à retenir).

  Dans http://core.spip.org/projects/spip/repository/entry/spip/prive/squelettes/inclure/barre-nav.html#L46, c’est la boucle , ligne 46, qui affiche les entrées.
  Tel quel, on ne peut pas faire de tri au moyen de {par xxx}, car la chaîne de langue n’est pas contenue dans #VALEUR{menu}, juste le nom de l’entrée i18n associé :
  

  array (size=6)
    ’auteurs’ => 
      object(Bouton)[301]
        public ’icone’ => string ’’ (length=0)
        public ’libelle’ => string ’icone_auteurs’ (length=13)
        public ’url’ => null
        public ’urlArg’ => null
        public ’url2’ => null
        public ’target’ => null
        public ’sousmenu’ => null
    ’rubriques’ => ...
  

  
  (Note : dans la boucle DATA, l’objet « Bouton » est traité comme un tableau associatif).
  Pour faire le tri alphabétique, il y a juste 2 points à traiter :

  • Rajouter la chaîne de langue dans les valeurs. Les premières lettres suffiront pour le tri.
  • Faire en sorte que cette paire clé/valeur soit au début du tableau. Anéfé, dans une boucle DATA, quand les #VALEUR sont des tableaux associatifs, {par valeur/toto} ne fonctionne pas. En revanche, on peut faire {par valeur} tout court et ça va prendre en compte la valeur associée à la première clé du tableau.

  Donc concrètement, en ajoutant 'tri' => 'chaine de langue' au début du tableau de chaque entrée, on peut faire {par valeur} dans la boucle et le tour est joué.
  Je propose 2 patchs, au choix :

  Patch A¶

  Dans le squelette barre_nav.html : juste avant la boucle DATA qui affiche les entrées, on fait une boucle qui modifie le tableau qui l’alimente (dans le patch, on fait gaffe au espaces blancs, mais là c’est pour la lisibilité).

  [(#REM) prépare les données des entrées ]
  #SETsousmenu,#ARRAY
  #SETentree,#ARRAY#CLE,#ARRAY
  
      tri,#VAL#VALEURlibelle|_T|replace’\s+’,’’|substr0,3|strtolower,
  
      icone,#VALEURicone,
  
      libelle,#VALEURlibelle,
  
      url,#VALEURlibelle,url,
  
      urlArg,#VALEURurlArg,
  
      url2,#VALEURurl2,
  
      target,#VALEURtarget,
  
      sousmenu,#VALEURsousmenu
  
  
  
  #SETsousmenu,#GETsousmenu|array_merge#GETentree
  [(#REM) Affiche les entrées ]
  ...
  

  Patch B¶

  Dans boutons.php, on ajoute $this->tri      = strtolower(substr(preg_replace('/\s+/','',_T($libelle)),0,3)); à la classe Bouton et on fait en sorte que ce soit la première donnée renvoyée.
  Du coup dans le squelette barre_nav.html il suffit de rajouter {par valeur}.

• Anomalie #3461 (Nouveau) : bug sur les urls à cause d’une mauvaise global $profondeur_url

  4 juin 2015, par Maïeul Rouquette

  Le symptome¶

  de temps en temps (mais assez fréquemment dans mon cas) lorsqu’on a un site dans un sous repertoire, les urls produite par #URL_ARTICLE et co contiennent des "../". Conséquent, lorsqu’on clique on remonte d’un niveau, et du coup on tombe sur une page 404.

  La cause¶

  Visiblement d’après https://core.spip.net/projects/spip/repository/revisions/20729 la cause serait une mauvaise globale $profondeur_url.
  Je cite ESJ

  Enfin compris pourquoi SPIP compile parfois des squelettes où la globale profondeur_url est incorrecte. Lorsqu’on place dans ecrire/.htaccess une redirection comme "ErrorDocument 403 / ?page=403", curieusement Apache met dans $_SERVER[’REQUEST_URI’] l’URL initiale (donc avec .../ecrire/...) tandis qu’il met dans $_SERVER[’SCRIPT_NAME’] l’URL de redirection (dans l’exemple ci-dessus une page à la racine). Du coup, la compilation de cette page à la racine se fait avec une profondeur d’URL qui est celle de ecrire/ et non de la racine. Pour peu que cette page et ses inclusions soient mises en cache, c’est toutes les autres pages qui les partagent qui se retouvent avec de mauvaises URL.

  Les tentatives de résolution¶

  Deux commits en 2.1 ont tenté de résoudre les pb :
  https://core.spip.net/projects/spip/repository/revisions/20729
  et https://core.spip.net/projects/spip/repository/revisions/20762

  Ils ont été reporté en 3.0 par
  - https://core.spip.net/projects/spip/repository/revisions/20744
  - https://core.spip.net/projects/spip/repository/revisions/20745
  puis annulé car visiblement non pleinement fonctionnels en

  - https://core.spip.net/projects/spip/repository/revisions/20746
  - https://core.spip.net/projects/spip/repository/revisions/20747

  à ma connaissance c’est le point mort depuis