We'll make a maintenance release to bump distributors like softaculous

We made a second release of v1.9.9 to address the issue of the spurious `<div>` tags showing up. Can you try downloading again from the website?

What HTTP server software are you using?

The error is explaining that PHP cannot WRITE to a file in the `(root)/files/5` folder. (Sorry for the confusing error message.) The `5` folder is created automatically to prevent the `files` folder from growing very large, since most filesystems don't tolerate extremely large directories well.It would seem that the automatic permissions created on the new folder don't allow writes by the Apache / PHP process. I would suggest using posix ACLs or the setgid bit on the `(root)/files` folder to assist in allowing PHP write access to the new folders automatically.

@[deleted],My guess is that you have a one minute scheduled cron and several users using the system. It looks like the search indexer runs on both the autocron and on the scheduled cron. I would recommend we disable the indexer from the autocron — at least on your system. Perhaps you could add / change this code in the `class.search.php` to disable the indexer for the autocron:    /** 

     * Cooperates with the cron system to automatically find content that is

     * not index in the _search table and add it to the index.

     */

    function IndexOldStuff($signal) {

        if ($signal)

            return;

        $class = get_class();

        $auto_create = function($db_error) use ($class) {

I think I finally identified the issue. Thanks for the hint on copy+pasting from other FAQ articles. I see it was previously mentioned; however, I seemed to have read right over it earlier.I opened #1960 on GitHub, can anyone try the patch to see if it fixes the issue?Cheers,Jared

I think this crash was caused because you do not have the PHAR extension enabled for PHP. I've addressed the issue here. You can apply the patch manually or download the ZIP file from GitHub and unpack it if you would like to have it fixed before the next release.Thanks for reporting the issue.Cheers,Jared

Jacek,I'm confused. You cannot do fetching unless you have the `imap` extension. Instead, you'll have to do mail piping, which does not use the mail fetch code to do character set transcoding. Instead, it uses code in the class.charset.php file.Could you post a raw email with headers for and email resulting in an empty subject so I could test it on a system without the imap extension installed?Cheers,Jared

Hey, I just wanted to pop in here and add a couple details. Thanks again for all the translation assistance.The software can be translated in place, without downloading and monkey-patching the translation files. Just visit http://jipt.i18n.osticket.com/. Log into the Crowdin dialog with your Crowdin credentials and into osTicket with username and password "demo" and "demouser" respectively, (without the quotes). This would be the recommended approach since it allows for collaboration, and uses your time effectively.Please send @[deleted] messages via Crowdin for other translation related issues, including requests to publish language packs or add new target languages.To convert the messages.po to message.po.php, run the include/class.translation.php directly (this is documented at https://github.com/osTicket/osTicket-1.8/blob/develop/setup/doc/i18n.md (setup/doc/i18n.md in the software codebase):php include/class.translation.php message.mo > message.mo.phpSorry, as of yet, we still don't have a utility to unpack the PHAR files.Cheers,Jared

> osTicket uses an unsafe way to get PATH_INFO, obviously it will not work with FastCGI.I'm not sure how 'unsafe' is meant here. Perhaps 'unreliable' is vetted. We have production servers using mod_rewrite, Apache2, php-fpm with mod_fastcgi, and the current codebase works just fine. I like your fallback code and I'll test it out.Cheers,

The 1062 errors are harmless. Hopefully we'll get it taken care of in an upcoming release

Pardon me if I'm a noob here, but in SSL context, isn't `verify_peer_name` usually used to verify the apparent hostname of a server with the hostname in the server certificate. Are you using a self signed certificate or something?

There is a permission grantable via the group to manage canned responses, and there is a config option to enable the canned responses feature. Are those settings setup properly? v1.9.5 introduced a "fix" that actually implemented the checkbox to enable/disable the canned responses feature.

At the moment, no. This is the main reason we have yet to publish information on the plugin system. For the time being, you could just add the signal in the Ticket: method:$info = array('agent' => $staff);Signal:('ticket.assign', $this, $info);Hopefully in the not-too-distant future, we'll have a far more complete list of signals to allow for better interaction with the software.Cheers,

It looks like ROOT_PATH is not being setup correctly. Could you share some information about your server configuration: what path is /support/ served from on the filesystem? Do you have a virtual directory or website configured?You can configure the ROOT_PATH in the config file by uncommenting the lines that define it and set the ROOT_PATH to /support/

Any chance I can get a screen shot of the ticket view page? What language's characters are missing in the PDF printout?

So I was able to confirm the issue with the end-user reply. I've created a pull-request with the fix on GitHub. Sorry again for any inconvenience and confusion.https://github.com/osTicket/osTicket-1.8/pull/1269

I can confirm that this is fixed in v1.9.4-rc2. Here's the code that generates the SQL statement:https://github.com/osTicket/osTicket-1.8/blob/v1.9.4-rc2/include/staff/templates/tickets.tmpl.phpThe problem part of the code wasLEFT JOIN ON ost_ticket_priority pri (pri.priority_id = cdata.priority_id) and it was fixed prior to the release of rc2 in this commit.Sorry for any confusion. Downloading the latest from osTicket.com and upgrading should address the issue.Cheers,Jared

Please open up an issue on the github site at github.com/osTicket/osTicket-1.8 so this doesn't get lost

You're overthinking it. We started with the 1.7 version in the repo name, then forked to 1.8. What's the advantage of forking to a 1.9 repo? The next repo will not have a version number in the name. In my opinion the version number in the repo is misleading and unnecessary.Cheers,