WHMCS is not working with PHP 5.5.x and ionCube 4.5.0

[vivaciti]

Sorry to dig up and old thread but I have got into a little pickle.

We have just upgraded our ver of WHMCS to 6.22 and then done a health check and got the message about upgrading the ver of PHP, so we upgraded that and are now running PHP 5.6.18 but when we try to edit a product we get the following error:

 

Fatal error: The file /home/XXXXXXXX/public_html/whmcs/modules/servers/dotnetpanel/dotnetpanel.php was encoded by the ionCube Encoder for PHP 4 and cannot run under PHP 5.5 or PHP 5.6. Please ask the provider of the script to provide a version encoded with the ionCube Encoder for either PHP 5.3 or PHP 5.4 or PHP 5.5. in Unknown on line 0

 

I have raised a ticket but they normally takes ages to get looked at nowadays so thought I would see if there was any solution to this I have not seen in the forums.

 

As always thank you in advance.

[vivaciti]

We have also downgraded our ver of php to 5.5 just in case and same thing

[durangod]

Usually what happens is that most hosts only run the 4.x ionCube because I believe its the default that is installed when they set up the server. The problem is because its not a "hot" topic they don't usually update it which causes issues when running scripts that are built for more recent versions of ionCube.

 

What I always did was just get the download of the ionCube files from ionCube website and install the ionCube into a folder in my domain root. Then using the php.ini file you can redirect the ionCube to read from your folder rather than the default server folder.

 

Hope that helps.

 

ps. go ahead and install all the ionCube files so that you have the legacy versions as well. This way if you have older scripts they will still run.

[vivaciti]

We got a reply telling us to change the server type from dotnetpanel to websitepanel but we don't use these we use cpanel, so im still none the wiser.

I have got something to go on though, we had an module that was written for us some years ago (we don't use it anymore) and one product had this as the module, so we have changed that to none and recompiling back to php 5.6 to see how that works.

Sorry if I am rambling but someone else may have this issue a stumble on this thread and it may help them.

[vivaciti]

No and as belt and braces even removed the modules from the disk, same issue so back to support

[vivaciti]

OK got a work around, the solution was to remove the module files from the disk (rename the dir wonr work you have to remove it!), so something was referencing the old module, but that was the fix with the idea that we keep hold of the old module files somewhere safe so we have a roll back just in case.