I've seen this particular snippet in gazillions of install profiles in the meantime:

/**
 * Implements hook_form_FORM_ID_alter().
 *
 * Allows the profile to alter the site configuration form.
 */
function coredev_form_install_configure_form_alter(&$form, $form_state) {
  // Pre-populate the site name with the server name.
  $form['site_information']['site_name']['#default_value'] = $_SERVER['SERVER_NAME'];
}

It's time to reverse the logic for the default value, and instead make install profiles override it to an empty string or whatever.

CommentFileSizeAuthor
drupal8.install-site-name.0.patch1.55 KBsun

Comments

Everett Zufelt’s picture

What's the benefit of this change? Speaking as only one person, I almost always overwrite the value anyway, I would prefer it left empty.

sun’s picture

Assigned: Unassigned » sun

The goal of this change is to remove unnecessary code from many installation profiles, which simply copied the hook_form_alter() from the core profiles in order to prepopulate the default value for the site name.

My intentions are purely technical - solely targeting needless duplication of code due to a weird default value in core's installer.

While the actual default value may be debatable on its own, that's not the topic of this issue.

marcvangend’s picture

I agree with Everett, it doesn't make sense to use the server name as default. If that's not the topic of this issue, then we should make it the topic of this issue.

Have you asked yourself why this particular snippet is duplicated over and over again? I think it's just because default.profile (D6) and standard.profile (D7) do it, and people simple copy it as 'best practice' without a second thought.

Two days ago, I was observing my sister (she's a doctor, not a geek; she is "Verity") installing and configuring Drupal. During the whole process, there was just one point when she really did not know what to do: choosing the Site Name in the installer. (Even the block region demonstration page confused her less!) The problem was not even the lack of a help text below the field - what really confused her, was the default value. The fact that it is set to the server name (which looks a bit technical), gave her the impression that this value is not arbitrary, but that there is a 'correct' value she needed to enter (or else Drupal does not work).

I realize that observing a single person does not count as a scientific user test, but I am convinced that using the server name as default value is something we should actively discourage instead of making it a default.

sun’s picture

Issue tags: -API change, -API clean-up

drupal8.install-site-name.0.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, drupal8.install-site-name.0.patch, failed testing.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

quietone’s picture

The patch here removes lines from standard.profile and minimal.profile that have since been removed in #2473709: Do not use SERVER_NAME as default value for the site name. The removal of those lines is the goal of this issue, See #2. That strongly suggests that there is nothing to do here.

Another change in the patch is to add the server name as the default site name in the install process. Comment #3 gives a example of why that is not a good idea. In #2473709: Do not use SERVER_NAME as default value for the site name the site name with a placeholder. Again, this caused problems and the place holder was removed, see #2494131: Placeholder text for site name in installer can be confusing.

It seems that leaving the site name blank has been chosen by the community. Closing this as won't fix.

Of course, if you disagree, reopen the issue by setting the status to 'Active' and comment on why you think this should be done.

Thx.