The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.I think it's about time to start thinking about Features integration for this module. A couple things need to happen before this is possible:
- Uploading a PDF currently saves it to a particular location. We interface with that via the fid from the {files} table. It's a numeric ID, which won't play well with Features. It would be better if we stored the path to the saved file (using the proper stream wrapper prefix, such as public://). Token support could be enabled for this in case people needed to store the file at separate locations on different servers but still wanted to save their configuration in Features.
To properly revert the feature, they'll need the file to exist, of course (I don't exactly want to base64_encode it into the generated module :)), but this is a minor thing in comparison to the potential benefits of exportability.
- There is now a default_nid field. NIDs are numeric, so it would almost certainly be wrong. Exporting it as a UUID instead and fixing it to be the proper NID if UUID Features is detected would be a nice touch. (We would export it as the straight NID otherwise, and the user would have to manually fix it up.)
- hook_fillpdf_default_pdfs would need to be created so that the settings could be stored in code.
- Each Fill PDF configuration would need a machine-readable name.
These are the main points, and this is sort of a meta task. It probably needs to happen in its own branch. I'll create those tasks once I start on this, but anyone who wants to also can. Update the issue summary with the issue links if you do.
Comments
Comment #1
wizonesolutionsI'm not sure if this actually makes sense anymore. The question of the associated PDF file will always get in the way. Postponing indefinitely, will won't fix once I've completed the initial refactoring and not seen a need.
Comment #2
wizonesolutionsComment #3
Anonymous (not verified) commentedHi,
It would be great if features support is implemented.
Is there anyway I can contribute?
Comment #4
wizonesolutionsThe issue summary more or less sums it up. I postponed this because the problem is the actual PDF templates; I don't see a good way to featurize them. They might be quite large, and should a Features module really be large just because of that? Maybe there is a smart way to do it, e.g. storing a reference to the files that Features then downloads and puts into the database at revert time, but I am not sure what it is.
If you would like this, a patch would probably be best, but also just sharing your ideas could help. How would you use the feature? Does not having the integration make deployment harder currently (i.e. just using the import/export functionality)?
Comment #5
aruuska commentedI just want to add note here that I have done exporting thru hook_install. It seems to work okey.
I placed PDF templates in subfolder under my feature, exported json codes with fillpdf export and copy paste codes to .json file in sub folder under my feature. Then code in hook_install insert fillpdf forms and also insert mappings in place. It's a little dirty but it works :)
Comment #6
wizonesolutionsAh, that is a neat approach. Thanks for sharing! If you have any time, that could make a good documentation page, help other users and increase your number of documentation edits on your profile. Add it somewhere under https://drupal.org/documentation/modules/fillpdf.
Comment #7
liam morland