Support for printing entity revision

1. +++ b/src/Renderer/ContentEntityRenderer.php
   @@ -40,6 +48,7 @@ class ContentEntityRenderer extends RendererBase {
   +    $this->currentRequest = \Drupal::request();
   

   I don't think the renderer should have anything to do with the request, this seems like the wrong approach.

2. +++ b/src/Renderer/ContentEntityRenderer.php
   @@ -60,7 +69,28 @@ class ContentEntityRenderer extends RendererBase {
      public function render(array $entities) {
   ...
   +    $current_path = $this->currentRequest->getPathInfo();;
   +    $path_args = explode('/', $current_path);
   

   Can we hook in earlier, and pass the loaded revision entities to this method instead?

1. +++ b/src/Controller/EntityPrintController.php
   @@ -76,14 +76,37 @@ class EntityPrintController extends ControllerBase {
   +    if ($revision_id == 'latest') {
   

   I don't like revision_id being latest, does this get the currently published revision or the forward most revision? I think i'd prefer for that to be a separate route.

   I'm also wondering if the access control needs to handle revisions as well?

2. +++ b/src/Controller/EntityPrintController.php
   @@ -76,14 +76,37 @@ class EntityPrintController extends ControllerBase {
   +        $entity = $node_revision = $this->entityTypeManager->getStorage('node')
   ...
   +      $entity = $node_revision = $this->entityTypeManager->getStorage('node')
   

   This shouldn't be hard-coded to node, it needs to work for all entity types. We probably need to check if the entity type supports revisions?

Adding a patch to support revisions for entity_print debug.

@benjy,

I don't like revision_id being latest, does this get the currently published revision or the forward most revision? I think i'd prefer for that to be a separate route.

@benjy, I have changed $revision_id to $revision, since we are reusing the same controller method, I thought it'd be simpler to keep them together. Please confirm if we still need to add new route for 'latest' revision.

$revision in the last patch did not work and throws missing mandatory argument error. Fixed and re-submitting patch.

I've created a new patch. Please review.

New try

Verified and applied patch #14 on Drupal 10.1.x-dev version with entity print v8.x-2.x-dev
The patch applied cleanly.

Steps:
1. Enable entity print module
2. Enable the content moderation module for workflows to have the latest revisions
3. Make necessary changes in the manage display as per the entity print module configuration
4. Create a node and published
5. Create multiple revisions with the latest revision (keep in draft)
6. Click on View pdf of the latest revision and check the changes if available
7. Now, apply the patch -> clear all cache
8. Go to that node's latest revision
9. Click on View pdf of the latest revision and check the changes if available

Result:
After applying the patch, able to print entity revisions as well.

Refer to the attached screenshots
Revision

Before patch pdf:

After patch pdf:

RTBC +1

Hi verified and applied patch #14 on Drupal 10.1.x-dev version setup. The patch applied successfully and cleanly.
Thanks.

I need to create PDFs of revisions, so I tried #14, but it didn't work for me. Although it alters the controller to accomodate printing revisions from PDFs, it seems to be lacking the {revision_id} path parameter for the entity_print.revision.view and entity_print.revision.view.debug routes.

Also, I couldn't apply the patch via git apply due to a case mismatch in EntityPrintController.php: @TODO should be @todo in the patch. This case change was made back in #3104331.

I made the following changes to #14 and got it working for my purposes:

1. added {revision_id} path parameter to the entity_print.revision.view and entity_print.revision.view.debug routes
2. added a missing @param to the viewPrintDebug() document block
3. revised entity_print_entity_view_alter() to add revision_id as a path parameter for the View PDF link.

I'm sure that my revision to entity_print_entity_view_alter() (to alter the View PDF link) is the wrong way to go about this, so consider this patch to be in-progress. It assumes that there's always a revision id, and it works for my specific use case so far. But I'm sure this needs to be improved.

@benjy can I get some feedback on the overall direction of the patch?

Fix fatal error:
Symfony\Component\Routing\Exception\InvalidParameterException: Parameter "revision_id" for route "entity_print.revision.view" must match "[^/]++" ("" given) to generate a corresponding URL. in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 206 of core/lib/Drupal/Core/Routing/UrlGenerator.php).

-        '#access' => $access_manager->checkNamedRoute('entity_print.view', $route_params, NULL, TRUE),
+        '#access' => $access_manager->checkNamedRoute('entity_print.revision.view', $route_params, NULL, TRUE),

With the latest patch we are using access check for the revision page even for the regular non-revision link.
I think it would be cleaner to have two separate paths of control flow.
I am going to prepare an MR.

+   * @param int $revision_id
+   *   The entity revision id.

I think the type needs to be "int|null".
This is what I see a lot in core for parameters with NULL default value.

-  public function viewRedirectDebug($export_type, $entity_type, $entity_id) {
+  public function viewRedirectDebug($export_type, $entity_type, $entity_id, $revision_id = NULL) {
     return $this->redirect('entity_print.view.debug', [
       'export_type' => $export_type,
       'entity_type' => $entity_type,
       'entity_id' => $entity_id,
+      'revision_id' => $revision_id,
     ]);
   }

This seems weird:
The redirect route is only meant for legacy support, so we should not expect this to be called with a revision id.
On the other hand: If we support a revision_id parameter, then we need to conditionally change the route for the redirect to use the revision route.

See also #3448919: Wrong usage of trim() in entity_print_entity_view_alter().
If we solve that, it will conflict with the patches here..

I pushed some what I think are improvements - TBD.
See the individual commit messages.

I should also add tests, but that requires a bit more thinking and searching.

Actually it could be useful to add the revision id or the revision date to the file name of a pdf.

Tested MR following the steps and revision is being printed perfectly.

Something probably that should have simple test coverage.

Don't see any file for moderation so probably could add one to Functional or Kernel folders.

I've added test coverage and improve the MR slightly.

Merged! Thanks everyone!