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

[stevland]

Hi Daniel,

Apologies for the slow response on this one.

This sounds like it could be the quick-edit popup opening but having nothing to render because the agent’s role doesn’t have permission to change the value. I’d like to narrow it down so I can look into it properly.

When you get a chance, any of the following would help (all optional, but the more the better):

1. What version of osTicket Awesome are you running?
2. What exactly is the agent clicking when the blank window appears? For example, are they clicking a priority value in the queue list, or clicking something inside the ticket view?
3. Are there any errors in the browser console (F12 > Console tab) when the blank window appears?
4. Does it happen in a different browser?
5. A screenshot of the blank window would be very helpful if you can grab one.

In the meantime, if you can confirm which element triggers it, I can take a look at whether the click target should be disabled for agents without that permission.

[stevland]

Hi Jacqueline and Jeremy,

Thank you both for reporting this. I was able to reproduce this obscure issue and identify the cause.

The theme settings page was processing form data unconditionally on every request, including empty or incomplete ones. When that happened, all checkbox-based settings (custom theme toggle, scroll-to-top, consent message, custom CSS, etc.) were being blanked out and saved over your actual configuration. This could be triggered by things like a server’s post_max_size being exceeded, a truncated request from a slow connection, or even a browser glitch, which explains why it seemed random and was so hard to pin down.

Apologies for the frustration this has caused. A fix will be included in the next release.

[stevland]

Hi JulienVDC,

Apologies for the very long delay on this one. This fell off my radar and I’m sorry about that.

Steve, excellent diagnosis, thank you. You nailed it. The :contains("0") selector is doing a substring match, so any organization with a user count containing the digit 0 (10, 20, 30, 100, etc.) gets incorrectly hidden.

Rather than removing the line entirely (which would also remove the intended styling for organizations with genuinely zero users), a slightly more precise fix is to replace this line in include/staff/orgs.inc.php:

$('table.list td:nth-child(3):contains("0")').addClass('user-count-hide');

with:

$('table.list td:nth-child(3)').filter(function(){ return $.trim($(this).text()) === '0'; }).addClass('user-count-hide');

This does an exact match on “0” instead of a substring match, so it will only hide organizations that truly have zero users.

This fix will be included in the next release (Awesome-104).

Thanks again for tracking this down, Steve.

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

[stevland]

Hi Christian,

Good news: I’ve identified the problem.

Your ost_user_account table is missing the timezone column, which was introduced in a recent osTicket core update. It appears the database migration during your upgrade from 1.18.1 to 1.18.3 didn’t complete successfully.

Run this in your MySQL console:

ALTER TABLE ost_user_account ADD COLUMN \timezone\varchar(64) DEFAULT NULL AFTER \status\;

Now, I have to be transparent with you. When you confirmed that the same error occurs in old osTicket mode (SHIFT+O), that tells us this is an upstream osTicket core issue, not an osTicket Awesome issue. Normally I would direct you to the osTicket community forum at that point, because I simply cannot troubleshoot core osTicket problems for all of my customers. If I did, I wouldn’t have any time left to actually develop osTicket Awesome!

I overlooked your answer to my fifth question above, so I kept digging when I should have pointed you upstream. Since I’ve already found the answer, it would be silly not to share it. But please understand this is a one-time courtesy, not a service that comes with osTicket Awesome. I also assume no liability if something goes wrong with the above query. Please back up your database before running it.

For future reference, any issue that also occurs in old osTicket mode (SHIFT+O) is by definition an upstream issue. The best place for those is the osTicket community forum:
https://forum.osticket.com/

Hope this gets you sorted!

[stevland]

I am in the middle of migrating my entire web server. As soon as that is complete I will fix the form again. But for now, here are all of the instructions:

Upgrading from osTicket to osTicket Awesome, using Linux, installing to a subdomain

Upgrading from osTicket to osTicket Awesome, using Linux, installing to a subdomain

Upgrading from osTicket to osTicket Awesome, using Linux, installing to a directory

Upgrading from osTicket to osTicket Awesome, using Linux, installing to a directory

Upgrading from osTicket to osTicket Awesome, using Windows IIS, installing to a subdomain

Upgrading from osTicket to osTicket Awesome, using Windows IIS, installing to a subdomain

Upgrading from osTicket to osTicket Awesome, using Windows IIS, installing to a directory

Upgrading from osTicket to osTicket Awesome, using Windows IIS, installing to a directory

Updating osTicket Awesome (already installed in a subdomain on a Linux server)

Updating osTicket Awesome (already installed in a subdomain on a Linux server)

Updating osTicket Awesome (already installed in a directory on a Linux server)

Updating osTicket Awesome (already installed in a directory on a Linux server)

Updating osTicket Awesome (already installed in a subdomain on a Windows IIS server)

Updating osTicket Awesome (already installed in a subdomain on a Windows IIS server)

Updating osTicket Awesome (already installed in a directory on a Windows IIS server)

Updating osTicket Awesome (already installed in a directory on a Windows IIS server)

First Time Installing osTicket or osTicket Awesome, using Linux, installing to a subdomain
https://osticketawesome.com/installation-instructions/first-time-installing-osticket-awesome-linux-subdomain/

First Time Installing osTicket or osTicket Awesome, using Linux, installing to a directory
https://osticketawesome.com/installation-instructions/first-time-installing-osticket-awesome-linux-directory/

First Time Installing osTicket or osTicket Awesome, using Windows IIS, installing to a subdomain https://osticketawesome.com/installation-instructions/first-time-installing-osticket-awesome-windows-iis-subdomain/

First Time Installing osTicket or osTicket Awesome, using Windows IIS, installing to a directory
https://osticketawesome.com/installation-instructions/first-time-installing-osticket-awesome-windows-iis-directory/

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

[stevland]

I wouldn’t have realized there was a problem if you hadn’t of reported it. Thank you.

The Installation Instructions conditional logic form is working again.

[stevland]

I’m sorry to learn about the frustration you experienced. Please know that all plugins have been updated in the lastest releases and I will do a better job of keeping them updated going forward.