Error generating document: Failed to generate PDF with DOMPDF

I have the same error as #110 🐛 Error generating document: Failed to generate PDF with DOMPDF Needs work With patch from 118 and entity_print 2.11 and dompdf v1.2.2 as v2.0.1. But even with dompdf v2.0.1 it's not working.

v2.0.1 of dompdf is working for us with the latest entity_print release.
This patch is still working for me provided that I put in a base_url

I have some css resources that it otherwise can't load and throws an error if the base_url isn't set thanks to the patch.

This is the patch that we're using. Otherwise http://default/sites/default/files/css/xyz.css never resolves to our css
but when we put http://domain.docker.localhost into the base_url setting provided by this patch number 116, it works.

    "drupal/entity_print": {
      "2865185 - DomPDF incorrect url internally to docker container, override with setting.": "https://www.drupal.org/files/issues/2023-01-18/entity_print-dompdf_base_url-2865185-116.patch"
    },

@Rar9 @kwinten-hardies you should probably check the output HTML for printing. Do you have HTML5 Parser enabled for Dompdf plugin?

Html parser is enabled, and base url is defined to point to our css.

Watch the html for what?

@Rar9 probably check for malformed HTML. The error message from dompdf likely relates to the HTML structure instead of remote assets.

I notice that Entity Print 8.x-2.11 introduced a new root setting Base URL:

It also has the entity_print.post_render_subscriber event subscriber to change all root relative URIs in <link href>, <a href>, and <img src> into absolute URLs using the new base URL setting above.

I have tried to remove the patch from this issue and instead use that new Base URL setting and notice that dompdf is still able to load CSS/images on my Docker-based project.

I wonder if this issue is still valid with the new setting.

For me, it seems like this new Base_url field in entity_print 2.11 does not work for us.

We have differences between stages, we are coping with like installations which can not curl themselves at all, installations which can curl only via localhost, installations which can resolve their domain names and docker / ddev for development.
And then there is multisite, we have to deal with. Further, we are using it with webform, which has some special issues when private files and the signature field are used.

I got it working in ddev / docker, but not at installations which can call themselves only via localhost. It, too, seems that the file:/// syntax is not supported.
If the patch is applied against 2.11 it doesn't work either. I guess the base_url field form module needs to be overridden to bring back the previous behavior.
Meanwhile, I'll roll back to the patched 2.7 and try to figure out if a differently patched 2.11 would be an option.

With this there are now two base url fields, so we need to rework it to use the root base url field

This patch works for me on Drupal 10

The issue continue for me, comparing the patch 113 and the patch 129, I see that two lines are not adding in the patch 129.

Re-rolled #132 + fixed coding standards for version 2.13

ready for review MR https://git.drupalcode.org/project/entity_print/-/merge_requests/19/diffs

patches were not up to date with latest version (and were not tested as base_url was not even passed through)

can we please stick to git-flow with patches?

Re-rolled patch file from #116 and #133 on the latest 8.x-2.13. This new patch now uses the root base_url setting from entity_print.

Adding the missing line in the patch #132

Re #137 The missing line was missing for a reason, it is not needed 😉
Re #136 Your patch is omitting a fix from the MR and adding a schema field which is unused in this issue? If it's missing it should be added in it's own issue, not as part of a different issue.

Re #134/#135 I reviewed the merge request and to me this seems okay. The Base URL is properly passed now.

Let's stick to the MR now.

Can we get an issue summary update here and have the redundant MRs and patches hidden.

There are two MRs so I'm not sure which one is RTBC

Additionally the issue summary talks about the issue being something to do with settings.php, let's update it to reflect the new approach.

Let's stick with the latest MR as it's more complete as the other patches.

BramDriesen → changed the visibility of the branch 2865185-error-generating-document to hidden.