This time last month we released version 3.6 of the software which saw major changes to the brand, website and plugin itself. Considering the size of these changes it all went relatively smoothly glorified pat on the back to us.
With that said, we did run into a problem we hadn’t originally considered and feedback from our user-base revealed that the new configuration folder structure which included the site’s domain name wasn’t effective when users were utilising production AND staging environments. For those who aren’t familiar with this new configuration structure it looks like this:
Resolving the configuration structure issue
To help resolve this issue we brainstormed ideas with Thorsten Frommen – he originally brought this issue to our attention and submitted a patch to help resolve it (thanks again Thorsten). The conclusion we came to was to make slight tweaks to the configuration structure and remove the domain names from folders.
In the 3.7 release we opted for the following structure in standard WordPress installations:
/app/uploads/PDF_EXTENDED_TEMPLATES/. It’s similar to folder structure in pre-3.6 releases but still remains in the uploads directory. Whereas for multi-site users we have left the structure the same as 3.6 but changed the directory names to their associated multi-site IDs –
This change will mean there are NO special requirements for Gravity PDF when migrating a website. You can freely drag and drop the PDF_EXTENDED_TEMPLATES directory from site to site.
Like the 3.6 release, 3.7 will automatically migrate your file/folder structure (or prompt you to manually upgrade if there is a permissions issue).
Preventing the problem…
Before every major release we release a beta of the software to get feedback on the new changes introduced. If you rely on our software in your business you should consider yourself a major stakeholder in the ongoing development of Gravity PDF. Don’t just trust blindly. You need to be testing every beta release. If we had more user feedback during the 3.6 beta we could have caught the problem early and fixed it before it ever got to production.
What other changes are in 3.7?
The tweaking of the configuration directory structure isn’t the only change in this release, but there are very limited new features. Instead, we have focused on fixing up a number of bugs that were found while expanding our unit testing, preventing any PHP notices and making the software even more stable.
Introduction of ‘default-show-section-content’
We’ve added a new configuration option to this release called
default-show-section-content. To date, the software has ignored the section break description but can now be enabled with this option.
Usage [codeblocks name=php1]
Much like the other
default- options it only applies to the default templates.
If you want to use this new feature on existing website’s running Gravity PDF you need to reinitialise the default templates. This can be done from the PDF settings page in your admin area –
Forms -> Settings -> PDF.
Added $form_data[‘html_id’] data key
While unit testing we found the
$form_data['html'] key did not allow you to access the HTML fields by its field ID. This is problematic if you remove a HTML field from your form after creating your PDF template.
To prevent problems like this in future, and prevent any backwards compatibility problems, we introduced the
$form_data['html_id'] key which does allow you to access HTML fields by field ID.
You can download the 3.7.0 Beta from GitHub.
Remember, don’t use it in a production environment. You should only test it on a staging server that mimics your existing website, or on a fresh installation.
If you find any bugs or would like to provide feedback about the beta please do so via GitHub.
- Feature – Added
default-show-section-contentconfiguration option. You can now display the section break content in the default template. Note: if this option is enabled and the section break is empty it will still be displayed on the PDF.
- Housekeeping – Migrate your template and configuration files. As of Gravity PDF 3.7 we’ll be dropping the ‘site_name’ folder for single WordPress installs and changing the multisite install directory to the site ID.
- Housekeeping – Added
$form_data['html_id']key which has the HTML fields added by their ID (much like the signature_details_id key).
- Housekeeping – Add large number of unit tests
- Housekeeping – Derestrict certain pages software loads on.
- Housekeeping – Split up PDF viewing security components into smaller chunks (easier to unit test)
- Housekeeping – Remove CLI-checking override in RAM settings
- Housekeeping – Included directory paths by default on the system status page
- Bug – Fixed issue initialising plugin when memory limit was set to -1 (unlimited)
- Bug – Fix Multisite migration problem where if an error was thrown for one of the sub sites it caused all of the sites to show an error (even if they were successful)
- Bug – Fix typo in
- Bug – Fix up notices in custom templates when using poll/survey/quiz add ons.
- Bug – Fix up notice in custom template when the form description is empty
- Bug – Fix up notices in mPDF template when using headers/footers
- Bug – Fix up error in PDF when signature field wasn’t filled in