Apparently the latest Debian (13) is considered broken and unsupported by our witch doctor friends up stream.
While Alpha 1 of the latest Debian LTS was released in December and RC1 in June we once again discover a lack of development and QA. The time to discover the platform you standardized on has bugs isn’t 2 days post stable release. This is especially true when your promise in standardization is people could run upstream (debian) updates and be always secure and up to date from an OS standpoint. They apparently forgot or didn’t know, whichever is worse, to make a promise like this you have to have that platform in a lab and do continuous updates and testing.
Why is it hilarious? Bookworm is fully supported by Debian until June 2026 after which it goes into LTS until 2028. There is absolutely no issue with them keeping FreePBX v17 on Debian 12 as long as it is a supported upstream release, which it is still.
Using PHP 8.2 which is EOL and loses security support in December can be an issue. The thing is the proof is in the pudding they aren’t testing. You can’t find issues 2 days post release then throw out a panic message. They literally need someone on a regular basis running apt update then seeing what breaks. This needs to be done with stable and pre-release versions.
I will note that I always thought it ridiculous they were going to allow blanket updates without controlling the environment. We learned that back in the trixbox days
I can run Asterisk 22.5.1 and FreePBX-17 with PHP 8.2 on Debian-13 right now. The difficult part for FreePBX is another round of code changes to accommodate PHP 8.3 or beyond. If they are smart, they should shoot for the highest available release of PHP and start modifying their code for the future. I don’t expect Debian versions to be the limiting factor, but rather older code they have continued to use.
It sounds like the gotcha might be that there is no platform available for commercial modules with Trixie. Wouldn’t affect Incredible PBX which @kenn10 already has up and running.
I’m not sure what you are basing that on. ionCube works just fine with Trixie running PHP 8.2. In order to move to PHP 8.3 it will require ionCube to be a different version (v13 = 8.2 and v14 = 8.3) and in order to move to PHP 8.3 on Debian 12 you need to install the Sury repos since PHP 8.3 doesn’t exist in the Bookworm repos. So just jumping to PHP 8.3 on FreePBXv17 means that every single user would have to do a major update to their system to get PHP 8.3 and the latest version of ionCube.
Not only that, while there aren’t huge changes between 8.2 and 8.3, the deprecation items need to be paid attention to since in 8.2 they may throw silent errors, no errors or just warnings but in 8.3 they will throw exceptions if not handled properly.
What I’m curious about is how much testing has been done outside of getting it to install and doing a handful of basic things. Backup/Restore tested? Certs tested? Any checking to see if things like MariaDB, Nodejs, npm or any other software/applications are playing nicely? Not having a visible error or warning in the GUI doesn’t mean they don’t exist.
I just ran into issue on another system (not FreePBX) but because the database got updated to a new version while everything ran as it should, one certain piece kept failing because a column wasn’t being used in the INSERT/UPDATE commands and the newer version of MariaDB had was more strict policies that blocked the bad SQL statement while the previous version allowed it.
Yes, I have FreePBX-17 (open source modules), Asterisk 22.5.1, PHP8.2 all running on Debian-13. I restored a backup and that works. The screens all seem to work without crashing or exceptions.
I don’t really see the point in running it on Debian-13 if FreePBX isn’t going to support it until FreePBX-18. By the time they’re ready with FreePBX-18, Debian-14 and PHP 8.4 or 9.0 will be out. Its a futile game of catch-up if they maintain their existing ionCube infrastructure.
I spent a day making it work for the challenge. I wish people at Sangoma would similarly start planning for the changes that will be required to convert to PHP 8.3. That will be as big a challenge as it was to go from PHP 7.4 to 8.2.
For those who want the latest and greatest Debian or PHP, I don’t think FreePBX is going to be the best choice.
I mean PHP 8.4 has been out since Nov 2024 and it’s the default PHP version on Trixie. Guess they should really just skip PHP 8.3 and go straight to 8.4 in reality.
I’m not sure what this means. If they move to PHP 8.3 they just move to ionCube v14 which is built for PHP 8.3 and the v14.x release also supports PHP 8.4.
They shouldn’t even be worrying about PHP 8.3 at this point, it goes SFO in December which puts it in the same boat as PHP 8.2. The reality is moving from 8.2 to 8.3 will be a lot less work than 7.4. to 8.2. The big challenge is getting to PHP 8.4 because it’s a lot more stricter, things that are being using in 8.2 are going to throw errors in 8.4 and there’s a lot of stuff that breaks.
So moving to 8.3 can cause some minor issues right now but moving to 8.4 breaks things.
So rather than fixing the modules for dynamic properties they added a bandaid. They bandaid hers ripped off on a 8
9. they literally need to touch every class om the system.
Another train wreck you can’t force yourself to look away from…
Are you guys sure you don’t want to write a new GUI for Asterisk? How about one for FreeSwitch? FS PBX is getting started but still can’t compete with FreePBX features.
It’s more than just the GUI that would need to be updated. These classes control more than just the GUI but how things are written to the backend, read from the backend, write out config files, the API interactions and cron jobs. Throwing a fresh new GUI up is like painting a moldy rotting wall. Sure it looks fresh and clean just don’t lean against, try to hang a picture or shelves on it because the wall could just crumble apart.
AI agents could actually do almost all of those fixes honestly. AI isn’t yet ready to replace actual developers but it is ready to replace the tasks of certain developing countries. It would also save certain companies a lot of money so I don’t know why they don’t. In any case… I have thought about doing some stuff with laravel that ties in to the FreePBX plumbing for certain things. It is not high on my to-do list.
