Recherche avancée

Sur d’autres sites (3962)

• Révision 22452 : report de r22346

  29 octobre 2015, par brunobergot@gmail.com

  Fix #3430 : les boucles avec langue utilisaient lang_select_public() qui changeait sauvagement la langue en debut de boucle, sans la restaurer en fin de boucle, provoquant des bugs de contexte
  On modifie la compulation des boucles : lang_select_public() appelle toujours lang_select(...) avec eventuellement la langue inchangee, et la boucle finit par un lang_select() qui depile et restaure la langue pour l’iteration suivante.

• 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}.

• Evolution #3459 (Nouveau) : Essayer d’éviter les spams de referrer

  2 juin 2015, par kent1 -

  Ce serait pas mal d’essayer de les restreindre un peu

  Regarder comment fait Piwik ici : http://piwik.org/blog/2015/05/stopping-referrer-spam/?pk_campaign=org_newsletter_2015_06&pk_medium=email&pk_source=piwik_org_newsletter

  Avec un début de liste ici : https://github.com/piwik/referrer-spam-blacklist

  On pourrait peut être fonctionner un peu comme no-spam ?

  à développer en sous-plugin peut être ?

  Des avis ?