I can’t speak for Tom, but it sounds like he just wants a FreePBX upgrader. As do I! Nothing to do with operating systems.
Usually we create these after the distro is released. I will be doing the same.
1 Like
Ok thanks for the reassurance! There’s been an awful lot of focus on the bundled OS product the last couple of years, just don’t want you guys to forget about the guys who get paid to build and manage their own systems. 
One thing of note FreePBX 14 requires PHP 5.6. Any non-distro implimentations will need to update their php version to match.
Yup have been on Remi’s PHP 5.6 for years now. Looking at upgrading to 7 soon!
I have just finished the version upgrade script (for non-distro). PM me if you’d like it
You can not go to PHP 7 with FreePBX. Have to stick with 5.6 for now.
Just curious, why not design FreePBX for PHP 7?
Because there is no Zend support for php 7
Are you talking Zend Framework? It’s supported PHP7 for over a year.
@qoole No, we aren’t referring to Zend Framework here but rather a product they are no longer supporting, which is Zend Guard.
Will there be an upgrade path from the RC to final release? We are in the process of setting up servers for a new facility, and would like to use the newest version if possible.
The holdup at the moment is the 13->14 migration. The current stable download it SNG7 with FreePBX 14. You can download that now and use it. If you are on a RC of SNG7 with FreePBX14 you may simply run yum update and update your modules.
@GameGamer43 - it’s a shame when commercialisation comes between users and performance. I totally understand it and the need for it, but it should be taken as a demonstration not to rely on 3rd parties for such a fundamental part of your business model, because ultimately it’s the users that suffer.
1 Like
@qoole While I understand the comment, keep in mind that if users want to use a new version of PHP such as PHP 7, there is nothing stopping them from using FreePBX with PHP 7 and reporting issues to us at issues.freepbx.org.
Hi. If we use PHP7 will we lose all commercial module functionality because it relies on Zen Guard?
Yes, Commercial modules will not work with PHP7. At this point this will also break the repos as they do not understand PHP7 at this time.
For a point of reference:-
Just reading some old threads.
No idea (and haven’t looked) when the time frame for 15, but PHP5.6 eol is Dec 2018. That may sound far off, but when you need to go through all that code, it can be a massive undertaking.
With ZendGuard being dead and PHP5.6 being dead at the end of next year, it’s a lot that needs to be reviewed, tested, and validated.
To add to this problem, PHP 7 ends at the same time, and IonCube is not support on PHP 7.1
There really is no place to go right now.
You also have some customers who want to run all the lastest versions, some customers asking not to break anything. Compliance people asking why is this stuff so old (we all love explaining CentOS and it’s back porting)
To make it worse, some organizations where End of Life means End of Use. I remember whe 5.4 hit eol, we had to dump an application because the vendor was not able to covert fast enough.
While I’m not sure where I’m heading on this, I do hope that next year there will be a clear path. Otherwise some of us have to start looking for alternatives, but that’s still 11 months away.
I enjoy FreePBX, I’m glad I made the switch, I really don’t want to have to go through a migration again. I took a lot of heat (still do) for moving to FreePBX, but as I stay to bashing vendors, “people call, the phone ring. how can they make it better?” None have an answer ( other than a BS sales pitch) but if it can keep up, I lose.
1 Like
Yes we will be working on moving to ioncube in the future but Redhat 7 is not even shipping with php 5.6 so us going to 5.6 was a big jump that we have to maintain already so we are good with doing such things and PHP 7 will be supported when when we are ready for it and as proven we have no issues using updated packages that upstream RHEL is not using yet.