Recherche avancée

Sur d’autres sites (3886)

• Anomalie #4187 : Connecté en Anglais (langue principale français) pas de bouton pour ajouter les p...

  4 octobre 2018, par jluc -

  En effet, en français, pas de problème, mais si je change ma langue perso pour "Anglais" et que je fais dans admin_plugin la recherche des plugins "Etiquettes" ou "objets_virtuels", ou "Des jeux dans vos articles" alors l’affichage est cassé car il y a un une fin de liste /ul qui s’insère au milieu de la liste (au milieu de la boucle).

  Le squelette en cause semble être dû à <span class="CodeRay">[(#VALEUR{description}|extraire_multi|propre)]</span> dans svp/formulaires/inc-plugins_trouves.html

  On dirait que propre se prend les pieds dans les énumérations générées par « -* » qu’il y a dans ces descriptions.

  Par exemple :
  

  <span class="CodeRay"><span class="tag">span> <span class="attribute-name">lang</span>=<span class="string"><span class="delimiter">'</span><span class="content">fr</span><span class="delimiter">'</span></span><span class="tag">></span>Le plugin Étiquettes permet de créer facilement...
  
  -* Une liste à cliquer (sur les mêmes principes que les cases à cocher)
  
  -* Aucune aide
  
  <span class="tag"></span></span></span>

  devient :
  

  <span class="CodeRay"><span class="tag">span> <span class="attribute-name">lang</span>=<span class="string"><span class="delimiter">"</span><span class="content">fr</span><span class="delimiter">"</span></span><span class="tag">></span>Le plugin Étiquettes permet... 
  
  <span class="tag">span> <span class="attribute-name">class</span>=<span class="string"><span class="delimiter">"</span><span class="content">spip</span><span class="delimiter">"</span></span><span class="tag">></span><span class="tag"></span> Une liste à cliquer (sur les mêmes principes que les cases à cocher)<span class="tag"></span><span class="tag"></span> Aucune aide
  
  <span class="tag"></span><span class="tag"></span><span class="tag"></span></span></span></span>

  Une fermeture de la dernière ligne de l’énumération se fait APRÉS la fermeture du div qui suit, alors qu’elle devrait se faire avant.

  Rencontrant cette fermeture de div, le navigateur voit qu’il a un li et une ul en cours et les ferme de force. Juste aprés il rencontre les vraies fermetures... et c’est la liste principale (plugins énumérés par la boucle) qu’il ferme alors. Si mal que les plugins après se trouvent hors liste, et sans style.

  La particularité de la situation, pour propre, c’est qu’il y a du html collé juste après une liste, et que propre considère que ça fait partie de la dernière ligne de la liste.

• Anomalie #3055 (En cours) : Autorisation sur les listes d’objets

  5 mai 2015, par Eric Lupinacci

  En fait, c’est à mon avis un problème plus général, de rigueur dans l’appel des autorisations en entrée des pages mais aussi de stratégie de définition des autorisations qui sont malheureusement assez rarement arborescentes.

  Si on prend les pages objet comme article, rubrique et auteur par exemple, elle commencent toutes par une autorisation :
  

  (#AUTORISERvoir,article,#ID_ARTICLE ou
  (#AUTORISERvoir,rubrique,#ID_RUBRIQUE ou
  (#AUTORISERvoir,auteur,#ID_AUTEUR
  

  
  Cependant d’ailleurs seul l’autorisation article_voir est définie, les autres renvoyant sur l’autorisation par défaut. Mais au moins une autorisation est appelée systématiquement quelque soit le moyen avec lequel on arrive sur cette page.
  A partir de là si il existe un bouton qui envoie sur cette page il faut le conditionner par cette autorisation (code HTML) et si c’est un menu créé automatiquement alors là il faut créer une autorisation de menu qui appelle l’autorisation de voir et pas le contraire à mon avis.

  Donc si on étend ça aux pages articles, auteurs et rubriques je suis d’accord qu’il faudrait une autorisation voir_xxxx (ce qui n’est pas le cas actuellement) qui serait appelée en entrée de la page comme l’exemple ci-dessous pour la page articles :
  

  (#AUTORISERvoir,_articles
  

  
  et il faudrait alors coder l’autorisation du menu Articles de cette façon :
  

  function autoriser_articles_menu_dist($faire, $type, $id, $qui, $opt) 
      return autoriser(’voir’, ’_articles’) ;
  
  

  
  En effet, la décision d’afficher ou pas le menu est indépendante du fait de voir ou pas la page articles mais doit s’appuyer dessus si on décide de ne pas présenter un lien qui mène vers une page interdite.
  Et il faudrait systématiser cela pour tous les plugins objet du core à mon avis.

  En second lieu il faudrait faire une passe sur le code des autorisations actuelles pour imbriquer un peu plus les autorisations de façon arborescente ce qui leur donnerait plus de lisibilité car parfois elles sont identiques sans qu’on s’en rende compte car le code est dupliqué.

• Anomalie #4374 (Nouveau) : Sauvegarde au format SQLite impossible avec les dernières version de Ma...

  25 août 2019, par Olivier Tétard

  Les dernières versions de MariaDB exportent utilisent current_timestamp() en tant que fonction quand on exporte le format des tables SQL (via la commande SHOW CREATE TABLE). C’est ce résultat qui est utilisé pour créer les tables dans la base SQLite, or, l’utilisation de la fonction current_timestamp() n’est pas possible avec SQLite.

  Ce problème a été introduit avec les dernières version de MariaDB (voir par exemple ce rapport de bug ou cette discussion sur StackOverflow. Ce problème est par ailleurs évoqué sur les forums de SPIP, ici.

  Un correctif bête et méchant est de modifier le code de SPIP pour permettre de changer l’appel à la fonction current_timestamp() vers la variable CURRENT_TIMESTAMP. Ça peut soit être fait dans le code de la fonction base_copier_table() en rajoutant le bout de code suivant ligne 604 :

  <span class="CodeRay">        <span class="keyword">foreach</span>(<span class="local-variable">$desc_source</span>[<span class="string"><span class="delimiter">"</span><span class="content">field</span><span class="delimiter">"</span></span>] <span class="keyword">as</span> <span class="local-variable">$k</span> => <span class="local-variable">$v</span>) {
              <span class="local-variable">$desc_source</span>[<span class="string"><span class="delimiter">"</span><span class="content">field</span><span class="delimiter">"</span></span>][<span class="local-variable">$k</span>] = <span class="predefined">str_replace</span>(<span class="string"><span class="delimiter">"</span><span class="content">current_timestamp()</span><span class="delimiter">"</span></span>, <span class="string"><span class="delimiter">"</span><span class="content">CURRENT_TIMESTAMP</span><span class="delimiter">"</span></span>, <span class="local-variable">$v</span>);
          }
  </span>
  Télécharger

  (L’idéal serait de vérifier que la base de données source utilise bien la dernière version de MariaDB histoire d’éviter des appels inutiles à str_replace).