[3.0]: The installer ignores an existing $mbname in Settings.php

[albertlast]

Basic Information

The web installer's Forum name field always offers My Community, even when Settings.php already carries a different $mbname. Whatever is there is discarded.

The field's value is a constant language string, with no fallback to the loaded config:

// Themes/default/InstallTemplate.php:314
<input type="text" name="mbname" id="mbname_input" value="', Lang::getTxt('install_settings_name_default', file: 'Maintenance'), '" size="65">

$txt['install_settings_name_default'] = 'My Community'; — Languages/en_US/Maintenance.php:171

Sources/Maintenance/Tools/Install.php:668 then writes $_POST['mbname'] back unconditionally, so the prepared name is replaced by whatever the field happened to offer.

Config::$mbname is available at that point. forumSettings() calls Config::load() at Install.php:605, before the template renders, and Config::load() does populate $mbname from Settings.php — I checked that directly:

$ php probe.php          # autoloader + the constants index.php defines, then Config::load()
isset=yes
mbname=[SMF Dev]

Steps to reproduce

1. Before installing, put a Settings.php in place carrying $mbname = 'Example Forum'; — copy other/Settings.php and edit it, which is what a prepared or scripted deployment does.
2. Run install.php and go on to the Forum settings step.
3. Look at the Forum name field.

Expected result

The field is pre-filled with Example Forum, the name already configured.

Actual result

The field offers My Community. Finishing the install leaves $mbname = 'My Community', and the prepared name is gone.

Version/Git revision

3.0 Alpha 4 — release-3.0 at 6465d59

Database Engine

All — nothing here is engine-specific.

Database Version

8.4.11-MySQL

PHP Version

8.4.24

Additional Information

I am genuinely unsure this is worth changing, which is why it is a report and not a pull request. Both sides seem fair to me:

For: preparing Settings.php and then running the installer is an ordinary way to stand a forum up, and the installer already honours that file elsewhere — Config::$db_type and Config::$db_passwd are read at Install.php:889 and :921 to decide whether the database-confirmation step appears at all. The forum name is the one prepared value that is silently dropped.

Against: the database form fields do not carry Settings.php forward either; their defaults come from php.ini via getDefaultHost() and getDefaultUser(). So today's behaviour is at least consistent with itself, and it is arguable the installer is meant to be filled in by hand from end to end.

If it is wanted, it looks like one line. Config::$mbname is a typed static with no default, so it needs isset() rather than ??, which would still throw:

value="', isset(Config::$mbname) && Config::$mbname !== '' ? Config::$mbname : Lang::getTxt('install_settings_name_default', file: 'Maintenance'), '"

Low risk either way: a stock other/Settings.php already says My Community, so an ordinary install would look no different.

Found while reviewing #9317, where the Docker entrypoint pre-seeds $mbname and it turns out to have no effect. That line is being dropped from the pull request regardless of what happens here — this issue is only about whether the installer should honour the value.

I traced this in the source and confirmed the Config::load() half by running it; I have not sat through a fresh web install end to end, so the final "Actual result" line is read from Install.php:668 rather than observed.

[jdarwood007]

I don't think the intention of the installer is to ever read any of the values in Settings.php. We pull the default, as that is translatable, whatever the current language has specified.