FreePBX 16 beta available

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

11 Likes

I remember the prior discussion was PHP 7.3 I am happy to see this using 7.4.

4 Likes

Can’t wait to start testing it against PHP 8. :wink:

1 Like

slow down sparky :slight_smile:

1 Like
[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.

virtualbox on mac
image

Also available on the Raspberry Pi (since May 19):

[PBX] FreePBX for the Raspberry Pi - VOIP Tech Chat | DSLReports Forums

1 Like

Get your debugging tools warmed up :grinning: - 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 :wink:

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? ( :wink: )

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.