FAQ: https://wiki.freepbx.org/display/FOP/FreePBX+16.0+Beta+Release
Follow up threads to the forum beta category where appropriate:
https://community.freepbx.org/c/beta-program-issues
FAQ: https://wiki.freepbx.org/display/FOP/FreePBX+16.0+Beta+Release
Follow up threads to the forum beta category where appropriate:
https://community.freepbx.org/c/beta-program-issues
I remember the prior discussion was PHP 7.3 I am happy to see this using 7.4.
Canât wait to start testing it against PHP 8.
slow down sparky
[root@freepbx ~]# fwconsole ma list | grep framework
| framework | 16.0.10.10 | Enabled | GPLv2+ |
[root@freepbx ~]# php -v
PHP 7.4.16 (cli) (built: Mar 2 2021 10:35:17) ( NTS )
Anyone else think that Bill was the kid the took his toys apart and rebuilt them again?
GA for Rocky Linux came out today. Would make a good project to try with PHP8.
Also available on the Raspberry Pi (since May 19):
[PBX] FreePBX for the Raspberry Pi - VOIP Tech Chat | DSLReports Forums
Get your debugging tools warmed up - FreePBX 16 wonât currently install using PHP 8:
STARTING ASTERISK
Asterisk Started
Assuming you are Database Root
Checking if SELinux is enabledâŚIts not (good)!
No /etc/asterisk/asterisk.conf file detected. InstallingâŚWriting /etc/asterisk/asterisk.confâŚDone
Checking if Asterisk is running and we can talk to it as the âasteriskâ userâŚYes. Determined Asterisk version to be: 18.4.0
Checking if NodeJS is installed and we can get a version from itâŚYes. Determined NodeJS version to be: 14.17.1
Preliminary checks done. Starting FreePBX Installation
Checking if this is a new installâŚYes (No /etc/freepbx.conf file detected)
Database Root installation checking credentials and permissionsâŚConnected!
PHP Fatal error: Declaration of FreePBX\Database::query() must be compatible with PDO::query(string $query, ?int $fetchMode = null, mixed âŚ$fetchModeArgs) in /usr/src/freepbx/amp_conf/htdocs/admin/libraries/BMO/Database.class.php on line 239
FreePBX installation failed!
But it does install and run ok with the latest framework and PHP 7:
fwconsole ma list | grep framework
| framework | 16.0.10.11 | Enabled | GPLv2+ |
root@FreePBX:~# php --version
PHP 7.4.20 (cli) (built: Jun 4 2021 23:22:32) ( NTS )
With 15 they released the upgrade tool when it went GA; I would expect the same here.
Yeah, I donât think weâve even touched it with PHP 8. YMMV? Commercial modules probably wonât work due to ioncube being version dependent on php7.x right now.
Matt
Is there not any PHP signing tool that does not hard lock versions?
Because this sounds familiar.
It is not signing but obfuscation. It basically turns the code in to a binary blob that is processed through a php extension by way of a license file. Formally zendguard which no longer updates to new PHP versions or ioncube. They have to do a lot of work for each major release since this interacts with the plumbing of php.
This is the only way to make it âhardâ for someone to steal commercial code. Note it still isnât that hard and it is legal in some countries.
Got a patch once from a German fellow for a commercial module lol.
Correct, I used the wrong term.
But the point is that I find it hard to understand why solutions are used that require specific versions of PHP.
I am absolutely not a PHP developer, so I have no insight into this side of things.
Perhaps because PHP continuously patches itâs releases to eliminate security issues but the âobfuscatorsâ need to equally (perhaps more so) patch their code to match the fixes. Itâs a chicken-egg type thingy. Likely Zendguard gave up because it was apparently quite easy to find a good EasternEuropean/Asian coder that could crack a particular file (for a price).
FreePBX is stuck with PHP for the foreseeable future, so wait for ioncube to âcatch upâ to PHP 8, then wait for FreePBX to patch their several (hundred?)thousand lines of code and audit them
The immediate obstacle to using PHP 8 is not commercial modules or zendguard/ioncube issues.
The single most basic foundational module (Framework) that is key to constructing FreePBX will not currently install using anything other than PHP 7.
There is a lot of technical debt. The code base is over a decade old and originated in php4 with a small helping of perl and bash scripts. With 14 the minimum finally got bumped to php 5.6 which was a welcome change. Commercial modules aside the move to 7.4 and ultimately 8.X is a good goal. The refactoring will however be breaking in many cases which means a fix to php 7.4 code may not cleanly patch back to previous releases. Currently most bug fixes in 15 can be merged all the way back to 2.11 or 12. That goes away starting in 16+ assuming the team is going to use the 7.x features and syntax.
One thing I would like to see at the top of all php files in 16+ is
<?php
declare(strict_types=1);
then proper type declarations. Doing so âThere will be bloodâ but that alone can clean up so many weird edge cases
As I have ventured in to new projects I get to run parallel with php releases and write code for the latest. Honestly it is soooooooooooooo much nicer being able to write php like a real language.
Perhaps FreePBX should be rewritten in golang or rust? ( )
There are non PHP alternative platforms like Clearly Cloud or switchvox. FreePBX will always be mostly PHP. If you want a non-PHP PBX youâd have to use something else. Rewriting free PBX in a different language would make it something else anyway.