Shutting down your bug reporting system as you push out a major beta release is certainly a bold choice. Don’t know if you heard, but Github has a facility for users to open issues.
Anyway, here are some problems I’ve come across after installing version 17:
IVR module breaks reload when it tries splicing into macro-dial-one (at /var/www/html/admin/modules/ivr/functions.inc.php:45) (looks fixed with latest framework)
PHP Deprecation Notice: Optional parameter $name declared before required parameter $foreign_name is implicitly treated as a required parameter in /var/www/html/admin/modules/directory/functions.inc.php on line 282 (fixed)
PHP Deprecation Notice: Optional parameter $id declared before required parameter $dest is implicitly treated as a required parameter in /var/www/html/admin/modules/setcid/Setcid.class.php on line 88
Composer problems. I really thought we’d do away with these version locked libraries in the new release – if you’re committing your vendor folder to VCS it never works out well.
symfony/translation is locked to an old version that requires symfony/translation-contracts which conflicts with the newer symfony/contracts. Result: PHP Fatal error: Declaration of Symfony\Component\Translation\TranslatorInterface::getLocale() must be compatible with Symfony\Contracts\Translation\LocaleAwareInterface::getLocale(): string in /var/www/html/admin/libraries/Composer/vendor/symfony/translation/TranslatorInterface.php on line 69
Removed a couple of the Composer package incompatibilities that were due to mismatches with module-specific vendor directories. It would be nice if there was some way to hook into the FreePBX Composer libraries so there could be a central location to avoid conflicts and redundancy.
Thanks for the heads up. Recent communications re: our issue tracker move have indicated our intent to migrate to Github for this purpose. Not fully implemented yet, but you can see the progress on this here here: Issues · FreePBX/issue-tracker · GitHub
PHP Warning: Undefined array key "host" in /var/www/html/admin/libraries/BMO/Database.class.php on line 299
PHP Warning: Undefined array key "port" in /var/www/html/admin/libraries/BMO/Database.class.php on line 301
PHP Warning: Undefined array key "secret" in /var/www/html/admin/modules/core/functions.inc/drivers/PJSip.class.php on line 586
PHP Warning: Undefined array key "username" in /var/www/html/admin/modules/core/functions.inc/drivers/PJSip.class.php on line 610
Wouldn’t it be better to have issues enabled on each of the modules where people can go to the module and file a report.
They can still all be managed from a single dashboard https://github.com/issues?user=freepbx and it would allow pull requests and issues to track together, auto-close etc.
I assume it’s for users who aren’t as familiar with FreePBX, and just want to file a bug report without worrying about what module. Github does allow issues to be transferred between projects, hopefully they’ll be taking advantage of that. Even as someone who will just file issues, not manage them, it’s nice having those connections you mention between issues, PRs, discussion/wiki, etc.
PHP Deprecation Notice: Optional parameter $thispage declared before required parameter $currentcomponent is implicitly treated as a required parameter in /var/www/html/admin/libraries/BMO/GuiHooks.class.php on line 77
PHP Deprecation Notice: Using ${var} in strings is deprecated, use {$var} instead in /var/www/html/admin/libraries/BMO/GuiHooks.class.php on line 139
Not sure if this is an informational notice or what, but got it during an outbound call:
-- Executing [s@macro-user-callerid:27] NoOp("PJSIP/7040-00000006", "Macro depricated!! To keep the same line numbers") in new stack
-- Executing [s@macro-user-callerid:28] NoOp("PJSIP/7040-00000006", "Macro depricated !! To keep the same line numbers") in new stack
PHP Warning: Undefined array key "AMPDBPORT" in /var/www/html/admin/modules/backup/BackupBase.php on line 204
PHP Warning: Undefined array key "AMPDBPORT" in /var/www/html/admin/modules/backup/BackupBase.php on line 212
PHP Deprecation Notice: trim(): Passing null to parameter #1 ($string) of type string is deprecated in /var/www/html/admin/modules/backup/BackupBase.php on line 230
(we don’t define AMPDBPORT because we use socket connections for DB)
My experience has been that after initial install of framework there’s a conflict between these interfaces, but then when doing a reinstall it works ok? The thing breaks at first and needs to be manually updated and then reinstalled. It seems like a fragile state of affairs, and devs are just painting themselves into a corner by doing things like manually patching vendor code which will make updates even more difficult in the future.
[12-Feb-2024 12:10:38 America/Toronto] PHP Notice: Only variables should be assigned by reference in /var/www/html/admin/modules/core/functions.inc.php on line 2151
[12-Feb-2024 12:10:38 America/Toronto] PHP Notice: Only variables should be assigned by reference in /var/www/html/admin/modules/core/functions.inc.php on line 4647
[12-Feb-2024 12:10:38 America/Toronto] PHP Notice: Only variables should be assigned by reference in /var/www/html/admin/modules/core/functions.inc.php on line 3051
Oh I’m sure there’s going to be quite a few of this. All three of these errors are due to the variables not being assigned before being called on.
I’ve found this issue with a few things in PHP and even MySQL/MariaDB. The latest releases of each of those, PHP 8.x and MySQL/MariaDB 8.x or higher, the default settings are much more stricter than previous versions. It has highlighted a lot in this project where poor coding standards, etc have been used.
Previously in PHP, you could do things that were considered bad practices and not the preferred way of doing things, like pushing a reference to an unassigned variable without errors being thrown. Much like in MySQL/MariaDB, in 5.x you can do a lot of poor syntax and query structures such as add/update a row that doesn’t have default values set for a field or use reserved keywords as field names without any special escaping. Now those poorly written syntaxes throw serious errors unless you either fix them or reduce the policies to something way less strict.
I would like to think most code written from 13-15 is free of this. That said I am sure I am still guilty of this in places. For the stuff I do now I use static analysis which gives me a beating if I don’t do many of these things. It would be good to see something like psalm in the FreePBX workflow but that would be a lot of work to clean up that much code. There is no “business case” to fix the old stuff and invest in it so they won’t. I asked consistently for a 6 month bug fix release where nothing new was added, simply fix bugs and clean up the code base. Management consistently said they wouldn’t pay for it.
