What is up with the lack of deprecation follow through?

What is up with this project and the fact that deprecated items have to live in it for so long? Outside of the Asterisk deprecations there are all the third-party deprecations that riddle this project. However, the worst offender in my opinion is this one:

[2022-02-15 07:03:01] [freepbx.INFO]: Deprecated way to add Console commands for module voicemail, adding console commands this way can have negative performance impacts. Please use module.xml. See: Sangoma Documentation
[2022-02-15 07:04:01] [freepbx.INFO]: Deprecated way to add Console commands for module backup, adding console commands this way can have negative performance impacts. Please use module.xml. See: Sangoma Documentation

This was introduced by the FreePBX developers back in 2014 for FreePBX v13 and the fact OOP/class-based functionality was added in. I get this was added as a way to information people “Stop using this method, it’s bad now” but we are now seven years past that and not only does this still exist, but it is also still being triggered by things within FreePBX. This would point to the fact this deprecated method is still in use after 7 years.

What is going on guys? Why can’t this project keep things current with its third-party vendors and even within your own development code?

1 Like

FYI this deprecation notice is not 7 years old. It was added in Framework 14.0.8 and Framework 15.0.7. In reference to supporting “Lazy Loading” (see the linked wiki). Lazy loading was added around 2018-2019 and the wiki explains the reasoning for doing so.

The wiki page itself was created in 2014 but the lazy loading and deprecation notices were added in 2019

1 Like

Well, that explains the notice not why something that has been deprecated for 3 years, at least, is still sitting around in the code. But this is just one example of numerous things within FreePBX that is years-old deprecated and in some cases where deprecated pre-v14 but still made it into v14, v15 and v16. With a 2-year release cycle that means there are things that are still in here that have been deprecated for over 6 years. The delay in getting Asterisk v19 support is a prime example. app_mysql was deprecated in Asterisk 1.8 but as of 2022 FreePBX is still using it for some reason.

That’s really what I’m trying to understand here. Why FreePBX is still relying on EOL, out of date and unsupported dependencies when there are more current and support versions of said dependencies.

I don’t mean to be too simplistic about it but I think there just are not enough programmers working on FreePBX. Let’s be honest, if the existing team took a year or so to stop feature development and just go back and work on tech debt then folks would be unhappy about lack of progress. To do both you’d need more developers.

2 Likes

I fought for a technical debt cycle of 3-6 months and couldn’t get it to happen because people want features not plumbing cleanup. In other words staffing or not, you are correct.

As opposed to now which requires them to redo the callerid stuff and anything else that is still dependent of app_mysql in order to deal with Asterisk 19?

What about next year? What happens when Asterisk v21 is released next year and things like app_macro, res_monitor and chan_sip are completely removed? Let’s be honest, they’ve known about app_macro for almost 5 years at least and the last two major releases are still filled with Macro() calls are core functions of the dialplan.

Is the plan to wait until after v21 is released like they did with v19 to address something that should have been addressed a long time ago (for various reasons). The removal of the three modules I mentioned from Asterisk are going to have an overwhelming impact on FreePBX. If there isn’t movement right now to address this, someone isn’t doing their job right.

Maybe all the people who use FreePBX without paying a dime will get into the open source spirit and contribute some tech debt cleanup. /s

6 Likes

That would be awesome but as I have pointed out before when this was brought up. There needs to be a plan, direction and leadership on this from the actual dev team. When this was brought up by @mattf in another thread, I pointed out that while going through and remove Macro() calls from places is easy, what is going to be replacing them? What replaces the Macro() calls in a Dial() string and when? What about things like Queues or other applications that have Macro() calls in their config files or in the system call like Dial() and Queue()?

What about the commercial modules that we can’t touch? So great, I fix all of the Queue() calls for this but what about the commercial part of Queues? Who is going to be touching that?

This goes in line with your work for PHP 7.x on the project. You could get as far as the open source side of thing buts you had no control over the commercial side of things. Some would call that incomplete on the project. You are going to have the same issue here.

You could have 25 people chomping at the bit to contribute and help with this but they would have no direction, no leadership, no idea on what the actual plan might be (if any). If this is going to be done it should also be done with a future forward vision so that 2 years from now things don’t have to be redone again and again.

Of course, at that point you have 25 people pushing patches/codes that needs to be reviewed, QA’d, tested, all the fun stuff. Who will be doing that? Will the QA team be able to handle that additional load? Or will they end up being overloaded because they have a hard time keeping up with 6-8 full time developers let alone another 25. Who will review all this to determine what will be accepted and thus need to go to QA and what will not be? That’s going to require someone(s) from staff.

2 Likes

My technical debt notes were apparently on the internal wiki… go figure…

Some low hanging fruit…

OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function ivr_get_details detected in /var/www/html/admin/modules/fax/functions.inc.php on line 252 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function languages_list detected in /var/www/html/admin/modules/languages/functions.inc.php on line 49 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function ringgroups_list detected in /var/www/html/admin/modules/ringgroups/functions.inc.php on line 75 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function vmblast_list detected in /var/www/html/admin/modules/vmblast/functions.inc.php on line 56 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function module_getinfo detected in /var/www/html/admin/modules/core/functions.inc.php on line 1074 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function ringgroups_list detected in /var/www/html/admin/modules/core/functions.inc.php on line 1302 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function core_dahdichandids_list detected in /var/www/html/admin/modules/core/functions.inc.php on line 1614 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function core_users_list detected in /var/www/html/admin/modules/core/functions.inc.php on line 1655 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function outroutemsg_get detected in /var/www/html/admin/modules/core/functions.inc.php on line 2430 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function outroutemsg_get detected in /var/www/html/admin/modules/outroutemsg/functions.inc.php on line 29 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function core_routing_list detected in /var/www/html/admin/modules/accountcodepreserve/functions.inc.php on line 30 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function core_devices_get detected in /var/www/html/admin/modules/accountcodepreserve/functions.inc.php on line 55 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function core_devices_get detected in /var/www/html/admin/modules/accountcodepreserve/functions.inc.php on line 55 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function core_devices_get detected in /var/www/html/admin/modules/accountcodepreserve/functions.inc.php on line 55 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function core_did_list detected in /var/www/html/admin/modules/allowlist/functions.inc.php on line 170 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function core_routing_list detected in /var/www/html/admin/modules/allowlist/functions.inc.php on line 205 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function core_did_list detected in /var/www/html/admin/modules/blacklist/functions.inc.php on line 17 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function core_routing_list detected in /var/www/html/admin/modules/callrecording/functions.inc.php on line 419 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function fax_detect detected in /var/www/html/admin/modules/fax/functions.inc.php on line 314 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function fax_get_incoming detected in /var/www/html/admin/modules/fax/functions.inc.php on line 323 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function ivr_get_details detected in /var/www/html/admin/modules/ivr/functions.inc.php on line 40 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function languages_incoming_get detected in /var/www/html/admin/modules/languages/functions.inc.php on line 67 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function core_routing_list detected in /var/www/html/admin/modules/paging/functions.inc.php on line 49 [] []
OUT > [2022-02-15 05:12:54] [freepbx.INFO]: Depreciated Function superfecta_did_list detected in /var/www/html/admin/modules/superfecta/functions.inc.php on line 158 [] []

One thing that will always help is NOT creating new technical debt. I noticed on my server one of the modules complaining about fwconsole is iot server which is a NEW module since things changed.

Also in this list allowlist is a new module since the function was moved in to a class.

Things like abuse of FreePBX::Classname need to be fixed to. In some modules the FreePBX class can be instantiated a dozen times for something like a page load.

I will look at regenerating my technical debt doc from memory on to my github in the next couple days.

Yeah, I think Sangoma has the exclusive burden of updating the commercial module side of things, but we welcome anybody who wants to help with the macro replacement work on the open source side of things. I opened up a JIRA epic to start organizing any issues surrounding Asterisk 21 related deprecations ([FREEPBX-23313] Asterisk 21 Support - Sangoma Issue Tracker) We may need to break it down further by module type though.

@franckdanard recently started working on some of the predial macros to get an idea of how much work it was going to look like for these types of changes. He’s also going to try to build a list of impacted other modules on the wiki so we can better organize tasking around it.

Your questions are relevant though - we’re going to have to work one by one through each usage of macro to figure out how to replace it (or if it can be replaced).

Some of the changes may not be logically backwards compatible and either are going to have to be hid behind feature flags or only within the next branch of FreePBX.

We look forward to any and all contributions with this work.

1 Like

Yes, I’m working on the core module right now.
The goal is to prepare what we need to replace macros with gosub.
Need to makes tests before publish.

BTW, It’s not worth shooting the ambulance either. :wink:

@franckdanard has publicly published a previously internal wiki page that @jfinstrom wrote about conversion from macro to gosub. We are starting to build the list of modules and issues associated with that work at the bottom of the page and will add them as we go through the code.

https://wiki.freepbx.org/display/FOP/Converting+Macro+to+Gosub

If anyone would like to help in contributing to the table and creating issues for the work needed to convert them we would love to have that help.

Then anyone in the community that would like to work on the actual conversion work can assign themself a ticket (so we’re not all working on the same things) and push their code up to git.freepbx.org.

Thanks again for all the enthusiastic voices about this work. I think that working together as a community we can move this work along much faster than if it’s just one or two people working on it on their own.

4 Likes

With regards to transitioning fwconsole commands to use the new module.xml lazy load stuff (warnings originally posted) this seems like low hanging fruit from a “getting started with FreePBX development” perspective. If you see something like that, feel free to give it a shot to convert it over and post a patch on git.freepbx.org. That’d help push back the technical debt burden we all bear as a community around this open source project.

On my system I see

[2022-02-17 05:04:19] [freepbx.INFO]: Deprecated way to add Console commands for module api, adding console commands this way can have negative performance impacts. Please use module.xml. See: https://wiki.freepbx.org/display/FOP/Adding+fwconsole+commands [] []
[2022-02-17 05:04:19] [freepbx.INFO]: Deprecated way to add Console commands for module backup, adding console commands this way can have negative performance impacts. Please use module.xml. See: https://wiki.freepbx.org/display/FOP/Adding+fwconsole+commands [] []
[2022-02-17 05:04:19] [freepbx.INFO]: Deprecated way to add Console commands for module iotserver, adding console commands this way can have negative performance impacts. Please use module.xml. See: https://wiki.freepbx.org/display/FOP/Adding+fwconsole+commands [] []
[2022-02-17 05:04:19] [freepbx.INFO]: Deprecated way to add Console commands for module queuestats, adding console commands this way can have negative performance impacts. Please use module.xml. See: https://wiki.freepbx.org/display/FOP/Adding+fwconsole+commands [] []
[2022-02-17 05:04:19] [freepbx.INFO]: Deprecated way to add Console commands for module voicemail, adding console commands this way can have negative performance impacts. Please use module.xml. See: https://wiki.freepbx.org/display/FOP/Adding+fwconsole+commands [] []

I may not have “everything” installed. That said it looks like for the open source side based on my system:

  • Voicemail
  • API
  • Backup

Notice deprication entries can be seen by running fwconsole dbug

Yeah, I was just looking at that too. I’m trying to see if I can hit a commercial module or two between things this morning from our side since it looks pretty quick and easy to resolve.

All right, I think I got most of the commercial modules knocked out this afternoon between meetings. Anybody want to join me and take on the last few modules (voicemail, api, backup) @BlazeStudios @billsimon, others ?

It’s really pretty easy and the docs on it take all the guesswork out. I’ll help if you have questions.

https://wiki.freepbx.org/display/FOP/Adding+fwconsole+commands#Addingfwconsolecommands-ModuleXMLLazyLoading

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.