As I understand the announcement of the beta release of FreePBX 15 it still does not support PHP 7.x. Some users sayed that FreePBX 14 runs with PHP 7.0 if no commercial modules are used. This is not true, I cannot run FreePBX 14 on a Debian 9 with PHP 7.0.
FreePBX 16 will have support for PHP 7.3 (readed in the announcement of the beta release of FreePBX 15). But FreePBX 15 still is not released. Therefore I assumed that FreePBX 16 is released somewhat in the Year 2021 or 2022. And will it work with PHP 7.0 or need it PHP 7.3?
In the meantime I need to have a separate server for FreePBX because modern webs (CMS) do not work anymore with PHP 5.
You should NOT run any other services on the same system as your PBX.
If you are running on Debian you’re not using commercial modules anyway.
15.0 works fine with PHP 7 the general hangup seems to be QA on the 15 backup module. From what I have seen they have been breezing through these issues with the help of the community.
There is absolutely no rationale for “You should NOT run any other services on the same system as your PBX.”
If your using Debian or anything not directly supported, It is not that “you’re not using” it’s that "you can’t use it (because we rely on a no longer supported obfuscation) and don’t care "
be careful with your use of PHP 7 , many distros now are at 7.3 (current) FreePBX hobbles along with 7.0 in some areas, same areas will fail at +7.1
Except the part where FreePBX wants everything that is needs control over to be owned by the user asterisk, it was designed with a specific file path/structure in mind for the modules/files and it will try to overwrite configs and other things that may not want to be overwritten by something else on the system.
Do not conflate the OS with what FreePBX, itself, does. This is why the manual install have instructions on where to install things, what to change as far as ownership/group and permissions and what dependencies you need to install.
So in order to do this it would require things to be updated/modified across the board if you change the default location of the modules from /var/www/html/admin to some other file structure or any other file structure layout.
Can it be done? Sure. As long as you know what you are doing. Claiming there is no rationale for not running other services with it, however, it just erroneous.
Only for commercial modules, all other modules are not encoded. That would make installing FreePBX on other OSes impossible if that was the case but it’s not. That’s why the statement was made that Debian can’t use commercial modules.
Where I am having my misunderstanding is that FreePBX 15 can support PHP 7 without issue since there are numerous modules (non-commercial and commercial) that are still on the v13 code track. The code track that is based on PHP 5.3. There were changes between 5.3 to 5.6 and from 5.6 to 7.x so how are those modules on the v13 track updated to support PHP 7?
I’m finding this claim that v15 works fine with PHP 7 misleading because as @dicko said sure it may work fine with 7.0 but that is EOL as well and everything is pushing out 7.1 or higher which will cause issues. Also, if the claim is v15 works fine with PHP 7 then why isn’t v15 at least on PHP 7.0? Why does v15 still use modules from the v13 track (same as v13 users) but still hold the claim it supports PHP 7?
Also in this thread some people say that FreePBX 15 runs with PHP 7.x, but in the beta release notes it is very clear that FreePBX 15 only supports PHP 5.6. It seems that is the truth.
By the way, commercial modules do not interest me.
FreePBX is a very good software and I like to use it. But that it is still based on an outdated PHP version, I find it catasrophic. Also, the claim to be the only application on a server is almost cheeky for me. I have many different applications on the same server and that is not a problem. An additional server in the cloud alone for FreePBX is too expensive for me. FreePBX does not seem to be programmed to coexist with other applications. Very selfish.
I have FreePBX 15 working on Debian 10, PHP 7.3 using the edge track. UCP, XMPP, everything works fine that I have tested out. I recommend you give it a try; test it for yourself. If it’s latest and greatest you want, it’s available.
This comment is ridiculous, and your interests are very much in conflict with each other.
What do you mean by “support”? Does a version of FreePBX 15 work with PHP 7.3: yes. Is Sangoma going to support that? Probably not yet, but if you want full Sangoma support, the path is clear: install FreePBX Distro with the current stable version of FreePBX on it.
Should FreePBX coexist with other software? It’s open source; you can do whatever you want really. But I don’t see any reason Sangoma should support that. Cisco Call Manager used to run on a version of Windows 2003. Should they support a server that runs Call Manager and Minecraft? Absurd.
Virtual machines are cheap. Set up one with FreePBX and another with your CMS.
I can’t give a definite answer on this but if the modules didn’t have any deprecated PHP, there’s no reason they shouldn’t still work with PHP 7.x.
I run several phone servers with FreePBX and am very satisfied. Everyone runs in their own virtual machine with the FreePBX distro. So I know how to go that way. And I do not need the support of Sangoma, it works so well.
I’m stumbling now, however, that I should get FreePBX on a server with Debian 9 and PHP 7.0 to work. An additional server will not be granted to me in this case. There are people and companies that save every penny.
I opened another thread in which I describe that unfortunately I can not even change the path where the web should be installed. It seems to work, but then there are funny side effects.
Another version: If it ain’t official, it didn’t happen.
BLUF: Working with the team and supporting the team is far more likely to get the team where we want the team to end up than sniping and complaining. Roll up your sleeve and dig it.
FreePBX is a lot of things to a lot of people. While it would be wonderful if it just magically worked the myriad ways that people want, the economic model of OSS doesn’t really support that. If one has a problem with the system, one needs to contribute to get it fixed. If someone thinks that Sangoma should be fixing it because they’re “selling” it, they might need to look at the fine print.
I, personally, believe that if someone is going to use free software, they need to support it with code. Of course, I’m old school - I started out on OSS with 386BSD 0.8. Even then, though, I needed a CD-ROM driver so I had to write it. I donated it back to the project and was rewarded with my CD working. Same deal here. If someone has a problem, almost all of the code is OSS - dig in and figure something out. We don’t learn without effort.
If someone over-promises on a project, it isn’t up to our bosses to fix it by spending more money than we told them they would need to spend. We hate it when someone does it to us, people hate it when we do that to them.
There are solutions. If one has a server, it can be virtualized. Implementations can be split across servers. Multiple PHP versions can be installed. The Distro can be used in the old fashioned way. There are different Asterisk Managers. There are no limits to the creative ways that we can solve these problems.
I’d rephrase that as “No ticket, limited chance of being fixed.”. An issue/problem itself may still exist, but without it being tracked then it’s up to someone looking through the forum/deciding to tackle it thus limited chance of being fixed.
This is what can be done when you are not limited to yellowdog update manager
There are folks running (myself included) FreePBX, Asterisk, Home Automation, Motion, Mosquitto, Plex, postfix. Hylafax and xrdp on Raspberry Pi’s .
Asterisk is a relatively tiny load nowadays on a modern CPU. So for the adventurous, don’t listen to this B.S. that it can’t walk and chew gum. (but seriously, don’t expect to edit videos on the Desktop ;while talking to your Granny either )
You mean like a working HA solution for $3000? + 2 x every commercial module (this makes absolutely no sense as only one can possibly be active, did anyone Sangoma related think that through? )
edit: Is the HA thing even close to working yet?
Most of us clouders have that already for $1 a month
)
