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

[stevland]

Thanks for the detailed update! Good to know what the resolution was. And i’m glad you’re back in business, Mike.

[stevland]

This is an excellent idea and I am thinking about it very seriously. Stay tuned!

[stevland]

Hi Michael,

Thanks for the detailed report. This is a false positive. All six flagged files are legitimate osTicket Awesome admin configuration handlers in the osta/opt/ directory. They’re part of the Theme Settings panel and handle saving your customizations (language bar, logo management, header text, mobile link/text, and theme selection).

The WEBSHELL_PHP_Writer signature by Arnim Rupp is a heuristic YARA rule that flags any PHP file capable of writing to the filesystem. Since these files need to save your admin settings (logo uploads, text changes, theme choices), they naturally contain file-write operations, which triggers the signature. The hosting provider’s own notice acknowledges this possibility: “this list may also include files whose contents were falsely identified as malware.”

What you did right: Adding .htaccess to block direct access to the osta/opt/ directory is a solid hardening step. These files are only meant to be called internally through the osTicket admin panel, never accessed directly via URL.

What else to do:

Do not delete these files. They are required for your Theme Settings to function (Settings > Theme in the admin panel).

Report the false positive to your hosting provider. Let them know these are part of a commercial osTicket distribution and that the file-write operations are intentional admin functionality. You can point them to osticketawesome.com if they need to verify.

Your .htaccess protection is sufficient. With direct access blocked, these files can only be triggered through authenticated admin sessions, which is the intended behavior.

No passwords need to be changed and no further cleanup is necessary for these specific files. Your installation is not compromised.

I will add an .htaccess file to the /osta/opt directory in the next release so you won’t have to worry about it again in the future when you install an upgrade.

Best regards, Stevland

[stevland]

Hi Alexander,

First, a huge apology: your post was silently flagged by our spam filter and I never saw it. I only discovered it today while investigating a broader moderation issue (which, ironically, you also helped uncover). More on that shortly.

You diagnosed this one perfectly. The double-escaped apostrophes in the Italian language pack were causing PHP parse errors. Italian wasn’t the only affected language; Catalan, Estonian, French, Hebrew, Turkish, and Ukrainian had the same problem.

This was fixed in osTicket-1.18.3-Awesome-102, released January 28th, thanks to you. If you haven’t already updated, grab that version from the downloads page.

Thanks for the thorough report, and sorry again for the silence.

[stevland]

Hi Cerian, apologies for the very delayed response on this one.

It looks like you have two accounts with us (bxxxxs@pxxxxxxe.co and sxxxxxt@pxxxxxxxe.com). The card decline happened because the payment was attempted under a second account that was created when you used a different email address.

Both accounts have since expired. If you’re still using osTicket Awesome and would like to renew, please send a message to info@osticketawesome.com and I’ll make sure everything is consolidated under a single account so you don’t run into this again.

[stevland]

Hi, Mike.

Thanks for posting and for the detailed error log. That makes diagnosing this much easier.

First, an important clarification: this is a core osTicket issue, not an osTicket Awesome issue.

The entire stack trace points to include/class.forms.php and include/class.dynamic_forms.php, which are unmodified upstream osTicket files. You would see this exact same error on a vanilla osTicket installation. I’m happy to offer some pointers as a courtesy, but our forum isn’t the ideal place to get sustained support on core osTicket issues.

A quick tip for future troubleshooting: press SHIFT+O on any page in osTicket Awesome to instantly switch to vanilla osTicket. If the problem still occurs, you know it’s a core issue. If it goes away, then it’s something we’ve introduced (which is rare, but we always want to know about it). You can also look at the file paths in any stack trace; if none of them reference osTA-tagged code, it’s upstream.

For core issues like this, the best places to get help are:

osTicket Community Forum: https://forum.osticket.com — The development team and a large community monitor this forum.
GitHub Issues: https://github.com/osTicket/osTicket/issues — For confirmed bugs. In fact, this issue from 2014 shows the exact same error pattern in class.forms.php, which illustrates how long this class of bug has existed in the core codebase.
These resources have a much larger pool of people experienced with core osTicket internals than we have here.

That said, here’s what I think is going on:

The error means a form field in your database has a type value that doesn’t map to any registered field class. When the admin panel loads, it builds the ticket queue by iterating all searchable form fields. When it hits a field with an unrecognized or empty type, it crashes at that new $clazz(...) line because $clazz ends up null.

Since you mentioned rebuilding the server, I’m guessing you imported your database from the previous installation. The most common causes are:

A plugin on your old server registered a custom field type, and that plugin isn’t installed on the new server yet.
A form field ended up with an empty or NULL type value (data corruption, incomplete migration, etc.).
To diagnose, run this against your osTicket database (adjust the table prefix if yours isn’t the default ost_):

 
SELECT id, form_id, type, name, label
FROM ost_form_field
WHERE type IS NULL
OR type = ''
OR type NOT IN ('text','memo','thread','datetime','phone','bool','choices','break','section','info','list','typehead','priority');

That list of valid types may not be exhaustive, but it will surface any obvious outliers. If you find a field with an unexpected or empty type, that’s your culprit. You can either correct the type to something valid or, if the field isn’t in use, remove the row.

One more thing about your fallback plan: downgrading to 1.18.2 with PHP 8.1 probably won’t help here. This error (Class name must be a valid object or a string) is a PHP Fatal that would occur on any PHP version when $clazz is null. Your other server works fine most likely because it’s running against a clean database, not because of the version difference. In other words, the problem is in your data, not in the code or PHP version. Dropping back to 1.18.2 would just be delaying the inevitable.

Hope that helps point you in the right direction. If the SQL query doesn’t turn anything up, feel free to follow up here and I’ll try to dig a bit deeper time permitting, but as I mentioned your best bet for deep troubleshooting on core internals is the osTicket forum or GitHub.

[stevland]

I’m glad you like Dark Mode as much as I do. But I do not have any plans to implement it in the Client Portal at this time.

It seems to me that Dark Mode is perfect for agents who spend many hours staring at tickets in the Agent Panel. But I don’t imagine many clients spend as much time staring at tickets. So the work to benefit ratio doesn’t seem to support enabling it.

But if I get more requests… I may change my mind.