[version-12] DNS-based mutitennancy destroys PDF format

Install / Update Deployment
1

Continuing the discussion from Multitenant production server setup:

I added a second site based on the linked Topic. This worked without any problem on first sight.

However the formatting of PDF’s created from a SINV and other documents (by clicking the PDF button on the print preview) does not work anymore. The entire Layout (Logo on Top, Layout of the print) is lost after clicking the PDF button.

The only workaround I can get running is to use PRINT (instead of PDF) from the Print Preview and save a pdf from there.

Any idea how to get around this misbehavior? I would suggest wkhtmltopdf being responsible for the translation to PDF but as I have not done anything to the codebase itself (and also it work going via PRINT leaves me puzzled to some extent.

1 Like
2

Make sure you have set correct hostname in the new site’s site_config.json file.

1 Like
3

hm, the issue appears in the original instance. I did not even get to trying the new instance (maybe I should have mentioned that).

Will check on your Tip for the next trial (had to roll back due to that issue)

4

added hostname, host_name, ssl_certificate & ssl_certificate_key entries to the site_config.json of my new site.

still the problem persists (on both sites)

5

The site_config value isn’t hostname but domains:

https://frappeframework.com/docs/v13/user/en/bench/guides/adding-custom-domains

This would often be set up when you configure the multi-tenancy, but if it didn’t get added then you might need to configure it manually. Otherwise, wkhtmltopdf calls face addressing issues.

6

thx, but maye there is a misunderstanding?

  1. I am on version-12 (not sure whether relevant)
  2. I do not want to add another domain to a site, but add a new site (which naturally uses a different domain then the default site)

that being said … does your comment …

… still has relevance?

this is the working site_config.json for my default site

{
 "db_name": "some_db_name",
 "db_password": "********************",
 "encryption_key": "*************************************************",
 "hostname": "https://site.domain.com:443",
 "limits": {
  "space_usage": {
   "backup_size": 82.0,
   "database_size": 52.21,
   "files_size": 36.0,
   "total": 170.21
  }
 },
 "ssl_certificate": "/etc/letsencrypt/live/site.domain.com/fullchain.pem",
 "ssl_certificate_key": "/etc/letsencrypt/live/site.domain.com/privkey.pem"
7

No, I definitely understand the problem you’re having. I’ve had it too, and there are several threads about this issue on the forum.

There are a number of different things that can lead to this issue, but at core the problem is that wkhtmltopdf is not able to access your css file locally. It usually takes some troubleshooting to fix, but explicitly setting your domain is often one of the necessary steps. Updating your /etc/hosts file is also sometimes necessary.

Unfortunately, wkhtmltopdf is a fussy creature, and it’s created a challenge for many.

8

It should be host_name: "https://site.domain.com", but as @peterg pointed above, it could either be caused by hostname or by some other issue. Also, you don’t require ssl details in the config usually.

9

I recently started having trouble again, which seemed to be related to an older version of wkhtmltopdf (0.12.4). I upgraded (to 0.12.6), and it’s working again. It’s a fussy thing, and thankfully wkhtmltopdf is being replaced in v14, but for now that’s another thing worth trying.