The current purpose of this module is global sanitization, but for one of our use cases removing titles from PDF file uploads creates accessibility errors for our files on our site. I explored if we could add file field level sanitization customization, but I think that fights the current architecture too much.
1. Upload a PDF that has a document Title set.
2. Inspect the stored file — the Title is gone.
3. Run an accessibility check (PDF/UA or Adobe Acrobat) → "Title missing" failure.
So to support the ability to allow PDF titles on my site but not force others, I propose on the settings form to allow customization of the allowed tags to keep, but making it file extension aware. This way only pdf files can retrain a title tag for example, and also in the example of a pdf file the exiftool command doesn't try to copy back in an "orientation" tag from images into the pdf.
- [ X ] Configurable global preserve_tags (config, schema, form, validation, update hook) with Extension-aware overrides
- [ X ] Wire into both the runner and the Drush command
- [ X ] Tests (functional form test + unit test) and README update
- [ X ] De-duplicate parsePreserveTags() - it's currently copy-pasted in MetadataSanitizerCommands and MetadataSanitizerRunner; move to a shared helper/service
- [ X ] Decide UX for the extension map customization (textarea key:value vs. structured table) - I went with table
- [ X ] Validation of form configuration to prevent injection of extra Exiftool args like -config
On the settings form retain the Global Sanitization, but based on file extension allow users to customize what meta-data attributes they can retain (jpg/png: Orientation, pdf: Title)
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | settings-after-update.png | 128.45 KB | nicholass |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
nicholassComment #4
nicholassTested Database updates, and it properly updated the orientation for images.
-------------------- ----------- --------------- ----------------------------------------------------
Module Update ID Type Description
-------------------- ----------- --------------- ----------------------------------------------------
metadata_sanitizer 8002 hook_update_n 8002 - Adds the extension-aware preserve_tags map.
-------------------- ----------- --------------- ----------------------------------------------------
// Do you wish to run the specified pending updates?: yes.
> [notice] Update started: metadata_sanitizer_update_8002
> [notice] Configured per-extension preserved ExifTool tags: image-display tags are kept for raster image formats, and all other formats (including PDFs) are fully stripped.
> [notice] Update completed: metadata_sanitizer_update_8002
[success] Finished performing updates.
Comment #5
nicholass@zarabatana - I'll be locally testing this more today, but I think this is a valid approach, I branched the #3583882 since it contained all the ddev changes, I think this makes that issue obsolete, while also providing the PDF customizations I need. I am lately pretty heavy AI user so full disclosure alot of this was AI written, but not vibe coded I did a lot of planning and manual review of the final code with manual changes.
Comment #6
nicholassI have been testing this module on our site we have ~54Gb of images and pdfs, no issues found when processing past files with drush, pdf titles are preserved keeping them ADA compliant, image rotation also works. So going to mark this for review since for our 10.x site it seems production ready for us.
Comment #7
zarabatana commentedThanks, this is a useful improvement, and the overall direction makes sense.
I think there is one important issue to fix before this can be RTBC.
The README/config describes an empty preserve-tags row as meaning “strip all metadata”, for example
pdf: ''. However, the command currently always adds-tagsfromfile=@, even when there are no tags configured to preserve.According to the ExifTool documentation, using
-tagsFromFilewithout specifying tags copies all possible tags from the source file. So an empty preserve-tags row may accidentally copy metadata back instead of fully stripping it.I think
-tagsfromfile=@should only be added when there are actually tags to preserve.It would also be good to add a small test for the empty preserve-tags case, for example
pdf: '', to confirm the file is fully stripped.So I’d keep this as Needs work for now.
Comment #8
nicholassGreat thanks for catching that, I fixed that and made those phpstan fixes, along with a cspell warning, checkout the latest version.
Comment #9
zarabatana commentedThanks @nicholass for the suggestion and for the follow-up work on this.
I updated the DDEV project name to a generic value, the pipeline passed, and the MR has now been merged into
1.0.x.Thanks again for helping improve this.
Comment #11
zarabatana commented