Currently, PDFs are saved to disk during form submission if the gfpdf_post_save_pdf hook is used, if the PDF is included as an email attachment, when using the Previewer add-on, or using the API.
Those PDFs are then cleaned up from disk:
At the end of the form submission process
At the end of the background processing queue
After the Resend Notification process
Every 12 hours (down from 24 hours)
If multiple notifications are sent on form submission with the same PDF attached, the PDF on disk will be used.
When the new Gravity Forms Async Notification feature is used, the PDFs are not currently cleaned up from disk, but this could be done via the gform_post_process_async_notifications hook.
Over the years various problems have cropped up due to the short lifespan of the temporary PDFs, or PDFs not being cleaned up at a suitable time. Some examples include:
As you can see the lifecycle of the PDF being saved to disk is currently unpredictable, and dynamically generating PDFs on demand over a short period of time is not performant.
Solution
Standardize the PDF lifecycle so it's more predicable and performant:
If a PDF is generated (viewed/downloaded/emailed), it will be saved to the temporary directory
If a PDF already exists in the temporary directory, the cached copy will be served
Remove all existing cleanup routines and replace it with a scheduled task that deletes PDFs older than 1 hour
~If a form or entry is updated/deleted, the associated PDFs will be cleanup from the temporary directory~ The 1 hour cleanup routine will handle this automatically.
The short-lived disk cache strikes a balance between security, performance, and easy-of-use for first- and third-party plugins. If emails are delayed, the PDF attachment files will still be available for at least 1 hour to allow for (re)sending. If the same PDF is viewed many times in a short period of time, the cached version will be served. Provided stale copies of the PDF are automatically deleted from disk when form/entry changes are made, users should always receive up-to-date documents.
Gravity PDF is making use of caching more and more throughout the codebase (templates, fonts, PDFs). Should the caches become stale, we need a simple solution for users to flush all caches. Currently this is tied to Debug Mode, but it's a toggle on/off feature – and not a one-off action – which confuses some users.
To make this simpler for users:
Add a new Clear Cache tool that will handle all templates/fonts/pdfs cache clearing
Remove the UI for Debug Mode and auto-enable it when WP_DEBUG is enabled and/or a new filter is used
Problem
Currently, PDFs are saved to disk during form submission if the
gfpdf_post_save_pdf
hook is used, if the PDF is included as an email attachment, when using the Previewer add-on, or using the API.Those PDFs are then cleaned up from disk:
If multiple notifications are sent on form submission with the same PDF attached, the PDF on disk will be used.
When the new Gravity Forms Async Notification feature is used, the PDFs are not currently cleaned up from disk, but this could be done via the
gform_post_process_async_notifications
hook.Over the years various problems have cropped up due to the short lifespan of the temporary PDFs, or PDFs not being cleaned up at a suitable time. Some examples include:
As you can see the lifecycle of the PDF being saved to disk is currently unpredictable, and dynamically generating PDFs on demand over a short period of time is not performant.
Solution
Standardize the PDF lifecycle so it's more predicable and performant:
The short-lived disk cache strikes a balance between security, performance, and easy-of-use for first- and third-party plugins. If emails are delayed, the PDF attachment files will still be available for at least 1 hour to allow for (re)sending. If the same PDF is viewed many times in a short period of time, the cached version will be served. Provided stale copies of the PDF are automatically deleted from disk when form/entry changes are made, users should always receive up-to-date documents.
Gravity PDF is making use of caching more and more throughout the codebase (templates, fonts, PDFs). Should the caches become stale, we need a simple solution for users to flush all caches. Currently this is tied to Debug Mode, but it's a toggle on/off feature – and not a one-off action – which confuses some users.
To make this simpler for users:
WP_DEBUG
is enabled and/or a new filter is used