With the new entity_print sub-module I get a error when the template is populated with custom css.

"Unexpected problem, please try again later"

Deleting everything from the css field in the template section solves the problem.

Entity print is set up with dompdf.

The error:

Auf der Website ist ein unvorhergesehener Fehler aufgetreten. Bitte versuchen Sie es später nochmal.Dompdf\Exception: Invalid CSS selector syntax: missing attribute name in Dompdf\Css\Stylesheet->_css_selector_to_xpath() (line 798 of /path/vendor/dompdf/dompdf/src/Css/Stylesheet.php). 

Dompdf\Css\Stylesheet->apply_styles(Object) (Line: 711)
CommentFileSizeAuthor
#22 3052597-22.patch14.1 KBjrockowitz
#21 3052597-21.patch10.56 KBjrockowitz
#19 2019-05-13_09-54-entity-print-cas.png31.29 KBbrt
#18 3052597-18.patch1.03 KBjrockowitz
#16 3052597-16.patch1.31 KBjrockowitz
2019-05-04_10-42_entity_print.png39.33 KBbrt
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

brt created an issue. See original summary.

jrockowitz’s picture

jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commented
Status: Active » Postponed (maintainer needs more info)

Using the below CSS in /admin/structure/webform/config. I am not able to replicate this error using DomPDF (/admin/config/content/entityprint)

/* Remove page margins and padding and rely on the PDF generator's default margins. */
body {
  margin: 0;
}

.page {
  padding: 0;
}

Are you using any additiona custom CSS?

jrockowitz’s picture

jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commented

I found this useful DomPDF CSSCompatibility.

brt’s picture

brt CreditAttribution: brt commented
Status: Postponed (maintainer needs more info) » Active

I'll do some more testing. Currently I'm having this issue with exactly the same (default) css code as in your example in #2.
I can repeatedly induce and remove the problem by including and deleting this code.
This is using 5.3-beta with no patches on core 8.7

Edit:
Just tried it with just the comment line from the default example:

/* Remove page margins and padding and rely on the PDF generator's default margins. */

and have the same error.

jrockowitz’s picture

jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commented

Are you using Composer to install the Entity Print module and DomPDF?

jrockowitz’s picture

jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commented

Have you examined the PDF debug HTML version?

brt’s picture

brt CreditAttribution: brt commented

Sorry for the delay. We still have this problem, on different machines.
When activating the debug option and viewing the html, everything seems fine.

How can we help debugging this?

jrockowitz’s picture

jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commented

Since I can't replicate this issue we need to document what versions of Drupal, Webform, Entity Print, and DomPDF we are each running.

Below is what I am running locally.

  • Drupal 8.7.1
  • Webform 5.3-dev
  • Entity Print 2.10
  • DomPDF v0.8.3

When viewing the HTML version can you looking the CSS file and past the contents here. The path is /webform_entity_print/css/{WEBFORM_ID}

brt’s picture

brt CreditAttribution: brt commented

The css file contains exactly what is in the template->css field.

It seems as if DomPDF is messing it up then.

We have a simelar set-up as you:

  • Drupal 8.7.1
  • Webform 5.3-beta1
  • Entity Print 2.1
  • DomPDF v0.8.3
jrockowitz’s picture

jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commented

What server and OS are you using?

I am on OSX using Apache (via Homebrew)

What happens if you just include a simple /* comment */ with nothing else in the Entity Print CSS? Does DOMPDF still throw an error?

Have you tried replicating this issue using a plain vanilla instance of Drupal?

brt’s picture

brt CreditAttribution: brt commented

Servers where I've seen the problem
- Ubuntu 18.04 and CentOS (local and hosted)

CLients:
- FF 66 on Ubuntu
- FF 66 on Windows

brt’s picture

brt CreditAttribution: brt commented

And yes if I just add a comment DOMPDF still throws the error.

jrockowitz’s picture

jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commented

Have you customized the entity print module?

Is /modules/contrib/entity_print/css/entity-print.css being included in the Entity Print template?

Are you able to manually alter the CSS in /modules/contrib/entity_print/css/entity-print.css?

brt’s picture

brt CreditAttribution: brt commented

1) No changes to entity print module

2) Yes included are:
"/modules/contrib/entity_print/css/entity-print.css?xyz"
"modules/contrib/webform/modules/webform_entity_print/css/webform_entity_print.css?xyz"
"/webform_entity_print/css/test_anhaenge?xyz"

3) Do you mean if changes to the file get rendered in the browser? If yes, yes they do.

Question:
Looking at this error output:
"Fehler beim Erzeugen des Dokuments: Failed to generate PDF: file_get_contents(http://test.local/webform_entity_print/css/test_anhaenge?pr8x6o): failed to open stream: Connection timed out, Unable to load css file http://test.local/webform_entity_print/css/test_anhaenge?pr8x6o"

Since this pdf/html/css can only be called when logged in, might it be that DomPDF can not access the css?

jrockowitz’s picture

jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commented

This is now starting to make sense. The custom entity print CSS is only accessible if the user can view the webform. This is probably the wrong approach.

jrockowitz’s picture

jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commented
FileSize
3052597-16.patch1.31 KB

Does the attached patch solve the problem?

I am not sure we can just allow anyone to view a webform's CSS and JS.

jrockowitz’s picture

jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commented

Steps to reproduce this issue

  • Go to the default Contact form (/form/contact)
  • Remove anonymous access from the Contact form (/admin/structure/webform/manage/contact/access)
  • Generate a test submission (/webform/contact/test)
  • Attempt to download the test submission as a PDF.
  • Confirm the below error is displayed.

Error generating document: Failed to generate PDF: file_get_contents(http://localhost/wf/webform_entity_print/css/contact?prc94x): failed to open stream: HTTP request failed! HTTP/1.0 403 Forbidden , Unable to load css file http://localhost/wf/webform_entity_print/css/contact?prc94x

jrockowitz’s picture

jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commented
Status: Active » Needs review
FileSize
3052597-18.patch1.03 KB

I can confirm that the attached patch fixes this issue. The problem is when a PDF is rendered by a server an anonymous request is being made to the dynamic CSS. Dynamic CSS has to be available to anonymous users.

The original thinking behind checking that a user can view a Webform to access the dynamic CSS and JS was to add a little extra but somewhat unnecessary layer of security. Site builders assume that all CSS and JS is publically available..

Custom CSS is very unlikely to contain any business logic in comments while it is possible that custom JavaScript contains some business logic.

The attached patch exposes custom CSS to all users while still checking that a user can access the Webfrom to access the custom JavaSrcipt.

brt’s picture

brt CreditAttribution: brt commented
Status: Needs review » Active
FileSize
2019-05-13_09-54-entity-print-cas.png31.29 KB

Tried the patch but it does not seen to work.

My guess:
We are using CAS for SSO and have no anonymous access to any content.

For the webform_entity_print module the CAS authentication seems to be trigered by the server and fails, as does DomPDF.

It is not a general entity_print problem.

jrockowitz’s picture

jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commented

One solution would be to refactor how webform entity print CSS is included and write the CSS to a static file which will bypass all authentication related issues. This is a lot of work.

jrockowitz’s picture

jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commented
Status: Active » Needs review
FileSize
3052597-21.patch10.56 KB

The attached patch moves all custom webform entity print CSS into

tags which prevents any of the access control related issues.
jrockowitz’s picture

jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commented
Issue summary: View changes
FileSize
3052597-22.patch14.1 KB

The attached patch includes a little more cleanup. I am 99% sure this approach solves the problem.

I also updated the change record.

jrockowitz’s picture

jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commented
brt’s picture

brt CreditAttribution: brt commented

Patch from #21 works!! Great

#22 fails to apply

  • jrockowitz committed 494f3c9 on 8.x-5.x 
    Issue #3052597 by jrockowitz, brt: Entity print: css template error
jrockowitz’s picture

jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commented
Status: Needs review » Fixed
Thank you for helping make the Webform module and our community a little better and stronger.

BTW, I am going to tag another beta release.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.