You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I understand correctly, we can do this now by passing a path to the filename argument. However, that doesn't work for me. I need to pass the absolute path to the public folder to be able to write to it (local development).
I also don't think this is good practice as the filename the user sees when downloading the file to his computer now includes the path to the file as well. Which doesn't look nice.
So it would be better in my opinion, if we could specify the path to the directory separate from the filename.
UPDATE
Got this working: I had a / at the beginning of the filepath/name which resulted in very strange behaviour.
It would still be better I think to separate these two parameters.
The text was updated successfully, but these errors were encountered:
So for over 100 hundred people, the plugin may encounter issues when using two parameters because the path with a folder is passed to the plugin in the examples. However, you have the flexibility to save PDFs in any writable path or by using aliases in the examples.
For testing purposes, you can pass entries as custom parameters in the pdfOptions with your test environment. You have the flexibility to pass any accessible path on your server, such as /tmp or a subfolder within Craft.
Additionally, you can optimize the PDF generation process by exploring the mentioned parameters of MPDF, which may help improve performance. Version 1.1.0 and 0.2.0 of the plugin introduced these optimizations.
However, in most cases, you will be using the @web alias, as the plugin is designed to generate and update multiple PDFs on the first-page load.
It would be nice if we could set the directory where we want our PDF's to be saved via a config setting.
Cfr. https://mpdf.github.io/installation-setup/folders-for-temporary-files.html
If I understand correctly, we can do this now by passing a path to the filename argument. However, that doesn't work for me. I need to pass the absolute path to the public folder to be able to write to it (local development).
I also don't think this is good practice as the filename the user sees when downloading the file to his computer now includes the path to the file as well. Which doesn't look nice.
So it would be better in my opinion, if we could specify the path to the directory separate from the filename.
UPDATE
Got this working: I had a
/
at the beginning of the filepath/name which resulted in very strange behaviour.It would still be better I think to separate these two parameters.
The text was updated successfully, but these errors were encountered: