Make default front page setting required and remove special case of /user/login

Did you installed the minimal or standard installation profile?

Hi rbaprado,
I have installed this with standard installation profile and it's working perfectly at my side.
regards,
Sourdrup

I created this bug report before finding this issue; I believe they're related!

rbaprado, is/was your "Default front page" field left blank on the "Site administration" configuration page (/admin/config/system/site-information)?

I've this same issue with D8.6.2 using minimal.profile.

Please see if #2693307: Front page set to /user if field is left blank is in effect here.

Editing my comment to say that I triaged this issue by manual testing to confirm, and updating the issue summary for clarity.

The default front page path was set to "/user/login" and not to "/node". So in this patch I have changed the default path to "/node".

Verified and tested by applying the patch #13.It was applied successfully.It was default set to blank instead of /node and also on updating the front page value to node , it is providing configurations saved successfully , but wasn't on editing it.Refer to the gif attached below.

After Patch -

Steps to test-
1. Go to the admin site.
2. Go to admin/config/system/site-information.
3. Verify the front page default value set.

Before Patch Results -

After Patch Results -

I will check on issue reported by @priyanka.sahani

In the latest patch, fixed the issue reported by Priyanka Sahni of default front page value to blank.

Honestly I think that the only thing that's missing is an explanation what the "default front page" actually is. Nothing else should be changed, in my opinion. It's just this little piece that's missing and which causes a lot of confusion like https://drupal.stackexchange.com/q/294800/15055 or https://drupal.stackexchange.com/q/295675/15055 for example.

Putting the #default_value in that field only makes it more confusing I think, because you can't really empty it anymore then. Let's simply add (/user/login) in brackets to the end of that sentence.

Optionally, specify a relative URL to display as the front page. Leave blank to display the default front page (/user/login).

I don't think that making /node the default is a good idea. What if the site has no front page view? Then that would be a 404. Does the minimal installation install Views and the front page view at all?

@leymannx

I don't think that making /node the default is a good idea. What if the site has no front page view? Then that would be a 404. Does the minimal installation install Views and the front page view at all?

Agreed, this is a good case not to change the default to /node.

But /user/login isn't quite correct, that is only if you are logged out. If you are logged in it is /user/[uid]. I think it is more accurate to say /user, which then redirects to the login page or your user profile page, depending on your state?

Well, looking at the code /user/login is correct. But when already logged in /user/login itself redirects you to your profile.

I would agree on making that more clear in the description. But I guess that this, again, might be more confusing. While /user really isn't correct.

Oh OK I see, that makes sense.

Perhaps then since your patch is at least an improvement it is the way to go. I don’t really have a suggestion for the description that would be concise.

Updated IS to reflect the approach.

Can the description of this issue be updated.
When I remove / node from settings for frontpage
I m redirected to user profile and not the user login page
In logged out state i m redirected to user/login page

If the only change is message change as done here:
Optionally, specify a relative URL to display as the front page. Leave blank to display the default front page (/user/login).

I would suggest to add that this will be displayed in logged out state and also state that user profile will be displayed in logged in state

@samiullah this is because /user/login redirects to the user profile page when you are logged in. This is noted in the previous comments. (It is not possible to access the login form if you are already logged in.)

As @leymannx noted in #23 the actual default path is /user/login so this is accurate. The fact that this behaves differently when you are logged in is something we could address in the description. E.g.:

Optionally, specify a relative URL to display as the front page. Leave blank to display the default front page, which is /user/login. Note this will redirect to the user profile page for logged in users.

The latest patch no longer apples no setting to NW until there is agreement on the text.

On a minimal install of 9.2.x I tried the string suggested in #28. I do like the additional information as it saves me the trouble of having to check what happens when you go to /user/login when you are logged in. I think that is helpful. And since it is so helpful having it in a third sentence as a note seems wrong. How about it is added as a clause to the second sentence like this:

Optionally, specify a relative URL to display as the front page. Leave blank to display the default front page (/user/login) which redirects to the user profile page for logged in users.

Does this need a test?

Can't apply patch #21 on 9.2.x

Checking patch core/modules/system/src/Form/SiteInformationForm.php...
error: while searching for:
      '#title' => t('Default front page'),
      '#default_value' => $front_page,
      '#size' => 40,
      '#description' => t('Optionally, specify a relative URL to display as the front page. Leave blank to display the default front page.'),
      '#field_prefix' => $this->requestContext->getCompleteBaseUrl(),
    ];
    $form['error_page'] = [

error: patch failed: core/modules/system/src/Form/SiteInformationForm.php:128
error: core/modules/system/src/Form/SiteInformationForm.php: patch does not apply

Adding new patch based on comment #30.Please check

@Abhijith S, thank you for your interest in this issue. There is no need to paste terminal output to prove the patch does not apply. just state it needs a reroll and do it. In this case however, a patch isn't needed just yet and I tried to convey that in #30, we need to have agreement on the text before making a patch.

On a minimal install of 9.2.x I tried the string suggested in #28. I do like the additional information as it saves me the trouble of having to check what happens when you go to /user/login when you are logged in. I think that is helpful. And since it is so helpful having it in a third sentence as a note seems wrong. How about it is added as a clause to the second sentence like this:

Optionally, specify a relative URL to display as the front page. Leave blank to display the default front page (/user/login) which redirects to the user profile page for logged in users.

I think this is a helpful way of rewording that, I agree that having the extra information about the redirect to the logged in user is good, +1

Does this need a test?

I don't think text changes need tests, so probably not needed.

Verified and tested patch #32 on Drupal 9.5.x-dev. Patch applied successfully and looks good to me.
Testing steps:
1. Install 9.5
2. Visit admin/config/system/site-information
3. Scroll down to the Front Page section.
4. Observe the description.
5. Apply the patch.
6. Visit admin/config/system/site-information
7. Observe the description for the front page section.
Testing Result:
1. After applying the patch Front Page section description has changed. Screenshots are attached for reference:
Can be move to RTBC

@yashingole, Welcome top Drupal! The Issue Summary states that the next step here is to a 'decide on the text' to display. That means this issue is not ready for testing. Remember to read the Issue Summary and comments to understand what needs to be done before testing a patch. Also, make sure the patch you are testing is on a development branch of Drupal, the latest patch here is against 9.2.x which is not a supported version of Drupal.

Setting back to NW.

I agree that "default front page" often causes a lot of confusion for those who start learning Drupal with the Standard installation profile, which set the default front page to /node.

But I'm not sure about simply adding "(/user/login)" after "default front page" in the sentence, it doesn't seem good enough regarding user experience. For those who start with the Standard installation profile, the default value in "Default front page" field indeed starts with /node. In this case, the behavior expected by the user when leaving the field blank is the default value /node (as the site started). "Whenever possible, build something that feels familiar. (...) If something seems unconventional, flag it and consider whether it should actually appear and work that way", right?

Maybe some more additional information about use "/node" to revert to Standard installation profile's default front page /node? Maybe we can add an info icon and help text to explain about everything: the default front page /user/login, which redirects to the user profile page for logged in users, and the /node page for Standard installation profile.

Is there any way to get the default front page value directly from system.site.yml?

Tagging "ux" to help us with this.

The scope of this issue is to improve the description text, which is currently confusing. I'm sure it is true that the underlying behaviour could be improved, but that would be a follow up issue that requires much more discussion.

To that end I have created a MR with the proposed change to the description.

Changes current text:
Optionally, specify a relative URL to display as the front page. Leave blank to display the default front page.

To:
Optionally, specify a relative URL to display as the front page. Leave blank to display the default front page, which is /user/login. For logged in users, this will redirect to the user profile page.

I agree, that's right.

The new description sounds good to me! It's clear enough about what the "default front page" actually is. +1

I also like it. Clear and precise. 👌🏻 +1

Updating screenshots for IS.

Adding before/after screenshots in the IS.

Removing typo.

Marking as RTBC if no one else disagrees.

Would it be better to just make this a required field, and not have a default? Allowing a blank default makes little sense, and it is set to /user/login by default in system.module and overridden to /node by the standard profile.

Interesting suggestion, I like it! Just wondering about the effect on existing sites? Do we need to include an update to set the value to /user/login if it is blank in an existing site? Would be a bit confusing to be forced to set this with no explanation when updating the site settings at some point in the future.

I don't think it can be blank on existing sites, because that is already handled as a special case in validation:

    // Check for empty front page path.
    if ($form_state->isValueEmpty('site_frontpage')) {
      // Set to default "user/login".
      $form_state->setValueForElement($form['front_page']['site_frontpage'], '/user/login');
    }

and this is undone in the form builder to get the (undocumented) default

    $front_page = $site_config->get('page.front') != '/user/login' ? $this->aliasManager->getAliasByPath($site_config->get('page.front')) : '';

Removing this magic default would mean we get to clean all this code up too.

If the front page is really set to an empty string, PathProcessorFront throws a 404:

      $path = $this->config->get('system.site')->get('page.front');
      if (empty($path)) {
        // We have to return a valid path but / won't be routable and config
        // might be broken so stop execution.
        throw new NotFoundHttpException();
      }

There is an outside chance this might be used on existing sites, but we shouldn't change that as part of this issue, so I don't think we need an update to any configuration here.

Marking needs work to try implementing #52.

I traced the history of this feature through several refactors all the way back to #806232: Site Information Improvements. Before this issue, the front page setting was required; this issue changed it so it was not required and /node was the default, but hidden as a blank value if the default was used. This has survived several refactors such as making node module no longer required.

I think that /user/login isn't a very helpful "magic" default any more - especially as it is already likely to have changed on most sites - and so we should undo this again, making the field required and the current value always show up. Also, a site must always have a front page, so making it a required field makes sense to me.

Probably interesting how this behaves in a minimal install. Will review later.

Okay, cool. Even before the patch, when you do a minimal profile install (that's the one where the "Default front page" form element was empty in the past) and when you export config, the system.site.yml has a value for the page.front key:

_core:
  default_config_hash: l58O_yEXSo-SeJi19LXdzTU1tNJG3lmnIhCitRkM1tk
langcode: en
uuid: 804840c9-87fc-4c4c-b54f-8e6160524953
name: 'Hello World'
mail: admin@example.com
slogan: ''
page:
  403: ''
  404: ''
  front: /user/login
admin_compact_mode: false
weight_select_max: 100
default_langcode: en

Now, with the patch applied on a minimal profile install the "Default front page" form element has /user/login in it and you can't empty it. You need to have a value set. Nice.

For the standard profile with the patch applied everything stays the same ("Default front page" containing /node same as the system.site.yml), except that you now can't empty it anymore. Nice.

I guess that's the moment where we might want to updated the issue title/description. And I would like to give props to @longwave for this really clever fix. 👏🏻

Retitled and updated the issue summary to reflect the new approach.

OK I double checked whether minimal specifies the default front page or relies on the default, and it relies on the default, and then I wondered how that was still /user/login, and it's because system.site.yml specifies user/login as the default. So we still have a default value, it's just required to set it explicitly in the form now.

So the experience of installing is the same, this is just cleaning up the form implementation, which is great.

Committed/pushed to 10.1.x, thanks!

We have a multisite multilingual project having the same issue while running core upgrade.

I found that system_post_update_enable_provider_database_driver() this update is causing the issue and its because of system.site.yml has been configured front page as '/user/login'. As we have more than 200+ site and 5 env, I have created a patch which indicate front page as 'home' and that resolved my issue.