Problem/Motivation
Once entity_print is enabled on a website, when re-saving and exporting entity view displays, we get this in "hidden" part:
hidden:
entity_print_view_epub: true
entity_print_view_pdf: true
entity_print_view_word_docx: true
This happens even for entity types that we never ever want to print.
E.g. I found this happening for message templates.
Steps to reproduce
As above.
Proposed resolution
Provide an option to select the entity types for which the extra fields should be added.
Note:
I tried hook_entity_extra_field_info_alter() in a custom module to remove them from some entity types.
However, this does not remove the items in the display form, which then causes errors when visiting the manage display form.
So, it needs to be more sophisticated.
It would also be nice to only have the extra fields on specific view modes.
But this is not possible with how extra fields are done in core.
Remaining tasks
User interface changes
We would have to provide a form where this can be configured.
API changes
Data model changes
Issue fork entity_print-3468563
Show commands
Start 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:
Comments
Comment #2
huzookaI also need the same feature (option to limit entity print to some specified types). I also discovered that extra fields are added to every single entity type, not just to content entity types.
Changing the category to feature request.
Comment #4
huzooka* Added a new config option to restrict print features to entity types.
* Added a config subscriber which resets entity field caches if config value is changed
* Updated hook implementations
* Added test coverage
Asking for review.
Comment #5
claudiu.cristeaNow I can limit entity print only to a limited group of entity types. No more unneeded extra fields and a huge Git diff on config export. Code looks good. Apart from manual testing, I see it has solid test coverage.
Comment #6
huzookaWe just hit an error with this patch applied, checking what's going on (should be obvious imho):
Moving back to NW.
Comment #7
huzookaTh test method I just added should reveal the problem we saw (see #6)
Comment #8
huzookaThere they are!
https://git.drupalcode.org/issue/entity_print-3468563/-/jobs/3536971#L127
Comment #9
huzookaI hope we can get back the RTBC status 🥹
Comment #10
alorencLooks good, moving to RTBC.
Comment #11
alorencComment #12
pilot3 commentedThis approach works well. We have recently started using the Recurring Events module, which creates a custom entity type for all events. We want to add a print option to all event pages. I was able to select the custom entity and configure it to enable printing on event pages.
Comment #13
joseph.olstadThis is a duplicate of
#2928222: Consider to make configurable the entity type on which enable entity print
Postponing in favour of 2928222 since 2928222 is smaller and I've tested it with Drupal 11.1.x
Comment #14
joseph.olstadComment #15
joseph.olstadActually, needs review. Please lets weigh the positives and negatives with both approaches.
#2928222: Consider to make configurable the entity type on which enable entity print
and
this one.
Comment #16
joseph.olstadDisadvantage with 3468563 is there's no way to have zero entity types.
Our use case for entity_print is to have a view that generates a pdf, this works when using patch 2928222 and zero entity_types selected, meaning we have no extra cruff when not needed.
So while 2928222 introduces the requirement to configure the setting it is probably worth makeing a 3.0.x version for 2928222
Comment #17
joseph.olstadI prefer #2928222: Consider to make configurable the entity type on which enable entity print
However let the maintainer weigh in.