Support

After applying a temporary fix for the issue mentioned in my other ticket, I'm now running into a new issue: The restore script fails to read the siteurl variable from the config file:

php installation/cli.php execute
Akeeba Backup Restoration Script v.10.0.2
Copyright (C) 2006-2025 Akeeba Ltd.
This program is Free Software, it comes with ABSOLUTELY NO WARRANTY and you are
welcome to redistribute it under certain conditions; use the `license` command
for more information.

Initialising restoration
» Detecting versions
» Loading existing configuration
» No wp-config.php found
Restoring database ‘site’
» Restored 1.26 MB of 1.26 MB (0.00%) – ETA: 0 seconds
» Finished

ERROR

Unhandled Akeeba\BRS\Framework\Cli\Exception\ExecutionException exception

You need to set the siteurl or homeurl in your config.yml.php file.

-- /redacted/installation/platform/src/Cli/Step/Setup.php:87
#0 /redacted/installation/platform/src/Cli/Step/Setup.php(35): Akeeba\BRS\Platform\Cli\Step\Setup->setURLsInHelper()
#1 /redacted/installation/src/Framework/Cli/InstallationQueue.php(177): Akeeba\BRS\Platform\Cli\Step\Setup->execute()
#2 /redacted/installation/src/Cli/Command/Execute.php(56): Akeeba\BRS\Framework\Cli\InstallationQueue->execute()
#3 [internal function]: Akeeba\BRS\Cli\Command\Execute->__invoke()
#4 /redacted/installation/src/Cli/Application/Application.php(111): call_user_func()
#5 /redacted/installation/cli.php(107): Akeeba\BRS\Cli\Application\Application->execute()
#6 {main}

The respective config section, generated by config:make, is:

setup:
superuserid: 0
superuseremail: null
superuserpassword: null
superuserpasswordrepeat: null
blogname: RemoteWP
blogdescription: ''
homeurl: ''
siteurl: ''
dbcharset: utf8mb4
dbcollation: ''
removephpini: false
removehtpasswd: false
htaccessHandling: none
disable_autoprepend: false

Whoops sorry! I anonymized both snippets and removed the value from "siteurl" where it should have been "redacted" - in other words: the config does contain a value, format is

siteurl: 'https://[redaced].org/wordpress'

However I debugged a little further. It seems like the issue is related to how config:make generates the default "replacements" section as in my example it has the following value:

'https://[redaced].org/wordpress': ''

So, the script is indeed using the provided siteurl from the config, however it will then set it to an empty value in the replacement step. WP will show an DB connection error when the siteurl option is empty, so I was assuming that the restoration failed and repeated the script. When I then re-ran the script, it's apparently consumed not only the config.yml.php value (which is fine) but also the existing siteurl (not sure why) from the DB - and is throwing an error as described in the first post.

So, long story short: the replacement value generated by config:make was wrong.

Case close from my side.