[astaadmin]

osTicket v1.18.3 // osTicket-1.18.3-Awesome-102
PHP 8.2.30 // MySQL 10.11.14 // Apache web server

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 with new installation and my configs  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. 
Upload working finde but logo print with an X 

The issue can fixed by switching to the osTicket core mechanism and embedding the logo via cid: while handling positioning and sizing purely with CSS, making the PDF rendering reliable. But please investigate 

[astaadmin]

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

[astaadmin]

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.

[stevland]

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?

[astaadmin]

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

[astaadmin]

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
 

[stevland]

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.

[astaadmin]

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

[astaadmin]

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.

[stevland]

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.

[astaadmin]

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.

[astaadmin]

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.