[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.

[stevland]

I love the idea, but it’s more of an upstream feature request.

[stevland]

It’s been a month with no response so I’ll mark this as ‘Resolved’ for now. But you can still add another comment if the issue hasn’t been resolved.

[stevland]

What version of osTicket Awesome are you guys running?

[stevland]

This extremely rare issue was resolved in osTicket-1.18.3-Awesome-104.

[stevland]

I’m not 100% certain what you’re seeing as it isn’t something I’ve run into before, and it’s a little hard to picture without screenshots.

That said, based on your description, it sounds like it is probably an upstream osTicket glitch rather than anything
specific to osTicket Awesome.

You can verify whether or not that is true by pressing SHIFT + O on your keyboard, which puts you into a vanilla osTicket environment. From there you can attempt the same steps to open a ticket. If the same issue occurs you’ll know that it isn’t something introduced by osTicket Awesome.

Having said that, you should also try going to Admin Panel > Manage > Help Topics, and setting one of your topics as the Default if there isn’t one set already. That way the Ticket Details fields should load immediately when the page opens, rather than waiting for you to select a topic.

If the issue doesn’t occur in vanilla osTicket and setting a default Help Topic doesn’t solve the issue, a screenshot or screen recording of what you’re seeing before and after the error would go a long way.

Let me know.

[stevland]

Hi @cgimicro,

Thank you for raising this issue.

I will fix it right away.

But for you I have prepared this hotfix with two files. Just drop them in the appropriate locations (once you look in the zip it will be self-explanatory) and you’ll be enjoying full Dark Mode again.

[stevland]

Hi @cbd4-dk,

Thank you for taking the time to report this.

Your solution is correct. That CSS doesn’t seem to be necessary and the multi-select form field works better without it.

The fix will be included in the next release.

[stevland]

Hi Carsten,

Thanks for the detailed writeup. You’ve clearly put some thought into this, and the use case is completely legitimate.

To answer directly: there’s no supported programmatic download mechanism at the moment. The download page is session-gated in a way that won’t survive scripting, which is exactly what you ran into. HTTP Basic Auth and token-based download endpoints aren’t something the current stack provides.

I’ve logged this as a feature request. An authenticated download API (where you provide a license key and get a verified download URL back) is a great idea and a reasonable ask.

In the meantime, the most practical workaround is to watch the version endpoint we publish (the same one osTicket Awesome uses internally to display the update notification) and trigger a manual download from there when a new release appears. It’s not fully automated, but it gets you the detection half of the problem without wrestling with session auth.

Appreciate you raising this.

[stevland]

Hi Carsten,

Great catch, and thank you for the thorough diagnosis. You’ve nailed the root cause exactly: when getAvatar() is called without a size parameter, the empty string slips through to imagecreatetruecolor() as zero.

This has been fixed in release 1.18.3-4, but if you’d rather not update right now, you can fix it in place by adding this line near the top of the render function in osta/php/avatar-initials.php, just before the image generation call:

$size = max((int)$size, 80);

Thanks for reporting this!

[stevland]

Hi bit111,

Sorry for your trouble. And thank you for reporting this glitch.

I have fixed the issue in the current 1.18.3-4 release. So either download it and reinstall it again, or simply download this hotfix with the 3 affected files. Place them in:

include/client/footer.inc.php
include/client/login.tpl.php
include/staff/login.tpl.php

Thank you for your patience!

[stevland]

Hi halmaclean,

Apologies for the very late response! Your original post was almost certainly caught by our spam filter (Akismet), which we’ve since discovered was being overly aggressive with legitimate forum posts. That issue has been resolved, but unfortunately yours slipped through the cracks. Sorry about that!

Regarding the Mailjet issue: I trust you’ve gotten this sorted by now. But if you’re still having issues, here’s the key thing to know: osTicket Awesome doesn’t modify the email-sending code in osTicket core. It’s purely a UI/theming layer, so the SMTP handling is all core osTicket.

The quickest way to confirm this: press SHIFT+O to switch into vanilla osTicket, then try sending again. If the problem persists, you’ve confirmed it’s a core osTicket or MailJet configuration issue (and not something Awesome is causing). As a bonus, while in vanilla mode you can take screenshots for posting on the osTicket community forums without any third-party modification concerns.

But if you’re still stuck, let me know and I’m happy to walk through it in more detail.

[stevland]

Sorry for the very late reply, but here is the answer you are looking for:

Reapplying Mods after upgrade

[stevland]

Hi webtekpc,

This is a core osTicket question rather than an osTicket Awesome one, so I’d recommend posting on the osTicket community forums for the most thorough help.

The short answer though: yes, you can edit your email templates under Admin Panel > Emails > Templates. Select your active template set, then edit the individual templates to remove or replace the footer image/branding as you see fit.

Hope that helps!

[stevland]

You’re right that CSS content can’t pull in dynamic values like the current year. But osTicket Awesome includes a file specifically for custom JavaScript: osta/js/user-scripts.js

Keep your existing CSS to hide the default footer links, then add this snippet to user-scripts.js:

javascriptdocument.addEventListener('DOMContentLoaded', function() {
var footer = document.getElementById('footer');
if (footer) {
var copy = document.createElement('div');
copy.style.textAlign = 'center';
copy.style.fontSize = '14px';
copy.style.marginTop = '10px';
copy.style.color = '#777';
copy.textContent = 'Copyright \u00A9 2006-' + new Date().getFullYear() + ' Our Company Name. All rights reserved.';
footer.appendChild(copy);
}
});

Then remove the #footer:after rule from your Custom CSS since the JS handles that part now. Keep the rule that hides the default links.

The year will update automatically every January 1st.