Following #3022485: Undefined entity label impedes identifying FillPdfForm, the admin_title is used for more than just the FillPdfForm overview on admin/structure/fillpdf. It is used as the entity label, so shows up on entity_reference fields, on the file usage screen (see also #3023341: Fix FillPdfFileContext label key; add FillPdfForm canonical route) and probably some more places in Core and contrib.
Which is good. Entities don't need to have a label, but without one they are quite hard to identify and work with in quite a couple of situations. It was proposed in #3022485: Undefined entity label impedes identifying FillPdfForm that we would mark the field required, but I was a bit hesitant to do so without having some mechanism in place that automatically creates an admin_title for a new FillPdfForm.
While we could easily create the 'admin_title' from the filename, I'm instead suggesting to create it from the PDF's metadata, specifically the 'title' key.
Yes, in many cases PDF templates will have some random 'title' metadata, autocreated by the application that created the PDF file. But that's a problem in itself for the user, as the title is going to be shown in the PDF reader's title bar.
PDF metadata can be easily corrected by pdftk, so what we should do as the next step is #3040775: Provide API and UI for editing PDF files' actual metadata. But that's the next step. For now this is just about exposing the PDF's 'Title' as 'admin_title'.
Now that we have a sensible autocreation mechanism, we may also mark the 'admin_title' #required to make sure the FillPdfForm under all circumstances has a proper label.
Comments
Comment #2
wizonesolutionsHmm. The interface for parsing doesn't provide for this, and it'd have to be implemented in all backends. Perhaps we default to filename and allow plugins to override it by implementing an interface? Then Pdftk could do that.