Recherche avancée

Sur d’autres sites (4333)

• Evolution #4175 : Publier les Auteurs qui ont un document joint ?

  27 septembre 2018, par Peet du

  Une idée : créer un champ "publié" qui peut prendre les valeurs oui/non (non par défaut).
  Il serait automatiquement mis à "oui" dès qu’un objet publié est associé à cet auteur.
  Avantage : cela allège (considérablement ?) la boucle Auteurs puisque plus besoin de faire une double jointure (table lien + objet publié ou non) qui peut être coûteuse en perf.

  Pour les documents, mettre en place une config :

  • Par défaut, un document associé à un auteur n’est pas publié, et l’auteur non plus.
  • La config propose de tout mettre à "Publie" dès une association document/auteur est faite.

• Révision 23304 : Report de r23258 :

  8 décembre 2016, par marcimat@rezo.net

  Ticket #3860 : Lors du calcul du fichier de caches des pipelines,
  notamment et particulièrement lorsqu’on utilise la balise `` dans un paquet.xml,
  bien faire en sorte d’avoir les chemins des plugins actifs (ou à activer) chargés pour
  tester la présence de la fonction demandée dans la balise ``.

  Sinon, si on vide le cache (depuis l’admin, ou brutalement tmp/cache/*), les crons déclarés dans
  les balises `` ne sont plus activés tant qu’on ne repasse pas sur la page d’administration
  des plugins.

  Du coup, on déplace le chargement des chemins de plugins et options un peu au dessus, pour que
  la précompilation des pipelines ait accès aux fichiers des plugins activés.

  Le petit hic, c’est un léger changement de comportement : les fichiers
  d’options des plugins n’ont plus accès, dans la globale ’spip_pipeline’,
  aux fonctions ajoutés par les balises `` des paquet.xml et plugin.xml,
  (infos complétées après le chargement des fichiers d’options donc).
  Je ne pense pas que ce changement soit gênant.

• Anomalie #3769 (Nouveau) : form_hidden insère un hidden en trop

  13 avril 2016, par jluc -

  La doc spip.net dit : Si on fait un formulaire qui utilise comme action un lien comprenant des arguments, il faut remettre ces valeurs dans des champs hidden .

  Le phpdoc dit : Fournit la suite de Input-Hidden correspondant aux paramètres de l’URL donnée en argument, compatible avec les types_urls.

  Normalement, le résultat de form_hidden devrait uniquement dépendre de la balise sur laquelle il s’applique, fut elle #SELF ou #URL_PAGEtagada

  Or, si la page courante est ?page=truc&id_truc=10, form_hidden insère toujours un hidden pour id_truc=10, même si on l’applique à un argument comme #URL_PAGEtagada dans lequel aucun id_truc n’est mentionné.

  J’imagine que ce comportement est pratique parfois, sur une page truc qui ne s’occupe que d’un seul truc et où toutes les noisettes s’occupent de ce seul truc.

  Mais il est des pages truc qui s’occupent AUSSI d’autres trucs, ou d’autres choses qui n’ont pas de rapport, ou des rapports plus complexes que "toujours tout sur un seul truc", et que ce paramètre id_truc peut gravement perturber.

  Exemple de squelette pour mettre en évidence : fichier truc.html

  DEBUT
  ENV=
  [(#ENV**|unserialize|print_r1)]
  SELF
  #SELF
  SELF|form_hidden
  [(#SELF|form_hidden|htmlspecialchars)]
  url_pagetagada
  #URL_PAGEtagada
  URL_PAGEtagada|form_hidden
  [(#URL_PAGEtagada|form_hidden|htmlspecialchars)]
  FIN
  

  
  Appeler ?page=truc&id_chose=1
  Appeler ?page=truc&id_truc=2
  Dans ce dernier cas, id_truc s’insère de force dans le form de la page tagada