[Faber]

Hello, find first problem :

The file main.php was encoded by the ionCube Encoder for PHP 5.5 and cannot run under PHP 7.0.

[liaison]

Only protected files produced for PHP 5.6 are currently supported on PHP 7. The script provider should be able to provide a PHP 5.6 version of the files to use on 7.
_________________
Community Admin

[Josh Abbott]

Isn't the core of PHP 5.6 nearly identical to PHP 5.5? I believe most of the changes were to PHP extensions, such as Open SSL, with only a few minor language changes. If that's the case, wouldn't it be a simple update to get the ionCube Loaders for PHP 7 to run PHP 5.5 files?

For professional script developers, targeting a new PHP version is far more complicated than simply running the encoder again. To avoid software fragmentation, developers also need to provide the update for all existing customers, which means any customers running PHP 5.5 will be required to update to PHP 5.6 to install the update. This is a support-intensive process involving hundreds of customers who use various hosting providers.

Until very recently, PHP 5.5 was the default version included with new cPanel installations, making it the logical version for developers to target. It would be great to be able to support PHP 5.5, 5.6, and PHP 7 without forcing our end users to update from PHP 5.5 to 5.6, since those versions are nearly identical.

[liaison]

Hi Josh

You're right that it's not entirely trivial to release a new version of a PHP based product, just as it's far from trivial for us to make any new release. Encoding for 5.6 vs 5.5 though fundamentally really is as easy as running the Encoder with a different setting, and providing updates as well as deploying an update for a customer should be straightforward as they would have the exact same set of PHP files and no changes to any database etc. The most likely complexity would be ensuring that a customer can get a copy of the exact same product version that they currently have, and not be forced to accept a feature based upgrade. Provided that software product releases have been properly controlled and it's possible to get the exact set of files that were used for each past release (which it should be!), producing PHP 7 compatible versions of those exact same releases should be straightforward. However the update is obtained by the end user, as there will be no datebase changes etc., just replacements to encoded files, rolling out the update should be straightforward. Assuming that the product has a builtin upgrade and rollback feature, which a more advanced product is likely to have, the effort for the end user should be minimal.

Producing a Loader with compatibility for a different version of PHP, even with no PHP internal changes at all, is far from trivial and involves lots of new code in the Loader. The work required to support 5.5 on 7 having supported 5.6 is not months of effort though, and will be something we look at when feasible.
_________________
Community Admin

[trice001]

thanks