- Bootstrap updated to version 5.x.
- Improve user interface regarding design.
- Offer multiple themes that are customizable.
- Rewrite an ISO install.
- Don’t lock the server on only one Debian version.
So we can have multiple install scripts between versions. That’s great. I mean the changes between Debian 12 and Debian 13 means that using the Debian 12 installer on Debian 13 doesn’t account for all those changes including moves to deb822, etc. I’m sure you’re going to run into the same things with Debian 13 to Debian 14.
I mean thinks like Python, Apache, PHP, etc are all different versions between OSes. Example, Debian 12 is PHP 8.2 while Debian 13 ships with PHP 8.4 and Debian 14 will ship with 8.5 (most likely 8.6). That goes the same for everything.
Having it work on multiple versions of Debian is great as long as they lock all those versions to the same thing because otherwise you have FreePBX v18-deb13 and FreePBX v18-deb14 maintained. And let’s not make this harder for them as it is already, they’ve got plenty of problems keeping one OS version smooth.
340
That fine for me. Whatever, I understood your point of view.I know one day some people could try to upgrade the OS just to be curious and break their FreePBX..
That means each version of FreePBX will be tied to a specific operating system, just like before. That’s right. I know PHP 8.2 can be installed on Debian 13. I’m not sure about Python, but I assume so.
In that case, creating an ISO image to install FreePBX 17 or 18 seems to make sense, in a way.
I think an overhaul of the dashboard notification system is due. I’ve logged into thousands of systems, and its very rare that a system is not showing a notice for something. Many are unimportant and can auto dismiss after a few logins. Others come back after being dismissed. Once dismissed/deleted, there is no way to see the history. The date tag shows time elapsed instead of the date and time of the notification. Some notices are unnecessary and can be removed. There are lots of tweaks that could be done so that the notification area remains useful, perhaps crowd sourcing ideas here is warranted.
Yeah but that’s why the installer locks things into specific repo versions now so it doesn’t do that. They can try and it will fail, meaning at that point if they do upgrade the OS they went out of their way to do it.
You’re also ignoring that some things don’t survive to the next OS due to various reasons. You might not be able to install things on new OSes that are on the current OS. Because you can’t install those it makes downgrading certain things harder.
What really needs to happen is pick a direction and stick with it. We’re told there won’t be an ISO moving forward when switching to Debian but six months later we have an ISO that is …meh and takes up resources. In one thread we’re told “we’ll stick with the versions that ship with the OS for ease” then in another thread we get a poll on which NodeJS version we should use instead of the version that is shipped with Debian 13.
Not easy. Also, Everyone want to install everything on the same server forgeting this server is only used for VoIP. I saw that too. 
I’d like to see apache go away. php-fpm has been a standard pattern for php applications for quite a long time. Apache is overweight.
+1 with Lorne on the notification system. It’s broken. If I update some modules then notices about those modules being out of date should go away. It’s become a habit just to clear notifications without reading them, defeating the purpose.
I’ve been asking about proper IPv6 support for years and don’t expect it but will throw it in here since this is a wishlist. The v17 install script, for a time, disabled IPv6 in the kernel, a step backward from the SNGOS ISO which at least left it alone.
Bring back the Version Upgrade module if it’s not already planned; since we are going from Debian 12 to 13 we should be able to upgrade in place both the OS and the FreePBX software.
So you want nginx+php-fpm instead of moving to php-fpm with Apache? php-fpm isn’t a web server it replaces mod_php. It also takes overriding its core configuration to work with a single user since it’s multi-user by default. To make it work as a single user setup, it removes most of the the things that make php-fpm be what it is. The first step of php-fpm with FreePBX is to make it work like mod_php.
I don’t need to be ‘splained, I’ve done it before. Yes nginx+php-fpm. It works great. The main issue is FreePBX relying on htaccess files for directory security. This is not a highly technical change, just a bit of work.
I REALLY want to have a way to schedule Music on Hold ahead of time, using Calendar or any other convinient way directly from GUI.
Like for Easter play from X category, Christmas Y category… for each Queue, not the global one. And when Easter, Chirstmas etc concludes, revert to the default ones.
This is a Time Conditions feature add. You can make this request at any point, it doesn’t need v18 for it.
It’s pretty wild looking back at how much FreePBX has changed since v15. The API and backup improvements were already big steps, and now seeing AI becoming part of the conversation makes the evolution even more interesting.
I’m especially curious to see what ends up being practical in v18 rather than just experimental. The way tools like phonexa are also bringing more automation into communication workflows shows how quickly this space is moving.
Appreciate everyone’s feedback as we continue to make a lot of progress on v18 BETA work. You may have seen some of the efforts in PHP 8.2 → 8.4 modernization specifically in the associated release/18.0 and other branches in individual modules.
One item worth mentioning – but not yet seen in this topic, although it’s been mentioned in others – is the upgrade of the firewall subsystem, with a planned move to nftables and potentially some GeoIP support.
I would like to see User management/AD Sync have the ability to integrate with the extensions module. To assist with things like name updates, vm to email update, vm reset to stock, new employee onboarding, etc.
But even better lets get this going in 17 too!
I know it has been asked for a few times through the years and at time has even been worked on.
Move the default automated updates day to Sunday upon signup, or preferably randomise it. The admin can override it, but currently the vast majority will take Saturday every time when that’s what’s offered. It only makes things worse and worse. Encourage x% of the existing base to move off of Saturday. Put a retry day(s) if the automated updates fail. Send a repeating email notification if the automated updates fail. Build in a mirror performance checker before attempting automated updates, similar to work I have done for IN1CLICK. Treat failed automated updates as a serious concern rather than a “we’ll try again same time next week!”.
Halleluiah !
I hate having to to play snipe hunt when tracking down what some issue is. Having some type of historical data to review, throguh the GUI, would be incredibly helpful.
Awesome, Awesome !
We use pfSense with pfBlockering… with multiple VoIP system in Hawaii, we have zero need to have phone registrations done from outside of the USA, Nigeria, Italy, China, etc. So GeoIP blocking is one of our top uses of the pfSense systems. Having it built into FreePBX could really be awesome for sites that are not using pfsense. Would it have an option to plug in the same credentials from the pfBlockering into the FreePBX blocking ? Or would you be possible using the same modules ?
By the way, is there some type of public checklist of feature list/ requests we can see, where we can see if something is being considered or rejected ? or considered for future improvements ?
Feature Requested - Will Be Included | to be considered for the future | flat out rejected and why
?
Feature Request : Call recording
I want to be able to turn on call recording and have it record EVERYTHING - A ONE BUTTON “ON” that includes all Inbound, Outbound and Internal extension calling.
I want a single button that says record everything - at all times, unless a particular extension / path etc is deliberately excluded. An example : A designated fax line (or something similar that would be just tones and garbage.
This is very important for call centers, 911 calls, etc. and it would save a lot of time instead of having to go and tinker with each inbound route, each outbound route, and each extension individually or go do bulk handler.
Some of our clients don’t care about recording, some of our clients that deal with sensitive issues and call centers - absolutely want everything recorded. Several have contractual mandates including a client that run a national medical hotline and several others clients that run prisoner re-entry programs. So accidentally overlooking to get something turned on or adding a new extension and forgetting to modify it for call recording can get us / them in trouble.
I really want to have geoip-blocking and simply realized it by copying an allowed country with CIDRs list (ipset list) from my ipfire (not using pfsense, since ipfire is quite easyer for me) to pbxfirewall in advanced rules. So loosing iptables to be subsituted by nftables might be modern, but requires a lot of effort to be put into some learning sessions. For me the question does V18 run on Debian13 as well is also important.
There are parts of an inbound call that need to be recorded, but not always all. Not every call should be recorded, especially internally, and there are times when recording should be paused.
Understanding Force, Yes, Don’t Care, No, Never and how they interact with each other on different layers of a call is important. Storage should be considered too, or you’ll end up with several recordings for the same call.
Don’t forget, if you’re being paid to understand and implement it properly, a big red on/off button requires no skill or experience. So why not let the end user to do it themselves with a BLF button on a phone at that point?
You talk about clients that sound relatively large and important, I’d say that’s even more reason to manage it properly, appropriately, and do what you’re being paid to do. I mean that generally, it’s not a discussion about your arrangements.
I haven’t had a request like you’re asking for before. “Record everything” isn’t the same thing as a big on/off button. If I did, and it was for an hour or so and I needed one button to press, a better solution might be to turn on packet capture and pull the call if required.
Perhaps start a new thread discussing the particular scenarios you’re facing and we can see if you’re doing what’s required in the most efficient way possible. Maybe I’m missing the point. Lots of things can get you into trouble if done wrong, but what if you or someone else disables it all by mistake, or forgets to turn it back on?
All it takes is an employee wanting access and touching things you’d really rather they didn’t.