Alternative to core_users_list() in FreePBX 14

I am trying to bring an old php script up to date to work with FreePBX 14+ and have hit a small hurdle. The script calls upon core_users_list() to get a list of extension numbers from FreePBX for validation (did the user enter a valid local extension #). Unfortunately, core_users_list() is not available in v14+.

What is the alternative to core_users_list() in v14 and newer?
Is the alternative backwards compatible or do I need to code for both (pre-14, 14-and-newer)?

Thanks in advance!

No one cares to chime in on this? :anguished:

That function is in FreePBX v14… grep through your /var/www/html/admin directory and you should find that it is defined in modules/core/functions.inc.php.

I was able to call it perfectly fine in v13 but I’m told the function doesn’t exist when calling it from the same script in v14. So, am I missing some other change from v13 to v14 in this function?

Maybe it’s deprecated. All it does is make a call to FreePBX::Core()->listUsers().

I tested with a simple CLI script:

<?php

include('/etc/freepbx.conf');
$getAll = FALSE;
var_dump(FreePBX::Core()->listUsers($getAll));

?>
2 Likes

Excellent. Thanks for pointing me in the right direction. I should be able to backport this to v13 too. I really don’t want to have to bake version detection into such a simple script. I just need to ensure the user-supplied extension exists before attempting to perform the next steps or all hell breaks loose.

1 Like

Just keep in mind that v13 is using PHP 5.3, v14 is using PHP 5.6 and v15 will be at PHP 7.x. Certain commands and functions where deprecated between 5.3 and 5.6 along with pretty much all deprecated functions being removed from 7.x. On the flip side, new things have been added as well.

So if you take a module, like Core, and you do not look at the differences between the major version releases then you’re blindly assuming that nothing has changed. The fact is something might have either due to a function no longer being available or a new method/function was introduced and could handle it better.

Also, at this point v13 is pretty much just there. It doesn’t get touched unless it absolutely has to be touched. Worrying about back porting things to versions that are either EOL or a dead man walking (like 13) may not be the most advised thing.

1 Like

Just keep in mind that v13 is using PHP 5.3, v14 is using PHP 5.6 and v15 will be at PHP 7.x. Certain commands and functions where deprecated between 5.3 and 5.6 along with pretty much all deprecated functions being removed from 7.x. On the flip side, new things have been added as well.

I’m not calling upon anything all that advanced that would change between PHP versions; everything I’m using are fairly basic functions, so I should be good there.

So if you take a module, like Core, and you do not look at the differences between the major version releases then you’re blindly assuming that nothing has changed. The fact is something might have either due to a function no longer being available or a new method/function was introduced and could handle it better.

In this case, the function still exists in the v14 code (as pointed out by @billsimon), but simply fails when called upon…which is what was tripping me up. I’m not the first to notice this, either…it was briefly mentioned by @lgaetz in his github about a year ago (github, which I only discovered recently while searching a cause for my issue). If the function has, in fact, been depreciated in FPBX v14, I’d like to think there are far more graceful ways of handling its demise than simply erroring out while the function still technically exists in the framework.

Also, at this point v13 is pretty much just there. It doesn’t get touched unless it absolutely has to be touched. Worrying about back porting things to versions that are either EOL or a dead man walking (like 13) may not be the most advised thing.

Trust me, I’m no more thrilled about continuing to support v13 than anyone else is…but there are still a LOT of v13 systems out there that I’m stuck consulting on and many are of the “if it ain’t broke don’t fix it” mentality about their PBX. In some regards, I can’t really blame them too much. They simply don’t want to give up their nearly EOL’d “stability” in favor of “headache-inducing bleeding edge” until they absolutely have to. That said, I do still have to keep supporting v13 systems in the meantime and, while I’m not adding anything in a backport to keep v13 working while still moving forward, I gotta at least be able to maintain the status quo in the interim. :weary:

I think I have what I need to get around this now. Thanks for the help!

This works perfectly for my purposes and works in both v13 and v14 without issue. Thanks again!

1 Like

There has never been an emphasis on preserving internal methods/classes. Starting in FreePBX 15 a formal API structure is in place. It will no doubt take time to mature, but it will minimize this type of thing going forward.

Thanks for the reminder of the project on github, I will test a fix when time permits.

Check out my fork. I think I already fixed it (it works), but would love a second look to confirm my work.

1 Like