Having Print Designer installed breaks pdf generation via chromium

[Jarif-Junaeed]

Environment

• Frappe version: 16.10.1
• ERPNext version: 16.7.0
• Print Designer version: 1.6.5
• Deployment type: Docker (affects custom and probably production images)

Steps to Reproduce

1. Deploy a standard Frappe/ERPNext Docker stack using the custom image.
2. Install the print_designer app on the site.
3. Create a print format that utilizes the Chrome PDF generator.
4. Attempt to generate a PDF of any document using that format.

Actual Behavior

The PDF generation fails instantly, throwing a ValidationError stating that Chromium is not downloaded, even though the chromium-headless-shell binary exists in the container.

Traceback:

Traceback (most recent call last):
  File "apps/frappe/frappe/app.py", line 102, in application
    init_request(request)
    ~~~~~~~~~~~~^^^^^^^^^
  File "apps/frappe/frappe/app.py", line 203, in init_request
    frappe.call(before_request_task)
    ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
  File "apps/frappe/frappe/__init__.py", line 1129, in call
    return fn(*args, **newargs)
  File "apps/print_designer/print_designer/pdf_generator/pdf.py", line 21, in before_request
    FrappePDFGenerator()
    ~~~~~~~~~~~~~~~~~~^^
  File "apps/print_designer/print_designer/pdf_generator/generator.py", line 48, in __init__
    self._initialize_chromium()
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "apps/print_designer/print_designer/pdf_generator/generator.py", line 81, in _initialize_chromium
    self._find_chromium_executable() if not self.CHROMIUM_BINARY_PATH else self.CHROMIUM_BINARY_PATH
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "apps/print_designer/print_designer/pdf_generator/generator.py", line 94, in _find_chromium_executable
    frappe.throw("Chromium is not downloaded. Please run the setup first.")
    ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "apps/frappe/frappe/utils/messages.py", line 159, in throw
    msgprint(
    ~~~~~~~~^
        msg,
     ^^^^
    ...<7 lines>...
        allow_dangerous_html=allow_dangerous_html,
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "apps/frappe/frappe/utils/messages.py", line 118, in msgprint
    _raise_exception()
    ~~~~~~~~~~~~~~~~^^
  File "apps/frappe/frappe/utils/messages.py", line 59, in _raise_exception
    raise exc
frappe.exceptions.ValidationError: Chromium is not downloaded. Please run the setup first.

Technical Analysis

The issue appears to originate specifically from the print_designer app's configuration checks. Standard Frappe looks for the chromium_path key in common_site_config.json, which is populated by default in the existing Docker setups due to #1815.

However, print_designer expects the key chromium_binary_path or looks for a chromium directory in the local bench directory. When it fails to find this specific key, it assumes Chrome is missing entirely leading to the failure. Not exactly sure as to why they're using two different keys (chromium_binary_path vs chromium_path)

(Note: It is highly likely this issue does not exist on stacks where print_designer is omitted, as the core Frappe generator relies on chromium_path, but I have not explicitly tested a clean stack without the app to verify).

Proposed Fix / Workaround

For anyone currently experiencing this, you can fix it by adding the expected key to your common_site_config.json during the configurator initialization.

Add the following to the command section of the configurator service in your docker-compose.yml:

bench set-config -g chromium_binary_path /usr/bin/chromium-headless-shell;

[Rocket-Quack]

First of all, thank you for the suggestion of a temporary fix 😄

However, from my point of view I would not change this in this docker_frappe repo but in print_designer.

Because in my opinion the repo print_designer deviates from the norm in terms of how the path to Chromium should be specified. Frappe itself also uses the chromium_path from the site config. (Chromium Frappe Path)
If you want to create an issue there with a link to this issue.

In my opinion print_designer needs to add a fallback to chromium_binary_path in this case chromium_path

[Jarif-Junaeed]

First of all, thank you for the suggestion of a temporary fix 😄

However, from my point of view I would not change this in this docker_frappe repo but in print_designer.

Because in my opinion the repo print_designer deviates from the norm in terms of how the path to Chromium should be specified. Frappe itself also uses the chromium_path from the site config. (Chromium Frappe Path) If you want to create an issue there with a link to this issue.

In my opinion print_designer needs to add a fallback to chromium_binary_path in this case chromium_path

Yeah, I was also wondering if this should fixed in print_designer rather than here. I'll open an issue over there as well.

[github-actions]

This issue has been automatically marked as stale. You have a week to explain why you believe this is an error.