Accueil > Contribs à ranger > Révision n°7502 pour SPIP 1.9.1
Révision n°7502 pour SPIP 1.9.1
samedi 30 septembre 2006
Nouvelle revision (N° 7502) pour la série 1.9.1 de spip.
Des détails en suivant le lien :)
Voir en ligne : Changelog du 29 septembre 2006
Discussions par date d’activité
36063 discussions
Le plugin insère #DESCRIPTIF et ce descriptif se calcule en fonction des 1res lignes du texte. Dans les squelettes on (je) utilise plutôt #TEXTE qui automatiquement concatène le chapeau + le texte.
Quand on lit le manuel des balises à propos de #DESCRIPTIF, c’est très éloquent : https://www.spip.net/fr_article3854.html
Je ne me sers pas de la balise #INTRODUCTION, néanmoins c’est elle qu’on devrait utiliser en fait. https://www.spip.net/fr_article3965.html
Vaut-il mieux que je crée une variante article.html pour utiliser #INTRODUCTION, ou bien est-ce une amélioration à apporter au plugin ?
Je ne pense pas être le seul à utiliser chapeau
C’est censé utiliser #INTRODUCTION en priorité, et seulement si cette balise ne renvoie rien, on se rabat sur #DESCRIPTIF : https://zone.spip.net/trac/spip-zone/browser/spip-zone/_plugins_/metasplus/trunk/inclure/metasplus/dist.html#L88
Si ça n’utilise pas l’introduction, c’est qu’il doit y avoir un souci avec la balise #INFO, à investiguer.
Merci de la réponse rapide.
Sur la rubrique où ça me pose souci, j’ai fait le test en insérant
Quel autre test mener ? Désolé mais je ne suis pas développeur, même si je commence à connaître certains basiques
Ah mais attends, c’est comme ça que fonctionne la balise #INTRODUCTION en fait : elle prend en priorité le descriptif, et à défaut le chapeau puis le texte : https://www.spip.net/fr_article3965.html
Donc pas de bug.
Si tu souhaites utiliser le chapeau, crée un squelette inclure/metasplus/article.html :
J’aimerai bien comprendre ce que contient la balise #DESCRIPTIF car la doc spip ne dit rien : https://www.spip.net/fr_article3854.html
OK j’ai trouvé ce qu’est le descriptif. Je ne l’ai pas activé.
Quand je fais le test sur un article de la rubrique incriminée, l’ajout de la balise #INTRODUCTION génère bien le chapeau en 1 et le texte en 2.
Comment trouver l’erreur ?
Effectivement l’aide en ligne est plus bavarde sur l’utilisation de ce champ :
N’hésite pas à te créer un compte sur spip.net et à proposer une amélioration dans le forum de l’article.
Après, son utilisation peut changer selon tes besoins éditoriaux et les squelettes utilisés. Mais très souvent, elle sert juste à avoir un « vrai » résumé avec la balise #INTRODUCTION.
Mais quelle erreur ? Sans descriptif oui, #INTRODUCTION prend le chapo et le texte.
Avec 11000 articles et 15000 urls, le moindre changement peut avoir un impact casse-c...
Ma balise meta description que j’utlise depuis... retourne bien le chapeau en 1er et si pas de chapeau, le début du texte
Si je fais le test sur une page : https://www.tendancehotellerie.fr/articles-breves/communique-de-presse/10967-article/reseaux-sociaux-une-influence-tres-forte-sur-les-voyageurs-d-apres-booking-com, ma méta description
[<meta name="description" content="(#INTRODUCTION{150}|textebrut)" />]
donne :<meta name="description" content="17% des voyageurs du monde entier s’inspirent des vacances de leur influenceur préféré pour organiser leur vacances 7% des sondés avouent avoir déjà (...) " />
ce qui est mon chapeau
le plugin METAS+ genère
ce qui est mon texte
S’il y a avait un problème avec mon chapeau, pourquoi ma balise « historique » arrive-t-elle à trouver le chapeau et pas METAS+ ?
Pfiou, on va y arriver...
Donc il y a bien un bug avec #INFO_INTRODUCTION.
En attendant que ce soit corrigé dans SPIP, il faut utiliser la solution indiquée dans mon message précédent : https://contrib.spip.net/Metas-version-2#comment500043-500036
Hop : https://core.spip.net/issues/4291
Merciiiii
Avec spip ya des fois où je tourne bourrique mais là, en effet, je vois qu’on va y arriver :)
En attendant une prochaine version de spip, je mettrai en place un squelette
Bon weekend
Répondre à ce message
Bonjour,
Comment peut-on contribuer à la traduction du plugin ? C’est sur un dépôt git ?
Dans quelle langue ?
Anglais pour commencer.
La prochaine version du plugin CIBLOC comprendra une traduction en anglais, en allemand et en espagnol.
La nouvelle version 1.3 du plugin CIBLOC ajoute des traductions en anglais, en allemand et en espagnol.
Répondre à ce message
Bonjour,
Je suis très heureux ou presque de pouvoir utiliser ce plugin parce qu’il semble y avoir une incompatibilité avec pdf.js.
En effet, tous les pdf incrusté dans mes articles pour être directement lus s’affichent désormais sur tous les articles du site avec une hauteur fixe très petite empêchant de voir l’intégralité du document.
: Un exemple ici
Quand je désactive CIBLOC tout revient à la normal mais quelle catastrophe pour le bel article publié avec CIBLOC. Pensez-vous pouvoir résoudre ce problème ?
J’ai bien essayé d’indiquer une hauteur de mon choix au PDF, mais rien ne change...
En vous remerciant par avance :)
Pour éviter ce problème, il convient de supprimer les lignes suivantes dans le fichier cibloc/_config_cibloc/_css/cibloc.css :
La nouvelle version 1.3 du plugin CIBLOC apporte la compatibilité avec le plugin Pdf.js
Répondre à ce message
Bonjour,
Encore 1000 mercis pour ce formidable outil.
Deux petits retours utilisateur :
1 - pb de redimensionnement
J’ai rencontre un souci lors du redimensionnement d’une page contenant un formulaire « formidable » selon que celui-ci est inséré dans un bloc multi_colonnes ou un bloc multi_colonnes_sans-marge (voir copie d’écran).
J’ai corrigé en modifiant la feuille de style (patch sur la copie d’écran). Je ne sais pas si ce patch est le meilleur possible mais il marche. Par contre, il présente peut-être des effets de bord indésirables...
2 - crayons
Si on configure les crayons pour que la barre d’outils soit présente, la fenêtre popup permettant de choisir les blocs est toute embrouillée.
On peut corriger le problème en recopiant dans perso.css les déclarations /*========== cibloc : cibloc_popin_blocs (ne pas modifier) ==============*/ présentes dans cibloc_modal.css
Je ne sais pas trop où ça se tient, mais est-ce que ça ne serait pas intéressant de faire les modifications pour que l’affichage via les crayons soit propre « out of box » ?
Encore 1000 mercis (10 000, même !) pour ce chouette outil
1- Redimensionnement du formulaire
Pour contourner le problème, il convient d’ajouter dans la CSS les lignes suivantes (et non pas recopier celles relatives aux colonnes sans marges) :
2 - crayons
La question a déjà été posée et j’ai déjà répondu :
https://contrib.spip.net/cibloc-mettre-en-forme-le-texte-d-articles-avec-des?debut_comments-list=@497714#comment497714
OK pour -1
Pour crayons, j’avais vu la réponse. Mais je ne sais pas très bien comment la comprendre... Les crayons sont très répandus (et sacrément commodes) et c’est dommage que les blocs ciblocs soient si mal présentés dans la boîte modale à cause d’une petite question de css, non ?
(mais peut-être n’ai-je pas bien compris)
La nouvelle version 1.3 du plugin CIBLOC apporte la compatibilité avec le plugin Formidable.
Répondre à ce message
Saut de ligne non pris en compte ?
Dans un article, j’ai inséré un bloc 50% / 50%.
Les sauts de paragraphe (2 retours « touche entrée ») sont OK mis les sauts de ligne (1 retour « touche entrée ») ne sont pas pris en compte (voir copie d’écran jointe)
Est-ce qu’il y a quelque chose que je fais mal ou est-ce un bug ?
SPIP 3.2.1 + dernière version cibloc
En laissant une ligne vide entre la balise de début du bloc et le début du texte, est-ce que le problème se produit ?
Ah, effectivement avec une ligne vide après [colonne50], les sauts de ligne sont bien respectés
La prochaine version du plugin CIBLOC apportera une solution à ce problème.
Pouvez vous m’indiquer si le patch ci-joint règle le problème :
patch
Ah, alors c’est super !
;-)))
Ah, les messages se sont croisés : le « Ah, super » concernait le fait d’un patch à venir.
Le patch proposé ne résout pas le dysfonctionnement observé ;-((
Après avoir copié le fichier du patch (au bon endroit), il est indispensable de vider le cache de SPIP.
C’est OK avec ce patch.
Le cache de SPIP a des fonctionnements qui restent parfais un peu mystérieux : j’avais testé le patch en faisant un « recalcul » de la page. Pourquoi cela n’a-t-il pas donné le même résultat qu’après avoir vidé le cache ? Je pensais que ces deux manip’s étaient équivalentes (au détail près, bien sûr, que le recalcul n’affecte que la page en cours)
Cette nouvelle version du patch évite un effet de bord :
patch
La nouvelle version 1.3 du plugin CIBLOC apporte la compatibilité avec un saut de ligne simple (un seul retour « touche entrée »).
Répondre à ce message
Bonjour,
Testé avec succès, avec un spip 3.2.3, l’ensemble de plugins :
documentation, latexwheel, zippeur, documentation2latex, et suivant_precedent
De petites modifications dans le fichier paquet.xml des plugins suivants ont été nécessaires :
Donc, cela semble bien tourner sous spip3.2 :-)
Je suis ravi
Merci les développeurs !
Merci pour ces tests et ces retours.
Concernant les compatibilités
https://zone.spip.net/trac/spip-zone/changeset/113894/spip-zone
https://zone.spip.net/trac/spip-zone/changeset/113896/spip-zone
les indiques pour les plugins latex
concernant le plugin documentation, comme j’en suis pas l’auteur, je préfère en parler avec Marcimat avant de commiter
concernant la police... je ne sais pas trop quoi faire. Parce que « FreeSans » n’est pas livré avec les deux os dominants (bien que propriétaire). Donc je suis très hésitant.
Salut,
concernant le squelette « documentation » tu es sur qu’il ne nécessite pas zpip ?
Bonjour,
En renommant squelettes-dist cela fonctionne (avec 2 squelettes introuvables dans ce cas) donc avec le squelette-dist restauré, c’est pour moi bon.
Répondre à ce message
Un ticket mal placé sur programmer.spip.net demande :
Il est mentionné des noms de pipeline erronés me semble-t’il :
https://contrib.spip.net/Porte-Plume-documentation-technique#Completer-une-barre-d-outil
il y est écrit :
porte_plume_barre_outils_pre_charger
sert à ajouter des boutons à une barre.porte_plume_barre_outils_charger
sert à afficher ou masquer certains boutonsMais comme le dit quelqu’un en 2016 dans les commentaires
https://contrib.spip.net/Porte-Plume-documentation-technique#comment485720
Ce serait plutôt
porte_plume_barre_pre_charger
etporte_plume_barre_charger
Répondre à ce message
Pour faire des sous-rubriques en espace public j’ai mis
[(#FORMULAIRE_EDITER_RUBRIQUE{oui, #ID_RUBRIQUE, [(#SELF|parametre_url{id_rubrique, #ID_RUBRIQUE})]})]
et pour faire afficher la sous-rubrique j’ai mis<BOUCLE_sous_rubriques(RUBRIQUES) {id_parent}{tout} {par num titre}{!par date}>
jusque la tout va bien.Maintenant si je clique sur le lien de la nouvelle rubrique que je viens de créer, j’obtiens une erreur 404 puisqu’il n’y a pas encore d’articles de créer. Pour palier à cela j’ai mis dans head/rubriques
<BOUCLE_rubrique_head(RUBRIQUES) {id_rubrique}{tout}>
mais cela ne fonctionne pas. Il y a toujours une erreur 404. Que puis-je faire ?Bonjour,
je vous conseille de poster cette question sur la liste SPIP, vous aurez beaucoup plus de chance d’avoir une réponse, ou même plusieurs...
Mais donc c’est possible, à condition de changer l’action du formulaire, pour faire en sorte de donner un statut « publie » à la rubrique dès sa création. Cela se passera dans la fonction traiter du formulaire. Pour ne pas polluer la création générique des rubriques, il faudra certainement dupliquer le formulaire, les deux fichiers html et php, pour le renommer par exemple editer_rubrique_publique, et renommer à l’intérieur les fonctions aussi.... on peut continuer la discussion sur la liste SPIP si vous voulez : https://listes.rezo.net/mailman/listinfo/spip
Répondre à ce message
je voulais poster un petit message de mise a jour.
nous utilisons cette contributions maintenant depuis presque 2 ans et nous en somme tres content.
nous servons +- 300,000 pages vue par jour avec une charge server tres faible.
nous ’push’ons desormais nos fichiers cache vers ’google cloud storage’ (simple et pas cher) et nous indiquons a notre CDN d’aller chercher les fichiers en deux temps, en premier sur le cloud storage et si non disponible (trop recent) sur le server live.
Ce system isole completement le server du traffic web. Nous avons eu des piques de traffic enorme sans aucune charge de server supplementaire.
Seul point ennuyeux, le nombre de taches de fonds pour rafraichir le contenu editorial ralenti parfois les mises a jours de certaines pages. Par exemple un article avec beaucoup de mot cles, beaucoups de documents, prend un certain temp a apparaitres sur toutes pages les mots cles.
Mais au final je pense que le leger delai est moins important que le fait d’etre sur que le site n’ai pas de soucis en cas de pique de traffic et de robots aspirateurs recalcitrant.
Je suis surpris de ne pas voir de message sur cette contrib. J’espere que d’autres sites a fort traffic s’y interesseront. Nous serions heureux de voir cette contrib utilise et ameliore par d’autres sites.
Répondre à ce message
Bug avec l’affichage conditionnel d’un champ obligatoire.
Bonjour.
J’ignore si c’est lié à Formidable ou à Saisies mais la validation d’un formulaire ne fonctionne plus quand on a un champ obligatoire non affiché (donc non rempli) à cause d’un affichage conditionnel.
Ça semble se faire sur tout type de champ (je l’ai vu sur des lignes de texte, radios, dates…). Mais, sur les checkbox, obligation + affichage conditionnel demandent carrément de cocher chaque case.
Voir démo, avec ce YAML :
Arrivez-vous à reproduire ça ? Ou est-ce lié à ma config ?
Merci d’avance et bonne journée.
(SPIP 3.1.9, Formidable 3.34.9, Saisies pour formulaires 3.13.0)
c’est lié à HTML5. Je regarde ce qu’il en est.
Saisies 3.13.1 corrige cela. Il sera disponible en zip/par svp peu après midi.
Merci beaucoup ! Ça a déjà débloqué une bonne part de nos formulaires.
Hélas, il reste un problème. Exemple :
Le choix Foo fait apparaitre :
- un checkbox obligatoire
- un date obligatoire (dans un fieldset toujours affiché)
- un fieldset contenant un radio obligatoire.
Si on choisit Bar, les champs date et radio liés à Foo bloquent la validation, mais pas le champ checkbox. Le problème disparait si on retire le champ radio du fieldset « Foo » (ou si on le remplace par un autre type de champ).
Ça semble donc être lié à la présence d’un radio dans un fieldset à affichage conditionnel.
Remarques complémentaires :
- Certains types de champs sont indiqués comme bloquants mais pas d’autres (voir pièce jointe).
- Un type de champ mis comme bloquant l’est aussi hors d’un fieldset (voir « Foo date » dans le haut de l’image jointe).
Oops… on ne voit pas bien l’image. La voici en lien.
Merci d’avance. Je suis bien entendu à disposition s’il y a des questions.
Heu... avec l’exemple envoyé, je n’ai pas de problème. Mes radios ne bloquent rien... j’arrive à poster du moment que je remplis les champs affichés et marqués comme obligatoire...
Étrange.
J’ai vidé les caches navigateur et Spip (y compris ./tmp/cache) et j’ai réimporté mon exemple ci-dessus.
Si je coche Bar et remplis les champs nécessaires, le formulaire ne se valide pas. (Sous Firefox, si je coche ensuite Foo, je vois que ce sont les champs date et radio qui bloquent : ils sont encadrés de rouge.)
J’ai essayé avec un Spip 3.2.3, pareil. Avec Chromium, pareil. :-/
ok, je sais. Il y a un problème au niveau du compresseur js interne. Comme pour les debug je le désactive, je voyais pas le problème. Je tente de corriger.
Bon,
ce n’était pas lié à la compression js, mais j’ignore pourquoi je ne reproduisait pas chez moi.
Enfin, j’ai fini par reproduire. La version 3.13.3 résoud normalement ce problème.
Merci beaucoup, ça semble fonctionner au poil. Mes collègues vont être contentes. :-)
Belle journée. 🌞
tant mieux. N’hésite pas à signaler si problème similaire.
Répondre à ce message