Recherche avancée

Sur d’autres sites (7742)

• Anomalie #3216 : Cron ne se déclenchant plus ?

  19 mai 2014, par Maïeul Rouquette

  J’ai dit dès le début qu’il s’agissait d’un SPIP standard, je n’entendais pas là le fait de ne pas utiliser des plugins, puisque c’est une fonction standard de SPIP ;-). En outre je renvoyais vers un lien qui parlait explicitement d’un plugin.

  En l’occurence il s’agit d’un cron effectué par un plugin. Donc le pb peut venir
  a) soit du mécanisme de cron
  b) soit de la fonction du plugin executé par le cron

  Comme le déclenchement manuel via la liste des travaux fonctionne, il y a tout lieu de penser que le pb est en a) non ?

  Avant de fermer definitivement, attendons 48h de voir si le cron automatique se fait sur la nouvelle version à jour. Si ce n’est pas le cas, je vais essayer d’investiger les changements relevés, mais je ne vois rien qui permettrait d’expliquer ce changement.

• Evolution #3230 (Nouveau) : Ajouter une pagination standard intégrant les informations sur les pag...

  17 juin 2014, par RastaPopoulos ♥

  Nous n’avons pas de modèle de pagination contenant déjà les informations correctes à propos des pages générées, afin de répondre à la bonne pratique 133 :
  http://checklists.opquast.com/fr/oqs-v2/criteria/la-page-des-resultats-de-recherche-indique-le-nombre-de-resultats-le-nombre-de-pages-de-resultats-et-le-nombre-de-resultats-par-page

  Sur les trois informations demandées, le nombre total de résultats et facilement accessible grâce à #GRAND_TOTAL, et il est généralement utilisé en début de page. Ce point-là n’est donc pas un problème.

  En revanche, au moins un de nos modèles de pagination standard, devrait générer les informations suivantes :
  - Le nombre de pages de résultats
  - Le nombre de résultats par page

  Par exemple quelque chose comme "4 pages de 10 articles". À placer avant (ou après, mais je dirais plutôt avant) la liste des liens de pages.

  Idées en plus :
  - cela pourrait être une option à passer pour l’avoir, ce qui permettrait de l’ajouter sur tous les modèles fournis par défaut
  - il faudrait que la chaîne soit personnalisable pas trop difficilement (si on veut mettre "résultats" plutôt que le nom de l’objet par ex)

• Anomalie #3261 : Non prise en compte des champs

  10 septembre 2014

  2h d’investigation de la question... Quelques idées que je mets ici pour voir et vous lire...

  J’imagine donc un champ suppl dans spip_urls mais ne s’agissant pas d’un objet, et vu que les urls peuvent concerner des objets linguistiquement marqués ou non, on l’appelerait multi plutôt que lang.

  Idées, côté "privé" :
  - à chaque création/modification d’objet positionné sur lang_choisie=non ou n’ayant pas ce champ, voir si le titre est en et créer autant d’url que de langues présentes (url=>titre traduit, multi=> langue de la traduction)
  - si l’objet à une langue, soit inhiber le champ multi (un code défini), soit le remplir avec la langue de l’objet. Vérifier le cas où on change la gestion linguistique d’un objet sur un site en cours...
  - Idem pour les recalculs d’urls
  - pour le privé, on peut passer le paramètrre multi et le transmettre aux préférences auteur (ou forcer la dépendance au plugin mutlilang et la gérer) ?

  Côté public :
  - produire les urls (de tout type sauf "page" il me semble) en ajoutant /[code_langue]/ en début d’url (ou un paramètre multi=[code_langue] dans certains cas ?), selon l’#ENVlang...(si on est dans le public) ou...
  - si l’objet a une langue et lang_choisie=oui (ou pas de lang_choisie), on récupère sa langue pour définir #ENVlang
  - si l’objet n’a pas de lang, récupérer la langue de l’auteur ?
  - pour décoder l’url, avec le htaccess on détecte le [code langue] et on convertit en lang=[code_langue] pour avoir la valeur de multi ? Si pas de htaccess. On peut aussi s’en passer et récupérer la valeur de multi encodée en spip_urls pour l’url demandée (?)
  - il faut modifier le cookie de langue s’il est présent.

  ...