DirectAdmin fails to detect installed ionCube Loader for PHP 7.4 after update

K

kamgor

Verified User
Joined
Dec 24, 2024
Messages
7
Hello everyone,

I'm facing a persistent issue with DirectAdmin and ionCube Loader on my server. I am trying to get DirectAdmin to recognize that ionCube is installed for PHP 7.4, but I keep getting the error message:

"Could not detect version for PHP 7.4 and IonCube 14"

The strange thing is that ionCube Loader is definitely installed and working correctly. When I check my phpinfo() page, it clearly shows:

Code: 
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with the ionCube PHP Loader + ionCube24 v14.4.1, Copyright (c) 2002-2025, by ionCube Ltd.

This confirms that the loader is active for the web server.

This problem started immediately after a recent DirectAdmin/CustomBuild update. I have tried reverting to a previous version of the ionCube loader, but that did not solve the problem, which suggests the issue lies within the updated DA scripts.

Here is a list of all the troubleshooting steps I have already taken without success:

  1. CustomBuild Installation: I have successfully run ./build php_ioncube. The installation process completes without any errors.
  2. options.conf: The php_ioncube option is correctly set to yes in /usr/local/directadmin/custombuild/options.conf.
  3. CLI PHP Verification: I have checked the PHP CLI version using /usr/local/php74/bin/php -v. The output confirms that the ionCube Loader is also loaded correctly for the command-line interface.
  4. php.ini Configuration: I have verified both the web server's php.ini (FPM) and the CLI's php.ini. In both files, the zend_extension line for ionCube is present and is the very first zend_extension listed to ensure correct loading order. The path /usr/local/ioncube/ioncube_loader_lin_7.4.so is correct.
  5. Rebuilding Configurations: I have run ./build php_conf and even the more forceful ./build rewrite_confs multiple times.
  6. File Permissions: I've checked the permissions for the loader file (/usr/local/ioncube/ioncube_loader_lin_7.4.so) and the php.ini files. They have standard permissions (755 for the loader, 644 for the .ini files) and correct ownership (root:root).
  7. SELinux Check: I have checked sestatus, and SELinux is disabled, so it is not interfering.
  8. Clean Reinstallation: I performed a full reinstallation cycle: ./build set_php_ioncube no, ./build php_conf, then ./build set_php_ioncube yes, followed by ./build php_ioncube. The problem still persists.
Has anyone encountered a similar issue or have any advanced suggestions on what else I could check? Is there a specific cache I need to clear or a manual way to force the detection?

Any help would be greatly appreciated. Thank you!
 
1752499433354.png


1752499479841.png


1752499489578.png


1752499512879.png


1752499576599.png


1752499608140.png
 
zEitEr said:
Hello,

What software reports the error? Is it reported by a directadmin plugin? Or a site hosted under a user account?
Click to expand...
This is information from the client's application (Wordpress site). Until Friday, everything worked without any issue. On Saturday I did an update through the DA UI and after that this error appears all the time. I can't find anything in the logs to check what is wrong.
 
Last edited:
Add phpinfo(); in the top of index.php and see if IonCube is loaded

If ionCube is loaded, and the client's application reports the issue, then you need to downgrade ionCube. DirectAdmin does not allow to downgrade ioncUbe only for one PHP version. It will install the same ionCube version for all PHP versions. If this is the issue, then you will need to disable ionCube in custombuild options and manage ionCube on your own, installing older ionCube version for PHP 7.4 and new one for PHP 8.x

Related:

- https://docs.directadmin.com/webservices/php/php-extensions.html
- https://docs.directadmin.com/webser....html#manually-compiling-an-extension-for-php
 
Check the wordpress plugin and contact your plugins dev and let's them re-encode the plugin with latest version of ioncube to work with php7.4, .... or downgrade ioncube to version that still working before updated.
 
Just wanted to post an update and close this topic. I have found the source of the problem (thanks @Ohm J).
It turned out to be a faulty plugin. After updating the specific plugin to its latest version, the ionCube detection issue was resolved and DA now correctly recognizes it.

So, if anyone else experiences a similar issue where everything seems correct but DA fails to detect a component, I suggest checking your plugins. A faulty or outdated plugin can apparently cause this kind of problem.

Thank you all for the help and suggestions!
 
Oh, old WordStress plugins, seems legit..... I thought to myself, WordStress is open source, why is it obfuscated?!
Is that specific plug-in paid for?
 
You're right @zEitEr. It is not the DA that detects it directly only the application that uses it. And it was a custom WP add-on that connected to the client's ERP for synchronization.
 
You must log in or register to reply here.
Back
Top