ionCube Logo
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Goto page Previous  1, 2, 3, 4, 5, 6  Next
 
Post new topic   Reply to topic    ionCube Forum Index -> ionCube PHP Encoder

PHP 7.0 Support Timeline

Author Message
jkirker



Joined: 31 Aug 2015
Posts: 6
Location: California

PostPosted: Tue Mar 08, 2016 2:00 am    Post subject: Reply with quote

While we all want to move to 7 due to performance enhancements and potential speed gains, liaison is right. This isn't something to be hasty with. There are lots of potential issues to be dealt with. Being a typical early adopter and tester of technology it can be frustrating to implement things before they are ready - even more so than the frustration felt when waiting. I'm very glad that IC isn't rushing this and is doing as thorough a job possible.
_________________
John
Back to top
View user's profile Send private message
jkirker



Joined: 31 Aug 2015
Posts: 6
Location: California

PostPosted: Tue Mar 08, 2016 2:00 am    Post subject: reid balsam Reply with quote

While we all want to move to 7 due to performance enhancements and potential speed gains, liaison is right. This isn't something to be hasty with. There are lots of potential issues to be dealt with. Being a typical early adopter and tester of technology it can be frustrating to implement things before they are ready - even more so than the frustration felt when waiting. I'm very glad that IC isn't rushing this and is doing as thorough a job possible.
_________________
John
Back to top
View user's profile Send private message
ryanf



Joined: 09 Mar 2016
Posts: 4

PostPosted: Thu Mar 17, 2016 9:29 am    Post subject: TEST Reply with quote

TEST
Back to top
View user's profile Send private message
ryanf



Joined: 09 Mar 2016
Posts: 4

PostPosted: Thu Mar 17, 2016 9:32 am    Post subject: Php 7 Support Reply with quote

Hello,

As a developer it doesn't sit well to read that someone is strongly suggesting to someone else that they shouldn't upgrade to Php 7 for 6 months. Why? Let's look at this: [url]techblog.badoo.com/blog/2016/03/14/how-badoo-saved-one-million-dollars-switching-to-php7/[/url] .

If ionCube's position is that they won't provide an encoder/decoder until Php 7 has reached 6 months, then maybe ionCube should have a vote in the Php Core...so that the Core doesn't release a new version until ionCube is ready? Otherwise, as an open source community, we can do what we individually please.
Back to top
View user's profile Send private message
ryanf



Joined: 09 Mar 2016
Posts: 4

PostPosted: Thu Mar 17, 2016 9:33 am    Post subject: Php 7 Support, continued... Reply with quote

What new features does Php 7 offer? Take a look: php.net/manual/en/migration70.new-features.php . This improves the OOP implementation for Php, and allows for better adherence to the SOLID principles ( en.wikipedia.org/wiki/SOLID_(object-oriented_design) )...namely Liskov's Substitution Principle and Open/Close...by enforcing a return declaration in an Interface, which can be depended upon.

Such arguments as "If it's not broke, don't fix it" only work for someone who isn't a developer/engineer...for the rest of us who depend on 3rd party code that uses ionCube, and who are working at an enterprise level, ionCube needs to be available A.S.A.P....I don't even care if there was a "beta" version which wasn't backwards compatible. Why? Because I could start realizing the same kinds of benefits Etsy and Badoo have, now.
Back to top
View user's profile Send private message
liaison
ionCube Support


Joined: 16 Dec 2004
Posts: 2788

PostPosted: Thu Mar 17, 2016 4:05 pm    Post subject: Reply with quote

Quote:
"I don't even care if there was a "beta" version which wasn't backwards compatible. Why? Because I could start realizing the same kinds of benefits Etsy and Badoo have, now."


Not being backwards compatible means that there's more than a fair probability that some 3rd party files you have are not yet going to work correctly on PHP 7. If you're ok to take that chance and happy to accept segfaults and possibly other failure scenarios then you could have the Loader as it stands now, but my guess is that you wouldn't be and our QA standards would not permit release at the moment. The Badoo article is indeed worth a quick read as it gives an insight into why there isn't a Loader just yet.
_________________
Community Admin
Back to top
View user's profile Send private message
ryanf



Joined: 09 Mar 2016
Posts: 4

PostPosted: Wed Mar 23, 2016 8:16 am    Post subject: Php 7 Support Reply with quote

Yes, the Badoo article is worth a quick read. So is anything on Etsy upgrading to Php 7...or Rasmus showing benchmarks for Php 7. Or anyone comparing Php 7 to HHVM, specifically regarding performance (and even the fact that the new Php 7 engine puts the project in line with adopting a JIT easier in the future).

I understand the importance behind stability and quality for a product, but I also think there's a middle path. Why not have an incremental release policy? One where early adopters can make their own choice to use a version of ionCube for Php 7 as is? Yes, this would require the end user to understand the risks...and yes, this could probably raise more inquiries from people who don't understand what is going on...but this would also allows those of us who want to develop code in Php 7 today, using ionCube, to do so.

My whole argument is that ionCube is essentially a pair of handcuffs at this point. A form of "Big Brother" who is dictating when Php 7 can be used. This just doesn't sit well with me. It also causes me to view ionCube as a liability, or better yet, any 3rd party code that uses ionCube is now a liability for projects that I'm apart of. Fortunately for myself, I can just round up the engineers and pitch a proposal to leadership to ok us developing in-house whatever we're currently depending on 3rd party code for. This removes the liability of ionCube, and the 3rd party vendor, and we can have more control over our SDLC and strategic planning. This isn't a reality for everyone though, and for the others I feel for them. It sucks, simple as that.

I'd appreciate it if you were to release some version of ionCube for Php 7 with a disclaimer. It would save myself and my team the time/energy of phasing out our vendor which relies on your extension. If not, then we'll just phase out that code and ionCube.

I personally don't like how the ionCube extension interferes with Xdebug anyway. I like to be able to have inline debugging, which isn't possible with ionCube. I hear that it is possible with Zend Guard though.
Back to top
View user's profile Send private message
mwoods



Joined: 25 Mar 2016
Posts: 1

PostPosted: Fri Mar 25, 2016 7:26 pm    Post subject: Reply with quote

Just wanted to offer a slightly different opinion on this than has been mentioned so far.

I've been testing with PHP 7 but my software is a private, invitation-only service so it doesn't have to deal with thousands of concurrent users and therefore the performance gains are modest.

However, the lack of PHP 7 support in Ioncube is still a big problem for me because when my customers install PHP, depending on the platform and method of installation, they often end up with PHP 7. They already have enough issues getting permissions correct so this makes them even more confused and annoyed and I need to talk them through downgrading to PHP 5.x, which, depending on the platform, can sometimes be quite technically complicated.

Even though many of liaison's points are correct, my customers have still bought into the marketing hype behind PHP 7 and want to use it now. The worst part is that I can't even tell them when they'll actually be able to use it.

So I understand that this is complicated and obviously no-one wants to install a loader that's going to crash, however it would be extremely helpful to have a more specific public schedule or roadmap so we can properly communicate to our customers when this is likely to be resolved.
Back to top
View user's profile Send private message
liaison
ionCube Support


Joined: 16 Dec 2004
Posts: 2788

PostPosted: Sat Mar 26, 2016 11:27 am    Post subject: Reply with quote

mwoods wrote:
obviously no-one wants to install a loader that's going to crash, however it would be extremely helpful to have a more specific public schedule or roadmap so we can properly communicate to our customers when this is likely to be resolved.


I agree, however the nature of the beast is such that it's impossible to estimate with accuracy, and even timescales on previous versions are only very loosely applicable. In a typical project, features and milestones are planned and prioritised, and if adopting an agile approach there would be deliverables with relatively short intervals between each one and a roadmap for iterative refinements; with experience and a predicable available effort, reasonable time estimation can be achieved. Unfortunately though, new PHP support is not "typical".

In supporting a major new PHP release we have a basic roadmap which is first to support files produced for the immediately prior PHP release, so running PHP 5.6 files on PHP 7 in this case. That would be the first Loader release, and we then look to support files produced for earlier versions of PHP, and last produce a Loader to work with files produced from the next generation of Encoder that natively encodes for that version. Unlike most projects that are driven by known quantities, supporting a new PHP version is stepping into the unknown and has a significant amount of research and development that makes it hard to estimate. Our starting point on a new PHP release is typically that nothing in our huge test suite works, not even a simple "echo 'hello world'", and it's voyage of discovery from there to find out why and how to make old code designed for a different PHP work on a the new one, Virgin Galactic said that they would have a maiden flight in 2009, but even with all the accumulated knowledge available in the area of rockets and space travel, the project has been delayed many times and had some catastroohic disasters along the way. Any research based project is hard to call, and like Branson's, there is little scope to compromise with the Loader. While we may put out a beta, unlike a typical project where a first release might have only 5 or 10% of planned functionality and yet stilll be very usable, the Loader needs to be almost 100% working to be usable at all and ideally not likely to cause a catastrophic failure for anyone using it. Finally, a further variable remains PHP itself as this can also be changing in the early stages of a new release, with inevitable bugs discovered and fixed, potentially impacting our work. We have weekly meetings to review progress and prioritise resolving remaining test failures, and everything is going pretty much as expected with the number of outstanding issues consistently and significantly falling. Based on the last meeting I'd say a release within a couple of months is very likely, but this could still change.

Last, we are also very mindful that for anyone wanting protecton against vulnerability exploits and malware on their website, ionCube24 is the only real option, and right now anyone using PHP7 is unable to be protected. As the ionCube24 functionality for PHP is integrated into the Loader, the sooner there is a Loader the better. We may release an early PHP 7 Loader for users who want the benfit of vulnerability protection and error monitoring for PHP 7 that ionCube24 provides but who do not need to run ionCube files, but we currently plan to release this at the same time as support for encoded files.
_________________
Community Admin
Back to top
View user's profile Send private message
mrlerch



Joined: 02 Apr 2016
Posts: 2

PostPosted: Sat Apr 02, 2016 8:12 pm    Post subject: It seems to me that IonCube is fighting PHP7 Reply with quote

Reading the posts and the snazzy replies from IonCube support that they are not interested in releasing an IonCube loader for PHP7. PHP7 seems to be quite a bit faster (at least when running Magento), and I for one would like to fun PHP 7 and Magento. There are extensions that require the Ion Cube loader and without having it for PHP 7 is in a way holding me back. Perhaps we all need to complain to the folks that are using Ion Cube technology to encode their products, apps and plugins and urging them to try to find a different method of encoding their work, instead of using Ion Cube? Or maybe Ion Cube could get off their high horse and step up and provide customers of their customers with a loader so they can run the damn software? But that idea seems too novel, doesn't it?

Thanks.
_________________
Mr. L
Back to top
View user's profile Send private message
liaison
ionCube Support


Joined: 16 Dec 2004
Posts: 2788

PostPosted: Sat Apr 02, 2016 10:56 pm    Post subject: Re: It seems to me that IonCube is fighting PHP7 Reply with quote

mrlerch wrote:
they are not interested in releasing an IonCube loader for PHP.


So far over $50,000 USD has been invested in the research and development of the Loader to support PHP 7 and that cost increases every second. Bearing in mind that the Loader is FREE and gives a zero ROI, we are probably the *most* interested in getting the Loader released Smile

Quote:
urging them to try to find a different method of encoding their work, instead of using Ion Cube?


No other provider makes any investment to support existing files on new versions of PHP, so that would not help.

We are certainly listening to end users of scripts, and because producing back compatibility support takes longer to develop than supporting files produced natively for a new PHP release, we may change approach for the next version. Instead of us developing support to run existing encoded files without change as we have always done up to this point, to speed up release of language support we may produce the compatible Encoder first. This would have the advantage of enabling our customers to take advantage sooner of whatever new features are in that next PHP language, and end users of scripts will be able to run them on a newer PHP sooner too provided that they obtain updated copies of the PHP scripts from the developers that they need to use. We would still look to produce a Loader to support users with scripts that they cannot update, but this would be secondary to supporting those users who can obtain and switch to updated scripts.
Back to top
View user's profile Send private message
mrlerch



Joined: 02 Apr 2016
Posts: 2

PostPosted: Mon Apr 04, 2016 2:47 am    Post subject: A simple "Sorry" may go a long way Reply with quote

A simple "We are sorry that it is taking longer than expected" may go a long way here. I can understand that it is a lot of work to support scripts that were encoded on an older platform, working with an older version of PHP, etc. But really what would need to happen is the following:

You should be in touch with all your customers that encode files

They should re-encode their files with your latest encoder

Your customers should provide their customers with updated encrypted files so the end user can continue using your customers' software.

Perhaps you are right with the new approach going forward.

Thank you.
_________________
Mr. L
Back to top
View user's profile Send private message
liaison
ionCube Support


Joined: 16 Dec 2004
Posts: 2788

PostPosted: Mon Apr 04, 2016 10:07 am    Post subject: Reply with quote

mrlerch wrote:
Your customers should provide their customers with updated encrypted files so the end user can continue using your customers' software.

Perhaps you are right with the new approach going forward.


Provided that all parties can upgrade and purchase new software where necessary, e.g. for a new Encoder and with end users upgrading PHP scripts, then this should work as you suggest. It certainly seems to be what end users of scripts would prefer so we're happy to be responsive to that going forwards. In case it isn't clear, we've always taken a back compatibility first approach up to this point and have done so for PHP 7 because the reality is that some users may be unable to obtain updated scripts, and even if they can, doing so may involve taking on an upgraded version that carries implications. However, as moving to a new PHP version is itself an upgrade, and scripts will need updating anyway if (as many do) they use deprecated features that are gone in that new PHP version, upgrading the entire production pipeline actually seems very reasonable.
_________________
Community Admin
Back to top
View user's profile Send private message
Josh Abbott



Joined: 08 Feb 2016
Posts: 8

PostPosted: Fri Apr 08, 2016 5:44 pm    Post subject: Reply with quote

For those who are rushing into PHP 7, I think it's important to note that PHP is a programming language and considered part of the foundation layer in many web infrastructures. While it's not uncommon for individual apps to be updated a few times a month, major updates to programming languages should be considered more slowly and carefully. Apps themselves usually run on a web platform (such as Wordpress), and then it's those platforms that actually run on PHP.

As the developer of a web platform, I usually target my software for a new PHP version every 2 to 3 years, and even that is a faster pace than many other platforms. In 2014, I began compiling my platform for a minimum version of PHP 5.3 while also supporting 5.4 and 5.5. The next change was March 2016 when I began compiling it for PHP 5.5 while also supporting 5.6.

While I'm already making preparations for PHP 7 and plan to support it once the ionCube Loaders are available, I don't think it will be wise or necessary to target PHP 7 as the minimum required version for at least another 2 years.

I believe that ionCube's pace for supporting new PHP versions is reasonable, and that it's important that they continue to provide backwards compatibility for scripts encoded for at least 2 PHP versions back. This gives me the flexibility to support older PHP versions that are still receiving security updates from PHP, while also being able to support newer PHP versions without needing to re-encode my scripts every time a new PHP version is released (which would force all my end users to upgrade their PHP version and possibly break other scripts and apps on their site).
Back to top
View user's profile Send private message
Phillip Frandsen



Joined: 23 Apr 2016
Posts: 2

PostPosted: Mon May 02, 2016 11:16 am    Post subject: PHP 7 Reply with quote

Hi

When can we expect ioncube to support php 7? Any news about a release date? Confused
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    ionCube Forum Index -> ionCube PHP Encoder All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 3 of 6

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum