Add support for generating a separate PDF per domain

Created on 13 December 2024, 9 days ago

Problem/Motivation

Currently, storing PDF's on a field on the node is required. This makes it so there can't be multiple variations of the same PDF. This is something we need in order to support the Domain module → : one node can be shown on multiple domains and can be themed differently per domain. The PDF of a domain should be able to be themed (and stored) differently per domain as well.

Proposed resolution

  • Change PdfGeneratorBase::getFinalPdf() to query for the right media entity directly instead of extracting it from a field. We could do this by adding a reference field to the media type, pointing to the node. We could also store this information in keyvalue for example.
  • Change PdfGeneratorBase::saveFinalPdf() to make storing the file on a field optional
  • Add an alter hook to change in which media entity a PDF is stored
  • Add a page_to_pdf_domain submodule (or in a separate project)
    • Adds an option to choose for which domains a PDF should be generated
  • Adds an implementation of the new alter hook that changes the media entity in which the PDF is stored depending on the domain

User interface changes

None, only the new configuration option.

API changes

TBD.

✨ Feature request
Status

Active

Version

1.0

Component

Code

Created by

🇧🇪Belgium dieterholvoet Brussels

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @dieterholvoet
  • 🇧🇪Belgium dieterholvoet Brussels
  • 🇧🇪Belgium dieterholvoet Brussels

    @scott_euser what do you think? I'm probably going to start implementing this on Monday.

  • 🇬🇧United Kingdom scott_euser

    I think the proposed resolutions are 'OR' right? If so I think any of options 2-4 are fine. I guess 2 & 3 would be least work for you but if you think others could benefit from 4, sounds great too!

    On option 1, I am worried it will remove features. E.g. some things we have some clients using:

    1. Translation of fields in/surrounding media, the UX let's them translate on the node page
    2. Access control in members area auto-applying to attachments via Entity Usage
    3. Ability for clients to e.g. maybe start with a quick page to PDF and use that for most, but then maybe more important annual report or something they decide to replace with an InDesign curated version

    Thanks for your contributions in any case!

  • 🇧🇪Belgium dieterholvoet Brussels

    I created a branch from ✨ Add option to automatically generate PDFs after saving nodes in a queue Active because there's too much overlap, so the changes from that MR are also in this one. We should merge that one first and then rebase this one. The current implementation seems to work for my use case, but it still needs some more testing.

    I also added the page_to_pdf_domain submodule that provides the integration with the domain/domain_access modules. For now it only creates queue items, it doesn't work yet with the batch way of doing things.

  • 🇧🇪Belgium dieterholvoet Brussels

    Any feedback is welcome!

  • 🇬🇧United Kingdom scott_euser

    Thanks! So this is 'Needs work' in that you want us to review & merge the issue mentioned in #5 first?

  • 🇧🇪Belgium dieterholvoet Brussels

    Yes, but this one also needs a little more testing IMO. Not working today, but I’ll try to do that tomorrow or Friday.

  • 🇬🇧United Kingdom scott_euser

    Just had a quick look at the WIP and it seems its going down the key value store direction; ie, the option 1 from the issue summary (converted IS to ol from ul now to be clear) which I raised concerns about in #4. If you feel you really need a different storage than Media/File fields maybe its better to have load/save in a service so you can replace the service in your own way for your projects?

Production build 0.71.5 2024