Skip to content

Link to css is hard-coded to the resource url link - problematic for server-side rendering with firewall or htaccess in play

In a few places in the code we add the print.css url with a section like this:

<head>
  <title>{$pageTitle}</title>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <base href="{crmURL p="" a=1}" /><!--[if IE]></base><![endif]-->
  <style type="text/css" media="screen, print">@import url({$config->userFrameworkResourceURL}css/print.css);</style>
</head>

That works fine from print.tpl & presumably the place in CiviCase where it is used but is problematic in CRM_Utils_PDF_Utils

When a pdf is being rendered internally & a firewall or htaccess is in play this css cannot be retrieved via http.

I also encountered someone struggling on chat the other day due to the print.css link written into a report instance being wallopped by the hard coded one when printing a CiviReport - going through that class.

@totten @bgm just trying to figure out the best way to handle this. I feel like in the pdf class it should try the file location FIRST if it does not appear to be customised - I think there might be some handy functions for that?

In the case of the report I think it's a bit trickier - we would need to figure out if a stylesheet is specified & only add one if not - or simply not add the

section. (I don't need to solve this but was thinking about it at the same time)

NB - this is the first issue I have logged in gitlab...

Edited by eileen
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information