The backup-restore.rst seems to refer to use hardcoded values when using the exaple Perl script. I think it's not necessarily true that elgg_get_config() might no longer be capable to return dbhost (and maybe other cofig values from settings.php) on Elgg 3.3 on purpose.

May I suggest you try with opening an issue about the problem in the Elgg repository at github to report that elgg_get_config() does no longer work as expected breaking backward compatibility and to ask if this was changed intentionally (and if not to fix it).

In case it was changed intentionally one possibility to set/retrieve dbhost and other database credentials without hardcoding them could be adding plugin settings for each database variable necessary. Maybe there are other solutions possible right now already. I guess when trying to use _elgg_config() you would have to make use of the PHP keyword "use" to set the namespace and load some classes defined in Elgg core. BUT! the functions starting with an _ are NOT meant to be used within plugins. They should only be used in Elgg core code because they do not belong to the API functions that are kept backward compatible throughout the lifetime of an Elgg major version but can change at any time. So, the question remains (hopefully asked if you open an issue at github) why the API function elgg_get_config does no longer work as it probably should.

In Elgg 3.0 we protected some configuration values. This mainly included the database configuration.

You can use: _elgg_services()->dbConfig->getConnectionConfig(\Elgg\Database\DbConfig::READ); to get all the information you want.

Keep in mind since you're using an _ function (_elgg_services()) this isn't part of public API and can be broken at any time (like iionly said)

Thanks iionly and Jerome!

I am glad to learn that any functions starting with _functionName are reserved for Elgg core codes.

iionly, according to Jerome's answer, I do not think I should open the ticket regarding this issue (already answered).

Jerome, if _functionName is for core codes, _elgg_services( ) is not a permanent solution then. I might take iionly's advice on creating plugin settings for these protected database values.

Really appreciate all your help! @RvR, @iionly, and @Jerome