Plugins Not Appearing (Fresh Install – PHP 8.2/8.3/8.4 Tested)

himala

Hello,

I am currently testing a fresh installation of osTicket and I am unable to get any plugins to appear in the plugin installer even after uploading them.

I searched the forum and found older threads about similar issues (for example this one), but I did not see a clear resolution, so I wanted to provide full environment details in case I am missing something.

https://forum.osticket.com/d/89470-no-plugin-showing-in-admin-panel-manageplugin-section-even-though-installed-file-storage-plugin

osTicket Installation

osTicket Version: Latest stable version downloaded from osticket.com
Installation Type: Clean installation (not an upgrade)
Database: MySQL / MariaDB
Server: Linux VPS
Server Environment
Control Panel: HestiaCP
Web Server: Apache
PHP Versions Tested:
PHP 8.4
PHP 8.3
PHP 8.2

The behavior is the same with all PHP versions.

What I Did

Installed osTicket normally using the official ZIP download.
Completed the setup and logged into the Admin Panel.
Navigated to: Admin → Manage → Plugins
Clicked Add New Plugin.
Uploaded plugin .phar files.

Result

The upload appears to complete, but no plugin ever appears in the plugin list.

Manual Installation Attempt

I also attempted manual installation by placing the plugin files directly in:

/include/plugins/

Example:

/include/plugins/storage-fs.phar
/include/plugins/authenticator.phar

After doing this I:

Restarted Apache
Cleared browser cache
Logged out and back into the Admin panel

However, the plugins still do not appear under Manage → Plugins.

Plugins Tested

Downloaded directly from the official osTicket plugin page:

Storage :: Attachments on the Filesystem
Google Authenticator (2FA) plugin

I noticed the main osTicket download does not include these plugins, so I downloaded them separately and attempted to install them.

File Permissions

include/plugins directory: 755
plugin files: 644

Apache should have read access to the files.

PHP Extensions

PHAR support appears to be enabled:

php -m | grep phar

returns:

Phar

Logs Checked

I checked the following logs:

Apache error log
PHP error log
osTicket logs

So far I do not see any errors related to plugin loading.

What I Am Trying to Achieve

This is currently a test environment, and my main goals are:

Enable Two-Factor Authentication (2FA) for agents
Store ticket attachments in the filesystem instead of the database

Question

Is there a specific requirement or configuration step needed for .phar plugins to be detected in newer osTicket versions?

Or is there something in the server environment (PHP configuration, permissions, or restrictions) that could prevent plugins from appearing?

Any guidance would be greatly appreciated.

Thank you.

himala

Update / Workaround

I wanted to post an update in case someone else encounters the same issue.

The .phar plugin files were not appearing in the Admin → Manage → Plugins section when uploaded or copied into the plugins directory.

With some help analyzing the .phar files, I realized they are simply PHAR archives, similar to compressed packages. After extracting the contents of the .phar file and placing the extracted folder inside the plugins directory, the plugins started working correctly.

Directory used:

/include/plugins/

Example:

/include/plugins/storage-fs/
/include/plugins/authenticator/

Steps that worked for me:

Download the plugin .phar file.
Extract the.phar archive.
Copy the extracted folder into /include/plugins/.
Refresh Admin → Manage → Plugins.

The plugin then becomes visible and can be enabled.

However, the .phar files themselves still do not load directly, so it appears the system is not recognizing .phar plugins properly in my environment.

For now the extracted plugin method works, but I am still interested in understanding why the .phar plugins are not being detected automatically.

Hopefully this helps anyone encountering the same problem.

Thank you.

KevinTheJedi

himala

Your host is most likely restricting PHAR execution. Old school or ticket gripped hosts do this for security purposes. When in doubt, reach out to your host to clarify.

Cheers.

himala

Thank you for the reply.

This is a self-managed VPS, not shared hosting. I manage the server myself and it is running HestiaCP, which is an open-source hosting control panel. So there is no outside hosting provider applying hidden shared-host restrictions.

I did some additional testing on both CLI PHP and the active web PHP-FPM runtime.

What I found:

Phar extension is enabled
PHAR stream wrapper is registered
The site is running under PHP-FPM/FastCGI
phar.readonly=On
phar.require_hash=On
open_basedir is enabled in the web runtime

I also verified that the plugin files themselves are valid by extracting the .phar archives manually. Once extracted into /include/plugins/, the plugins appear in osTicket and install normally.

So at this point the behavior seems to be:

extracted plugin folders work normally
direct .phar plugin loading does not

That suggests the issue is not that PHAR support is missing entirely, but something specific to how the .phar plugins are being detected or loaded in this environment.

For now, extracting the .phar contents into /include/plugins/ is a working workaround.

If needed, I can also share the relevant phpinfo() details from the active web PHP-FPM environment.

KevinTheJedi

himala

Not really needed. No one else experiencing this except you. If you find the cause please post back so others can learn as well. We’ve ran out plugins like this for over a decade so it’s pretty battle tested.

Cheers.

himala

Hi everyone,

I ran into an issue where the Audit plugin (.phar) would not load in osTicket and was throwing errors related to PHAR paths and file access.

After troubleshooting, I found the issue was not with osTicket or the plugin itself. The problem was HestiaCP’s PHP-FPM configuration.

Root Cause

HestiaCP enables open_basedir by default in its PHP templates. This restriction prevents PHP from accessing files inside PHAR archives, so osTicket cannot load plugins packaged as .phar.

Solution

Create a custom PHP-FPM template without the open_basedir restriction and assign it to your domain.

Steps

Copy the default PHP-FPM template

cp /usr/local/hestia/data/templates/web/php-fpm/PHP-8_4.tpl \
   /usr/local/hestia/data/templates/web/php-fpm/PHP-8_4-NOBASE.tpl

(Adjust PHP version if needed.)

Edit the new template

nano /usr/local/hestia/data/templates/web/php-fpm/PHP-8_4-NOBASE.tpl

Find this line:

php_admin_value[open_basedir] = ...

Comment it out or remove it:

;php_admin_value[open_basedir] = ...
Assign the custom template to your domain

In HestiaCP:

Go to Web

Edit your domain

Change Backend Template to:

PHP-8_4-NOBASE

Rebuild and restart services

v-rebuild-web-domain USER DOMAIN yes
systemctl restart php8.4-fpm
systemctl reload nginx
systemctl reload apache2

Verify plugin setup

Make sure you are using only the PHAR file:

include/plugins/audit.phar

Do not keep both the extracted folder and the PHAR file at the same time.

Result

After removing the open_basedir restriction and applying the new template, the Audit plugin loaded correctly and worked without errors.

Note

If you are running osTicket on HestiaCP and a PHAR plugin fails to load, check open_basedir first. That was the root cause in this case.