Resolved from 1.18.2 to 1.18.3, the logo is missing in the ticket print / PDF view

Hello,

after upgrading osTicket from 1.18.2 to 1.18.3, the logo is missing in the ticket print / PDF view when using osTicket Awesome.

What I tested
Replaced ticket-print.tmpl.php with the original osTicket 1.18.3 core version → logo works
Re-applied osTicket Awesome → logo broken again
File permissions and paths are correct

Comparison
1.18.2 + osTicket Awesome → OK
1.18.3 + osTicket Awesome → FAIL
1.18.3 + core print template → OK
This points to an incompatibility in the Awesome print template with osTicket 1.18.3.

Please investigate and update the print template accordingly.

Best regards

Additional information

I also noticed that avatars are not rendered correctly in the ticket print / PDF view.
Instead of the avatar image, only an “X” placeholder is shown.

This issue only occurs with osTicket 1.18.3 + osTicket Awesome.
Using the core 1.18.3 print template, avatars are printed correctly.

This further supports that the Awesome print template is not fully compatible with osTicket 1.18.3.

Hi astaadmin,

Thank you for your detailed reports. But I tested osTicket 1.18.3 with osTicket Awesome and cannot reproduce either issue:

Logo: Displays correctly in PDF print. The pdf_logo() function is already present in osTicket-1.18.3-Awesome-102 (line 172-173 in include/staff/templates/ticket-print.tmpl.php). Please verify your file contains:

require_once $_SERVER['DOCUMENT_ROOT'] . ROOT_PATH . "/osta/php/functions.php";
$custom_logo = pdf_logo(get_config());

If not, please re-extract from the release zip.

Avatars: Avatars are not rendered in PDF print by design (in both vanilla osTicket and osTicket Awesome). I cannot reproduce the "X placeholder" issue. Could you provide a sample PDF showing this, and confirm whether you have any
custom modifications?

Additional testing: 
I can reproduce the missing logo in PDF issue on our side, regardless of whether a custom logo is enabled or not. Neither the custom logo nor the default osTicket logo is rendered in the PDF.

Tested with a clean installation:

uploaded the release ZIP
extracted it
applied permissions
copied only include/ost-config.php
(no other changes)
The issue occurs with osTicket 1.18.3.
Running the exact same steps with 1.18.2 on the same server (same permissions, same config) works fine and the logo is shown.

This looks like a regression in 1.18.3.

Please let me know where I should upload a sample PDF.

Environment details:

PHP: 8.2.30 testet also with 8.3, 8.4
Extensions: gd, mbstring (no imagick)
PDF engine: no mPDF detected (class_exists returns false)
osTicket: 1.18.3
Install type: clean install, only ost-config.php copied

Same setup with osTicket 1.18.2 works fine (logo rendered in PDF).
Issue appears only with 1.18.3.

Best regards

Hello, 

Ive done some inspections here my conclusion please check this out and may resolve this in a new version if my inspections are correct: (i am not sure) 

The missing logo in ticket print / PDF view under osTicket 1.18.3 is not a server, permission, or osTicket core issue.
It is an incompatibility between the osTicket Awesome print template and mPDF ≥ 8.1, which is used starting with osTicket 1.18.3.

Test environment (minimal, reproducible):

PHP 8.2.x (also tested with 8.3 / 8.4)
Apache or Nginx
PHP extensions: gd, mbstring
no imagick
allow_url_fopen = Off
allow_url_include = Off
Software:

osTicket 1.18.2 (baseline)
osTicket 1.18.3
osTicket Awesome 102
mPDF:

1.18.2 → mPDF 8.0.x
1.18.3 → mPDF 8.2.7
Reproduction steps:

Working baseline
Fresh osTicket 1.18.2 installation
Install osTicket Awesome
no changes
allow_url_fopen = Off
Print ticket to PDF
Result: Logo renders correctly.

Failing case
Same server, same PHP config
Fresh osTicket 1.18.3 installation
Install osTicket Awesome
no changes
allow_url_fopen = Off
Print ticket to PDF
Result:

Logo missing (red X)
Avatars missing (red X)
Control test
Replace Awesome print template with the osTicket 1.18.3 core template
Print again
Result:

Logo renders correctly
This confirms the issue is in the Awesome print template, not in osTicket core.

Root cause:
The Awesome print template outputs image sources like:

In mPDF 8.0.x, root-relative image paths were often implicitly treated as local files.
Since mPDF 8.1, these paths are classified as URLs.
mPDF attempts HTTP(S) fetching, which fails when allow_url_fopen = Off.
This results in the red X placeholder in the PDF.

Why it worked before:
The behavior in mPDF 8.0.x was implicit and undocumented.
The Awesome template relies on this old behavior.
With mPDF ≥ 8.1 (osTicket 1.18.3), this no longer works.

Why core works:
The osTicket core uses pdf_logo() and embeds the logo internally (cid / local).
No URL-based image loading is used in PDFs.

Conclusion:
This is not an osTicket regression.
It is a template compatibility issue in osTicket Awesome caused by changes in mPDF ≥ 8.1.

Recommended fix:

Embed the logo via pdf_logo() / cid / Base64
Avoid URL-based images in PDFs
 

If you haven't done so already, please update to osTicket-1.18.3-Awesome-103. This issue is fixed and there are many new features.

I still habe the same error in the latest rev04. So i dont know what you did - but it fixed nothing? 

Your Rev 103 change does not actually fix the rendering issue.

It only switches the PDF logo source to the theme custom logo, but still uses a normal reference. This still depends on URL-based image loading.

In environments where allow_url_fopen = Off, mPDF cannot load these image sources, which results in broken images.

This is why:

Rev 104 still shows broken avatars and logos
forcing pdf_logo() to return null restores the osTicket core CID-based logo
enabling allow_url_fopen immediately fixes everything
This proves that the issue is not the logo source, but the image loading mechanism.

Hi astaadmin,

You're right: the issue persists when allow_url_fopen is disabled. Thanks again for your patience and for
the detailed diagnosis that pointed me in the right direction.

The earlier fix I provided was a partial fix. But it turns out the issue persisted if one has allow_url_fopen set to Off, which apparently you do.

Fix: Edit osta/php/functions.php. Three changes:

1. get_print_logo() — custom logo path (~line 225)

Change:
return ( isset( $config["upload-dir"] ) ? $config["upload-dir"] : "" ) . $config["custom-print-logo"] ;
To:
return $_SERVER["DOCUMENT_ROOT"] . ( isset( $config["upload-dir"] ) ? $config["upload-dir"] : "" ) .
$config["custom-print-logo"] ;

2. get_print_logo() — default logo path (~line 228)

Change:
return ROOT_PATH . "osta/img/ost-print.png";
To:
return $_SERVER["DOCUMENT_ROOT"] . ROOT_PATH . "osta/img/ost-print.png";

3. pdf_logo() — remove cache-buster (~line 389)

Change:
src="<?php echo get_print_logo( $custom )?>?<?php echo time(); ?>"
To:
src="<?php echo get_print_logo( $custom )?>"

This changes the image source from a URL path to an absolute filesystem path, so mPDF reads directly from
disk regardless of your allow_url_fopen setting.

Alternatively, you can re-download revision 104 — the updated zip includes this fix.

Thanks, the logo is working now.
Could you also apply the same fix to the avatars in the PDF print output?

The avatars have the same issue there and show a red X when allow_url_fopen is disabled.

Since allow_url_fopen is usually disabled for hardening reasons, it should generally remain turned off.

any news about that? 

Could you also apply the same fix to the avatars in the PDF print output?

The avatars have the same issue there and show a red X when allow_url_fopen is disabled.

Could you also apply the same fix to the avatars in the PDF print output?

The avatars have the same issue there and show a red X when allow_url_fopen is disabled.

Since allow_url_fopen is usually disabled for hardening reasons, it should generally remain turned off.

Could you reproduce that issue too with allow_url_fopen is usually disabled /for security reasons? 

Hi @astaadmin,

Apologies for the long silence here. The last several weeks have gone into rebuilding the entire website, rebranding osTicket Awesome as osAwesome and launching a new subscription system. Your follow-up got buried in the noise of that. Thanks for your patience.

The substantive answer: avatars in printed PDFs aren't really a bug we can fix. Vanilla osTicket doesn't render avatars in PDF print output either, and as of osTicket-1.18.3-Awesome-105 we've simplified our print template to match that behavior. If you update to 105, the red X you've been seeing should disappear, because the avatar <img> tags simply aren't being emitted anymore.

In earlier templates, avatars in PDFs were broken in different ways depending on the allow_url_fopen setting — broken images when off (your case), or generic Gravatar mystery-person silhouettes when on. Neither was actually useful, so we landed on the same behavior as vanilla: don't try to print them at all. The agent/user name above each thread entry identifies the speaker, which is how vanilla osTicket has always worked.

If avatars in PDFs would genuinely add value for your workflow, I'll recommend logging it as a feature request for a future release. It's a non-trivial change — to render reliably under hardened PHP configurations like yours, we'd need to pre-render each avatar server-side and embed it as base64 in the PDF — but if there's interest from you and others, we can look at it down the road.

Thanks again for the excellent diagnostic work earlier in this thread. Your allow_url_fopen analysis on the logo issue is what made that fix possible, and I appreciate you sticking with this one.