spiPDF : générer des contenus sur mesure en PDF

Publié le : 16 février 2011 – Dernière modification le 14 novembre 2023 – par Yves Tannier – 265 commentaires

1
2
3
4
5
75 votes

Le plugin spiPDF génère des fichiers au format PDF d’article ou de tout autre élément SPIP, simplement à partir d’un squelette construit au format HTML 4 et facile à modifier.

Avertissement de sécurité

Ce plugin a fait l’objet d’une faille de sécurité en mars 2017, il est important d’avoir son site SPIP et le plugin à jour pour continuer à utiliser ce plugin en toute sécurité

Présentation

Le plugin génère des fichiers PDF à partir d’un squelette écrit au format HTML 4.
Il vous permet donc de créer un PDF réellement sur mesure sans d’autre compétence que de connaître le HTML 4 et CSS.

Que ce soit un squelette pour vos articles, vos rubriques, votre plan de site ou d’autres éléments plus spécifiques, spiPDF génère le contenu en PDF.

Plusieurs librairies, plusieurs possibilités

Le plugin [1] se base - au choix de l’utilisateur - sur plusieurs classes de génération de PDF à partir de HTML :

Par défaut, le plugin utilise mPDF. Vous verrez plus bas dans cet article comment utilisez un autre librairie à la place.

Chacune des classes à ses avantages et ses inconvénients. On notera par exemple que mPDF gére le positionnement flottant (“float”) des éléments ce qui est indéniablement un plus pour de la génération d’article contenant des images.

N’hésitez pas à donner votre avis et vos expériences sur les différentes librairies dans les commentaires de l’article.

Pré-requis

A partir de la version v2.0.2 (compatible SPIP 4)
il est nécessaire d’avoir PHP 8.0 ou plus (pour la compatibilité avec les librairies embarquées)

Pour les versions v1.2.0 et précédentes, le plugin requiert :

  • PHP 5
  • d’installer manuellement dans le répertoire /lib/ une librairie (voir chapitre précédent)

Téléchargement et installation des librairies requises

A partir de la version v2.0.2 (compatible SPIP 4)
Il n’est plus nécessaire d’intégrer les librairies d’une facon externe, elles sont intégrées dans le répertoire vendor du plugin

Dans les anciennes versions
Vous devez les télécharger sur leurs sites respectifs et les décompresser dans un répertoire lib/ à la racine de votre site ou dans un répertoire lib/ dans le répertoire du plugin :

Les dossiers doivent se nommer exactement respectivement mpdf, html2pdf ou dompdf (sans majuscules).

Rendu obtenu avec les différentes librairies

Après un test simple de chacune des librairies, voici les résultats que j’ai obtenu :

  • mPDF version 6.0 du 01/03/2015 : bon rendu général
  • HTML2PDF version 4.03 du 27/05/2011 : rendu du texte correct, problème avec certains positionnements d’images
  • domPDF version 0.6.0 beta2 de 02/2011 : problème d’encodage des caractères

Utilisation

Une étape supplémentaire suffit pour commencer à utiliser le plugin.

Ajoutez un lien hypertexte vers le squelette du plugin, typiquement dans votre squelette article.html. Voici à quoi doit ressembler ce lien pour un article :

[<a href="[(#URL_PAGE{spipdf}
	|parametre_url{spipdf,spipdf_article}
	|parametre_url{id_article,#ID_ARTICLE}
	|parametre_url{nom_fichier,article_#ID_ARTICLE})]">
télécharger l'article au format PDF</a>]

Mise en page personnalisée

C’est tout l’intérêt du plugin : permettre une mise en page personnalisée sans connaître le PHP.

Pour obtenir un PDF sur mesure, vous pouvez :

  • soit modifier le squelette qui se trouve dans le répertoire du plugin : spipdf_article.html
  • soir créer votre propre squelette et modifier la balise #URL_PAGE pour qu’elle appelle bien votre squelette à la place de spipdf_article (remplacer spipdf_article par le nom de votre squelette)

Par exemple, vous avez dans votre répertoire squelette, un squelette plan_site_pdf.html que vous souhaitez utiliser pour générer une sortie PDF de votre plan de site.

Il vous suffira d’appeler ce squelette/PDF de la façon suivante :

[<a href="[(#URL_PAGE{spipdf}
	|parametre_url{spipdf,plan_site_pdf}
	|parametre_url{nom_fichier,plan_site_pdf})]">
télécharger le plan de site au format PDF</a>]

Ce qui donnera l’URL : http://monsite.tld/spip.php?page=spipdf&spipdf=plan_site_pdf.html

Liens vers des articles SPIP dans le PDF

Si vous utilisez des liens internes du type [->art2] dans vos articles,
il est nécessaire d’utiliser le filtre abs_url sur les balises
DESCRIPTIF, CHAPO, TEXTE, PS et NOTES pour que les liens dans votre PDF pointent bien sur votre site.

Nom de fichier personnalisé

Par défaut, les fichiers PDF se nommeront document.pdf.

Si vous souhaitez préciser un nom particulier pour votre fichier, vous devrez préciser, comme dans les exemples ci-dessus, le paramètre nom_fichier dans la balise #URL_PAGE.

Choix de la librairie de génération

Pour sélectionner l’une ou l’autre des librairies supportées, vous devez changer la valeur de l’attribut lib_pdf dans la balise du squelette spipdf_article.html ou de votre squelette personnalisé/

Les valeurs possibles sont mpdf / html2pdf / dompdf

Vous pouvez utiliser une librairie différente par type de squelette.

Format, orientation des pages et autres subtilités

Chaque librairies autorisent la mise en page directement depuis le squelette HTML mais pas de la même façon.

Pour plus de simplicité, le format (A4, A5, Letter...) est cependant gérés par le plugin depuis cette balise page pour toutes les librairies.

Pour le reste (marge, bordure, header, footer...) chaque outils à son propre fonctionnement mais tout ceci sans toucher au code du plugin.

mPDF

La librairie utilise le sélecteur CSS @page. Ceci est également explicité dans la documentation (en anglais) de la bibliothèque.

HTML2PDF

La librairie utilise les paramètres précisés via la balise (voir le squelette spipdf_article.html pour l’exemple)

Vous trouverez plus d’informations sur le wiki de la librairie et plus particulièrement sur la section concernant la fameuse balise page.

dompdf

Le support étant expérimental, je n’ai pas plus d’informations pour l’instant à fournir. A voir sur le site de cette librairie.

Contraintes et bugs connus

Certaines balises HTML peuvent ne pas être gérées par le plugin

C’est notamment le cas de balises qui ne sont pas gérées par la librairie que vous avez choisi d’utiliser. Dans ce cas, vous devriez obtenir une erreur à la génération du PDF ou un affichage dégradé. Dans cette situation, 2 solutions :

  • le HTML qui pose problème est dans votre squelette ? et bien... trouvez autre chose en attendant mieux (mais signalez-le quand même dans les commentaires)
  • le HTML est généré par SPIP ? Signalez-le dans les commentaires pour une mise à jour du plugin

Certaines balises CSS ne sont pas gérées par le plugin

Bien entendu, dans ce cas, l’affichage au format PDF sera différent de l’affichage au format HTML. On notera par exemple que le positionnement float est géré en partie par mPDF et pas du tout par HTML2PDF.

Vous devrez palier à certaines contraintes de positionnement en utilisant des tableaux imbriqués (snif !)

Encore une fois, toutes ces contraintes sont explicitées sur les site et les forums des librairies respectives.

Changer l’encodage utilisé pour la génération de PDF

Le plugin génère les PDF en UTF-8. Certaines personnes ont rencontré des problèmes de génération des contenus dans cet encodage.

Pour changer ce comportement, et utiliser ISO-8859-15, vous devez changer la constante suivante dans votre fichier d’options :

define('SPIPDF_CHARSET', 'ISO-8859-15');

Aide au développement

Pour pré-visualiser la page au lieu de générer le PDF, vous pouvez ajouter le paramètre debug_spipdf à l’URL
Par exemple : spip.php?page=spipdf&spipdf=spipdf_article&id_article=1249&nom_fichier=article-1249&debug_spipdf

Notes

[1] Depuis la version 0.2.0

Discussion

5 ans 1 an 3 mois Sans limite
par date
Filtrer

96 discussions

  • 3
    alinet

    Bonjour sur un SPIP 2.1 avec la lib mpdf toute fraichement télécharger, mise dans lib, je me prend deux warning qui empeche la génération du pdf

    Warning : require_once(lib/mpdf/config_cp.php) [function.require-once] : failed to open stream : No such file or directory in
    /htdocs/monsite/lib/mpdf/mpdf.php on line 39

    Fatal error : require_once() [function.require] : Failed opening required ’lib/mpdf/config_cp.php’ (include_path=’. :/Applications/MAMP/bin/php/php5.2.17/lib/php’) in htdocs/monsite/lib/mpdf/mpdf.php on line 39

    Merci de votre aide

    • alinet

      en ouvrant le ficher mpdf.php à la ligne 39
      j’ai require_once(_MPDF_PATH.’config_cp.php’) ;
      Merci

    • Yves Tannier

      Bonjour,

      C’est peut-être lié à la nouvelle version de mpdf... Je vais vérifier dès que possible.

    • Déesse A.

      J’ai rencontré le même problème, mais c’est faute d’avoir mal lu la page de download mpdf. Le lien « Download » à côté de « 5.6.1 » est juste une mise à jour de 2 fichiers, il faut d’abord charger la 5.6 dite « full version », puis la 5.6.1 à part et utiliser ses 2 fichiers pour écraser les 2 correspondants dans la 5.6.

    Répondre à ce message

  • 1
    Chris

    Bonjour,
    J’ai une partie du document qui n’est pas affichée !
    Ce n’est pas du à un texte trop long (je l’ai raccourci pour vérifier), et après maints essais, je me suis aperçu que ça venait des images flottantes (qui sont pas flottantes dans mon, pdf).
    Par exemple 2 images centrées, suivis d’une image à gauche, le tout entrecoupé de texte, dans ce cas tout ce qui est entre la 1re image centrée et l’image à gauche disparaît !
    C’est très gênant, car je dois générer mes pdf si possible tels qu’ils sont affichés sur la page web.

    J’ai mis à jour les versions, mais cela ne change rien, j’ai spip 2.1.20, spipdf 0.2.2 et mpdf 5.6.1

    Merci pour votre aide.

    • le cancre

      Bonjour Chris,
      Je rencontrais très récemment le même problème. Avec <imgXX|center>, le PDF supprimait du texte (et certaines images (??)).
      En utilisant <docXX|center>, le PDF est généré tout à fait correctement... sauf qu’il n’affiche pas les titres des images :-(
      Je m’en vais donc poser la question, dans le cadre un peu plus haut ;-)
      BM

    Répondre à ce message

  • 2
    Polar oïd

    Bonjour, merci pour ce plugin qui fonctionne parfaitement, testé sur les articles... J’aimerais réaliser un PDF sur mesure qui contiendrait les informations contenues dans la table spip_auteurs et qui retournerait les données d’un auteur en session, c’est à dire connecté via le formulaire de login...

    Aprés plusieurs tentatives, je ne parviens pas au résultat désiré étant donné que je ne comprends pas le principe de base qui permet de transférer les valeurs d’une table via le paramétrage de l’url de génération du .pdf

        <a href="[(#URL_PAGE{spipdf}
            |parametre_url{spipdf,spipdf_profil}
            |parametre_url{id_article,#ID_ARTICLE}
            |parametre_url{nom_fichier,Profil})]"></br>
    Votre profil en PDF</a>

    Que faut-il indiqué à la place de

      |parametre_url{id_article,#ID_ARTICLE}

     ?
    J’ai testé avec :

      |parametre_url{id_auteur,#ID_AUTEUR}

    et coté squelette (spipdf_profil), une boucle de type :

    <BOUCLE_Profil(AUTEURS){id_auteur}>

	 [(#ID_AUTEUR)] 
	 [(#NOM)] 
	 [(#BIO)] 
	 [(#EMAIL)] 

</BOUCLE_profil>

    Mais le pdf généré n’affiche rien...

    Des idées ? Merci d’avance ;)

    • Yves Tannier

      Bonjour,

      Ca devrait fonctionner de cette manière. Avez vous essayer d’ajouter votre boucle Profil dans le squelette fourni spipdf_article.html en gardant les éléments de style et de configuration du PDF (balise page) ?

    • Polar oïd

      Salut, merci pour votre réponse, j’ai en effet testé en conservant le squelette d’origine spipdf_article.html mais rien... J’ai donc testé autrement :

      <BOUCLE_Profil(spip_auteurs){id_auteur}>
         [(#NOM)]
</BOUCLE_profil>

      Étrange, cela fonctionne... Mais, je ne suis pas au bout de mes recherches. En effet, j’aimerais savoir si il est possible de passer un id_auteur au squelette ? l’idée serait de disposer d’une liste des auteurs en base et dont les liens généreraient un .pdf pour chaque profil, qu’en pensez-vous ? Grâce à :

      <BOUCLE_Profil(spip_auteurs){tout}{id_auteur=#SESSION{id_auteur}}>
 [(#NOM)]
</BOUCLE_profil>

      On peut produire un .pdf de l’auteur en session mais ce sont bien les profils de tous les auteurs que je cherche à obtenir avec un squelette unique...

      Avez vous des pistes ? ;)

      Récapitulatif :

      -  on fabrique une boucle auteurs qui retourne une liste de l’ensemble des auteurs sous forme de liens

      -  on clique sur un lien correspondant à un auteur donné

      -  on génère un .pdf contenant les donnés de l’ id_auteur spécifiquement

    Répondre à ce message

  • 1
    Marc P

    Bonjour, juste pour signaler que le lien pour télécharger la librairie mpdf renvoie sur une erreur.
    La bonne adresse est :http://www.mpdf1.com/mpdf/index.php

    Répondre à ce message

  • 2
    Brice

    Bonjour,

    Je tente de préciser un nom de fichier qui reprenne le titre de l’article. J’essaie donc dans les paramètres url de #URL_PAGE :

    |parametre_urlnom_fichier,(#TITRE|couper15)

    (je m’excuse par avance, je n’ai pas de balises ici pour indiquer qu’il s’agit de code...)

    Supposons que mon titre commence par « La restitution des suivis... », je devrais donc avoir « La restitution.pdf », n’est-ce pas ? Malheureusement, quel que soit ma troncature, j’ai « La.pdf » comme si le nom attribué s’arrêtait automatiquement au premier espace. Dois-je changer quelque chose au code d’un fichier quelque part pour empêcher cela ou est-ce que je m’y prends mal ?

    Merci par avance de vos lumières :-)
    Cdlt,
    BM

    • Yves Tannier

      Il faut peut-être mettre entre guillemet le titre tronqué. Il n’y a pas d’intervention au niveau du plugin sur ce paramètre (voir dans spipdf.html => c’est là qu’est utilisé nom_fichier)

    • Brice

      Bonsoir,
      Merci Yves et merci robomatix pour vous être penché sur mon problème. J’ai essayé avec vos solutions, tout au moins avec ce que j’en ai compris, mais n’y suis pas parvenu. Soit qu’elles ne fonctionnent pas, soit que je suis trop ignare...

      Malgré tout, j’ai réussi. Si cela peut en aider d’autres, voici comment jai procédé :
      initialement, les URL des articles finissaient par « article12 » ou « article12html » je ne sais plus. Bref, pas par le titre de l’article. J’ai donc modifié via « Configuration » et j’ai mis « propres » pour le « type d’adresses URL » (je suis sous SPIP 2.1.19).
      J’ai ensuite utilisé #SELF dans les paramètres pour spipdf, de cette manière :

      |parametre_url[nom_fichier,#SELF]

      (remplacer les crochets ici par des accolades)
      (en passant, comment faîtes-vous apparaître le code SPIP sur les posts ??)

      De cette manière, cela fonctionne.
      Merci à vous.
      BM

    Répondre à ce message

  • 7
    Brice

    Bonjour,
    et bravo pour ce plugin extrêmement utile, notamment dans le cadre de l’édition électronique (mais pas que).

    Dans son utilisation toutefois, je suis confronté à un problème assez bizarre.
    Quelques-uns de mes articles comportent des tableaux. Leur mise en forme passe totalement à la trappe sur la version en ligne de mon site... alors qu’en local, leur css est bien pris en compte.

    Pour exemple, dans le fichier spipdf_article.html, à l’endroit des « quelques styles en plus », j’ajoute :
    table margin-top : 10px ;border : 5px solid red ;border-collapse : collapse ;
    Certes, c’est laid, mais c’est pour tester.

    Eh bien en local (WAMP) mes tableaux, dans le PDF, sont bordés de rouge, alors qu’en ligne ils sont complètement nus, pas même une bordure à se mettre sur le dos ! Je précise que mes deux versions de SPIP et de plugin sont strictement identiques en ligne et en local.

    Une idée sur la cause de cette bizarrerie ?

    Merci par avance pour vos lumières :-)
    BM

    • Yves Tannier

      Bonjour,

      Vérifiez les différentes versions de PHP entre votre serveur local et distant peut-être une piste.

    • Brice

      Merci pour votre réponse.
      En local (tableaux OK) : version 5.3.5
      En distant (tableaux pas OK) : version 5.3.18

      Il s’agit de PHP 5 pour les deux. Bizarre...

      Je continue à chercher... Si quelqu’un a une idée, qu’il n’hésite pas ;-)

    • Brice

      C’est encore moi...

      Bonjour,
      Je me bats toujours avec mon problème de tableaux (cf. message un peu plus haut).
      Je ne crois pas que le problème vienne de PHP (5.3 en local comme en distant).
      Je pencherais pour un problème de feuille de style. En distant, les styles en semblent pas appliqués.
      Je joins une image, c’est toujours plus simple d’avoir la reproduction sous les yeux pour comprendre le « dysfonctionnement ».

      S’il s’agit effectivement d’un problème de liens vers une feuille de style (sachant que même les styles déclarés directement dans spipdf_article.html ne sont pas pris en compte en distant), comment résoudre ce problème ? Cela peut-il être lié au fait que le SPIP distant ne soit pas à la racine du site, alors qu’en local il l’est ?

      Merci vivement par avance à quiconque pourra m’enlever cette épine du pied.

      BM

    • Brice

      Bon, ben c’est réglé... Comme bine souvent la solution était sous mes yeux...
      En plus de mon problème de tableaux, j’avais un souci avec les images qui ne s’affichaient pas... Forcément, mon site distant étant en test, il est protégé via htaccess... Supprimer cette « protection » résout les problèmes et de tableaux et d’images. Si d’autres rencontrent ce problème finalement tout bête... J’en rougis de honte.

      BM

    • Yves Tannier

      J’aime quand les problème se résolvent d’eux même :)

      Surtout qu’en ce moment je mets un peu de temps à répondre !

    • Brice

       :-) Cela force à réfléchir un peu par soi-même !

      En revanche, mon problème du 21 novembre (nom de fichier) reste à résoudre ;-) J’ai beau me creuser les méninges, je ne vois pas, pour le moment.

      Merci Yves quoi qu’il en soit pour ce super plugin.

      BM

    • robomatix

      Pour le nom du fichier, essais un truc du genre

      nom_fichier,(#TITRE |replace{"'",""}|substr{0,15})

      Je crois que couper foire un peu si on coup trop court... Le replace, c’est pour supprimer le ’ .
      Pas sur que ça marche, mais peut être une piste à explorer....

    Répondre à ce message

  • 2
    Antoine

    Bonjour,

    J’ai essayé d’utiliser ce plugin pour générer un « catalogue » c’est à dire un pdf regroupant tous les articles d’une rubrique
    J’ai donc mis dans mon rubrique.html

    [<a href="[(#URL_PAGE{spipdf}
                                |parametre_url{spipdf,spipdf_catalogue}
                                |parametre_url{id_rubrique,#ID_RUBRIQUE}
                                |parametre_url{nom_fichier,rubrique_#ID_RUBRIQUE})]">
                                télécharger le catalogue de cette rubrique format PDF</a>]

    J’ai ensuite copié simplement spipdf_article.html du plugin dans mon répertoire squelettes et modifié la première ligne (la boucle principale)
    <BOUCLE_principale(ARTICLES) {id_rubrique} {par date}{inverse}>
    ET ça marche, mais pas à tout les coups. pour une rubrique qui contient entre 1 et 6/7 articles : ok
    Mais pour les « grosses » rubrique le pdf généré fait une page, qui est blanche.
    Auriez vous le commencement de début d’une idée quelconque ?
    Cordialement

    • Yves Tannier

      Bonjour,

      Le problème peut venir de certaines expressions régulières de la fonction spipdf_nettoyer_html du fichier spipdf.php

      Essayez de commenter la ligne 239 du fichier spipdf.php

      $html = spipdf_nettoyer_html($html,$possible_librairies[$librairie_pdf]) ;

    • Antoine

      Je vous remercie !
      Entre temps, en relisant un peu plus attentivement tous les messages de ce forum, j’ai tenté de simplifier mon fichier spipdf_catalogue.html et cela fonctionne.

      <BOUCLE_principale(ARTICLES) {id_rubrique}>
        [(#LOGO_SITE_SPIP)<br />]
         <div id="hierarchie"> .............</div>
        [(#LOGO_ARTICLE)]
        [<h1>(#TITRE|supprimer_numero)</h1>]
        [<div class="chapo_simple">(#CHAPO)</div>]
        [(#TEXTE|abs_url)]
        <formfeed />
</BOUCLE_principale>

      Le rendu est simple, mais comme tous les articles sont « formatés » avec des règles assez strictes, cela fonctionne parfaitement.

      J’en conclu bêtement que le fait d’avoir simplement supprimé les |image_reduire du squelette a résolu mon problème ...
       ?
      Cordialement

    Répondre à ce message

  • 2
    bruno31

    Qui a essayé les dernières versions des librairies ?

    En début d’année 2012, j’avais essayé les 3 librairies et j’en étais arrivé à la conclusion que c’était mPDF la plus aboutie.

    En regardant le forum de mPDF, je vois que l’auteur a arrêté le développement et que la dernière version est la 5.5. Je ne l’ai pas encore essayé

    A l’époque, j’avais regardé du côté de HTML2PDF mais elle était beaucoup moins avancée que mPDF. Mais la librairie a peut-être évolué depuis ? Qqun a t’il testé ?

    • Yves Tannier

      Bonjour,

      Je n’ai pas encore testé les nouvelles version de HTML2PDF. L’aspect le plus bliquant était la gestion des images « float ». A voir....

    • bruno31

      J’ai fait qq test. Apparemment pas de grosses évolutions.

    Répondre à ce message

  • 7
    alquitte

    Bonjour,

    je teste pour la première fois ce plugin : je rencontre deux soucis :
    -  sur les articles très longs, la génération du pdf produit une page blanche >> pb d’articles longs que tu évoques Yves sur ton post du 19 avril
    -  les images « img » ou les « doc » ne s’affichent pas du tout (mais les logos si !)

    j’utilise SPIP 2.10 et la librairie mpdf

    > pour les articles très longs, je ne peux pas y changer grand chose >> c’est un site de syndicat,
    > pour le souci sur les images, j’ai essayé les propositions dans les commentaires : commenter certaines lignes du fichier php, mais sans succès...

    pouvez-vous m’aider ou m’éclairer ?

    merci d’avance !

    • Yves Tannier

      Bonjour,

      Concernant les articles long, il s’agit également d’un problème avec une expression régulière. Peux-tu essayer en supprimant la balise LESAUTEURS de spipdf_article.html ?

      Pour les img ou les doc, on ne m’a pas fait remonté de problème à ce niveau. Ca doit venir du chemin vers IMG. Tu as chargé le plugin en FTP ou via l’espace privé ?

      J’espère pouvoir corriger prochainement ces soucis (pas facile de trouver le temps)...

      ++ Yves

    • Bonjour,
      en supprimant la balise LESAUTEURS >> pas de changement sur les articles longs

      j’ai chargé le plugin en ftp
      dois-je essayer d’une autre manière via l’espace privé plutôt ?

      merci pour ta réponse

    • alquitte

      j’ai oublié de m’identifier sur le précédent commentaire,
      je viens d’essayer le plugin en installation auto via l’espace privé : même souci pour les images !

      cordialement

    • Yves Tannier

      Bonjour,

      Autant pour les articles longs on m’a signalé ce problème, autant pour les images, je ne vois pas trop d’où ça peux venir...

      Il faudrait d’appeler directement une image dans le squelette spipdf_article.html...

      Toujours pas eu le temps de me pencher sur le souci avec les articles longs...

    • Loiseau2nuit

      Bonjour :)

      Confronté au même prooblème ici, et pareillement, la suppressions de #LESAUTEURS n’a rien donné.

      Constaté ce jour sur un spip 2.1.10 SVN mutualisé avec plateforme complète à jour (spip + plugins)
      Je précise que je charge Spipdf par le dossier extensions. Est-ce que ca peut venir de là ?

      Par ailleurs, tu sembles suggérer qu’on t’avait déjà remonté l’info. As tu un lien vers les fils concernés s’il te plait ?

      Merci beaucoup en tout cas, pour le boulot abattu :)

    • Yves Tannier

      Le bug des articles longs devrait-être résolu

    • alquitte

      Hello,

      pour info
      vient de re-tester le plugin spiPDF au cours d’une maintenance avec plugin remis à jour, librairie mpdf à jour et version de spip (SPIP 2.1.19) aussi à jour, j’ai toujours un souci avec les articles longs ! (le pdf est vierge).

    Répondre à ce message

  • robomatix

    Bonjour,

    Hier, nous avons eu des problèmes sur la génération de pdf d’une revue de presse...
    Pour éviter le problème, nous avons du mettre ’en cours de rédaction’ certains article qui ne semblaient pas passer...

    Spip 2.1.10
    SpiPdf 0.2.1
    Lib : mpdf

    Voici le code de la boucle qui récupère les articles génant :

                <BOUCLE_rubrique_suite(RUBRIQUES){id_secteur=1}{id_rubrique !IN 109,2,114}{par num titre, titre} >
                <BOUCLE_jour_suite(ARTICLES) {id_rubrique}{agenda date, jour, (#ENV{date_revue_presse}|annee), (#ENV{date_revue_presse}|mois), (#ENV{date_revue_presse}|jour)} {par id_rubrique} {par date} {inverse}{statut=publie}>
                    <BOUCLE_rubrique_titre_suite(RUBRIQUES) {id_rubrique}>
                        [<h2>(#TITRE|unique)</h2>]
                    </BOUCLE_rubrique_titre_suite>
                    <h3>#TITRE</h3>
                    <div class="texte">
                        [(#TEXTE|image_reduire{800,0})]
                    </div>
                                                                                 [(#REM) Portfolio : album d'images ]
                            <B_documents_portfolio_suite>
                                <div id="documents_portfolio">
                                    <BOUCLE_documents_portfolio_suite(DOCUMENTS) {id_article} {mode=document}{extension IN png,jpg,gif} {par num titre, date}{doublons}{vu=non}>
                                        [(#FICHIER|image_reduire{0,800})]
                                </BOUCLE_documents_portfolio_suite>
                                </div><!-- #documents_portfolio -->
                            </B_documents_portfolio_suite>
                </BOUCLE_jour_suite>
            </BOUCLE_rubrique_suite>

    Ce matin, j’ai voulu tenter de régler le problème et ai donc fait une boucle comme celle-là dans un fichier de test pour récupérer les articles ’en cours de rédaction’ qui posaient problème :

                <BOUCLE_rubrique_suite(RUBRIQUES){id_secteur=1}{id_rubrique !IN 109,2,114}{par num titre, titre} >
                <BOUCLE_jour_suite(ARTICLES) {id_rubrique}{agenda date, jour, (#ENV{date_revue_presse}|annee), (#ENV{date_revue_presse}|mois), (#ENV{date_revue_presse}|jour)} {par id_rubrique} {par date} {inverse}{statut=prepa}>
                    <BOUCLE_rubrique_titre_suite(RUBRIQUES) {id_rubrique}>
                        [<h2>(#TITRE|unique)</h2>]
                    </BOUCLE_rubrique_titre_suite>
                    <h3>#TITRE</h3>
                    <div class="texte">
                        [(#TEXTE|image_reduire{800,0})]
                    </div>
                                                                                 [(#REM) Portfolio : album d'images ]
                            <B_documents_portfolio_suite>
                                <div id="documents_portfolio">
                                    <BOUCLE_documents_portfolio_suite(DOCUMENTS) {id_article} {mode=document}{extension IN png,jpg,gif} {par num titre, date}{doublons}{vu=non}>
                                        [(#FICHIER|image_reduire{0,800})]
                                </BOUCLE_documents_portfolio_suite>
                                </div><!-- #documents_portfolio -->
                            </B_documents_portfolio_suite>
                </BOUCLE_jour_suite>
            </BOUCLE_rubrique_suite>

    Et là, pas de problème, le pdf était bien généré avec uniquement les articles qui posaient problème...

    J’avoue ne pas trop comprendre... Est ce que quelqu’un aurait une idée ?

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom