[In Progress] PHP 8.2 problem with OSTicket Awesome 1.18.3

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.