In a side chat about technical debt within FreePBX this bug about use of #[AllowDynamicProperties] everywhere came to mind. This is an easy but kinda tedious fix. In a search on github it is still in the code base 100 times. If you want a good easy task to get your feet wet this may be a good way to contribute back. There is also no shortage of technical debt in the project, parts of the code base is old enough to drink in the US. There is also a chance some of this code was written while the developers were drinking. Clean up tasks are relatively simple in most cases. Just a thought
This is a great stop gap but while there’s no official timeline for it no one expects this to survive far into 9.x (maybe 9.0). Every other major project out there (like Wordpress) had laid out this isn’t a permanent fix and they need to not rely on it past 8.x.
I have no clue what PHP version they are targeting for v18 but at this point if it’s less than PHP 8.5 (really it should be 8.6) we’re right back in the same boat. Poor code maintenance forcing outdate versions of applications to be run.
The key thing the developers need to keep in mind, #[AllowDynamicProperties] is not a permanent fix it’s there to help you get by until you fix the outdated code and it may not live as long as you would hope. So far, I see being used a permanent fix which is just bad, bad, bad.
I will say it seems some of these have been cleaned up on the process of other task. I was surprised there were only 100 results. So this particular problem has had some cleanup. Probably 5-10 minutes a module would probably be all that’s needed. That’s why I said this is a good task for someone wanting to get their feet wet. Perhaps part of githubs hackathon.
There’s been ongoing work in this direction, agreed. Just removed the triage label from the issue referenced in OP and added the good first issue label, as well as v18 milestone.
Target for v18 is still Debian 13 per FreePBX Versions documentation – corollary: PHP 8.4 per Debian wiki on PHP.
Because it ships with it is the logic here? If FreePBX v18 actually sticks to it’s release timeframe what you’re saying is “We’re going to use a PHP version that will be SFO by the time we launch our GA release.” So in other words, when FreePBX v18 goes GA the version of PHP on it will only have SFO. Then we’ll spend around 12-18 months with zero support for PHP.
Why the focus isn’t on PHP 8.5, which gives you a full year of support and two years of SFO, is beyond me. PHP 8.5 means, according to time lines, there’s 2-6 months of unsupported overlap until v18 would go fully EOL.
Choosing to use PHP 8.4 for FreePBX v18 is either negligent planning or deliberate corner-cutting. Honestly, it could be a bit of A and B mixed together.
Citation needed.
Sure you can use FreePBX release timeline and PHP timeline. If in fact I need to point this out to you, there’s a serious problem already with the development of FreePBX v18. Here I’ll break down the differences for you to make it easier.
| Milestone | FreePBX v18 | PHP 8.4 | PHP 8.5 |
|---|---|---|---|
| Release / GA Date | 01-01-2027 | 11-24-2024 | 11-20-2025 |
| Active Support Ends / SFO Only | 01-01-2030 | 12-31-2026 | 12-31-2027 |
| SFO ends / EOL | 07-01-2030 | 12-31-2028 | 12-31-2029 |
| Months of PHP upstream support | 0 Months | 12 months | |
| Months of Zero PHP support | 12 months | 6 months |
Eh I don’t want them pushing version requirements up and up for no reason. When we’re still getting PHP 5.3 array syntax and $x = isset($y) ? $y : $z pushed in the year of our lord 2026 I think there are more important things to focus on.
This is valid code in PHP 8.x, I mean there’s cleaner ways to do that now but still valid code.
If the more important things are making sure that all that legacy PHP code is brought into modern PHP then this is exactly what this focuses on. Moving from PHP 7.4 to PHP 8.4 when PHP 8.5 will have been out for almost a year is a waste. The jump should be to 8.5 which will have longer support and well…you’re already doing the jump…just jump all the way.
If history is any guide, then Debian 13 will continue to provide security fixes for PHP 8.4 until (at least) the targeted Debian 13 EOL of summer 2030 (EDIT TO ADD: not coincidentally the FreePBX 18 EOL target as well ;-).
Please review the EOL calendar from PHP, specifically the EOL date for PHP 7.4 in November 2022:
7.4 - 28 Nov 2022 (3 years, 6 months ago)
…and contrast that with the Debian 11 security updates for PHP 7.4 (per Debian PHP wiki calendar [typo’d that link in earlier post, my bad]) which followed the upstream EOL date e.g. this set of security fixes for PHP 7.4 that was published by Debian for Debian 11 in December 2024!!
Most Importantly
The supported Debian Release version lifecycle is expanding in the Debian project, notably due to the influence of Freexian e.g. PHP LTS by Freexian but also hat-tip to Canonical & Ubuntu 
Great group of open source security conscious folks all around on these fine upstream projects!
PHP still allows a lot of bad behavior.
What FreePBX actually needs is a heavier lift. The project needs unit tests, end-to-end tests, static analysis, and strict typing. We use Psalm internally, and it catches countless errors before they ever become bugs. Future releases should mandate type declarations and return types on everything. Even without a dedicated static analysis tool, modern PHP will throw fatal errors and force developers to fix sloppy code.
Getting the FreePBX codebase to play nicely with strict typing will be a massive effort. The current code is full of strings masquerading as integers, integers pretending to be booleans, and absolute chaos under the hood. Cleaning this up is a noble goal, but it requires a massive investment of developer hours. That means someone has to convince the accountants to fund it.
I originally campaigned for FreePBX 15 to be a dedicated technical debt and bugfix release. As you can see, I lost that battle.