Création paquet pour Yunohost

[Thatoo]

@corentin

Peut-être que certains fichiers de style ne sont pas correctement récupérés lors de l’impression.

Pourrais-tu détailler ton idée?
J’ai essayé sur une autre machine et j’ai le même rendu donc le problème ne venait pas de arm/raspi4.

Tant que ce soucis n’est pas résolu, impossible d’imaginer publier le paquet yunohost. Mais c’est aujourd’hui le seul frein à ma connaissance donc si on arrive à résoudre ça, le paquet ynh pourra être publié.

[corentin]

Bonjour @Thatoo,

Je viens de re-regarder ta capture d’écran du PDF et une partie de l’image m’intrigue :

Ce sont les boutons de prévisualisation d’impression qui sont bien présents dans toutes les impressions PDF, mais qui sont censés être masqués par la règle CSS suivante :

@media print {
  .print-hide {
    display: none !important;
  }
}

Cette règle se trouve dans le fichier print.bundle.scss qui est compilé dans un fichier :

dokos-bench/apps/frappe/frappe/public/dist/css/print.bundle.########.css

Donc ça veut dire que le serveur/reverse proxy n’arrive pas à servir le fichier, ou alors que la règle ne s’applique pas. Or, bench build produit des liens symboliques, en l’occurence le lien suivant :

dokos-bench/sites/assets/frappe/dist/css/print.bundle.########.css

S’agissant d’un lien symbolique, il faut s’assurer que l’utilisateur exécutant le reverse proxy (e.g. www-data) ait bien accès en eXploration à tous les dossiers situés sur le chemin complet vers le lien symbolique (incluant tous les dossiers parents, par exemple le home de l’utilisateur).

Si tu veux vérifier l’impression sans faire de PDF, tu peux consulter la page printview dans ton navigateur. Dans l’inspecteur Réseau, tu pourras voir tout de suite si certains fichiers ne sont pas chargeables par le navigateur car le reverse proxy ne peut pas y accéder. Si la page s’affiche correctement, alors il y a forcément un problème avec wkhtmltopdf mais ça me semble étrange qu’une règle simple comme celle susmentionnée ne fonctionne pas.

https://demo.dokos.cloud/printview?doctype=Quotation&name=SAL-QTN-2024-00001

Voilà un exemple du rendu attendu :

[Thatoo]

Voici ce que j’ai en allant sur « https://dokos.local/printview?doctype=Quotation&name=SAL-QTN-2024-00001 » :

le css est bien présent, ça s’affiche quand même un peu bizarrement, et si je clique sur « Obtenir un PDF » :

le css n’est pas présent et ça s’affiche mal.

Quand aux droits sur les fichiers/dossiers, voici ce que j’ai :

donc je pense que c’est ok.

[Thatoo]

ah, j’ai peut-être trouvé quelque chose d’intéressant dans dokos-bench-folder//sites/dokos.local/log/wkhtmltopdf.log :

Qu’est-ce que ce port 8000 vient faire là au milieu?

[corentin]

Aaaaaah c’est le host_name du site_config.json qui est peut-être mal configuré !!

[Thatoo]

évidement le lien avec le port 8000 ne donne rien mais si j’enlève le port 8000, je trouve bien le contenu du fichier print.bundle.xxxx.css

[Thatoo]

J’ai ça :

[corentin]

Oui il faut définir la clé host_name du fichier site_config.json à une valeur telle que https://monsite.example.com en production, sinon https://localhost:<port> en local/dev.

[corentin]

Pour que le site soit en mesure de bien fonctionner, il faut effectivement lui indiquer son URL. Typiquement, en production, le nom du site est suffisant parce qu’il y a un enregistrement DNS adéquat.

Mais en développement, le site va essayer d’accéder à dokos.local en vain tant que rien n’est ajouté au fichier /etc/hosts, ou alors qu’un host_name est défini.

[corentin]

J’en parlais un peu ici :

@corentin

Il faudra bien faire attention à configurer la variable de configuration host_name pour chaque site du fichier site_config.json, avec par exemple https://base.fr/site1/

[Thatoo]

J’ai changé pour :

Quand j’ai voulu « Obtenir un PDF », ça a planté donc je relance la VM.

[Thatoo]

erreur 504 :

mais par contre les logs de wkhtmltopdf n’ont plus d’erreur…

[Thatoo]

puisque tu me rappelles ce précédent message, je peux t’affirmer que Dokos fonctionne bien sous arm64, il tourne sur un raspi 4. Par contre, j’avais évidemment le même problème de PDF, à un moment je me suis demandé si le pbm ne venait pas justement de là mais depuis, j’ai la même chose en VM ou sur un ordi avec CPU amd64.

[corentin]

Okay superbe, je vais d’ailleurs bientôt sortir des images Docker ARM, j’ai aussi fait quelques expérimentations qui me semblent concluantes.

[corentin]

Il y a le PORT en trop dans https://dokos.local:8000 je crois bien

[Thatoo]

je n’ai pas mis de port dans site_config.json :
"host_name": "https://dokos.local",

d’ailleurs, il n’y a plus d’erreur dans le log de wkhtmltopdf :

mais en revanche, dokos se met en carafe pendant 10 minutes et m’affiche une erreur 504 puis ça revient.

[Thatoo]

En regardant le log de nginx, c’est upstream qui ne répond pas :

[Thatoo]

C’est drôlement sensible car si je mets
"host_name": "https://dokos.local/",
avec le / à la fin, j’ai de nouveau une erreur dans les logs de wkhtmltopdf :

Je renlève le /

[Thatoo]

erreur 504 avec dans les logs de nginx

mais sans erreur dans les logs de wkhtmltopdf.

Bon je crois que je tourne en rond, je vais me coucher.

[Thatoo]

Et bien nous n’étions pas si loin de, je crois, la solution :
"host_name": "https://dokos.local:443",

ça correspond à ce à quoi ça devrait ressembler?