Problem/Motivation

When installing with the standard profile the front page is set to node. On all other profiles (including testing and minimal), the front page is set to user (#375397-91: Make Node module optional) and recently to user/login. However, the login page behaves different for authenticated users and that leads to tests being forced to implement workarounds (e.g. \Drupal\system\Tests\System\AdminTest::testCompactMode()).

Also when installing with the minimal profile, the frontpage shows the login-form as well as the login-block in the sidebar.

In addition, this will help with test-failures over in #2288911: Use route name instead of system path in user maintenance mode subscriber.

Proposed resolution

Introduce a default system frontpage (on system/frontpage) showing the simple message No front page has been configured yet.

Remaining tasks

User interface changes

Front page is set to system/frontpage unless changed by the install profile. This only affects testing and minimal profile, standerd profile already sets the frontpage to node.

It has been pointed out on other occasions (#375397-123: Make Node module optional), that its the job of the installation profile to set the frontpage to a sensible value. Therefore third-party install profiles are not expected to be affected by this change.

API changes

CommentFileSizeAuthor
#14 2364643-system-frontpage-14.diff18.29 KBznerol
#12 2364643-system-frontpage-12.diff18.28 KBznerol
#6 interdiff.txt3.83 KBznerol
#6 2364643-system-frontpage-6.diff18.36 KBznerol
#4 interdiff.txt7.54 KBznerol
#4 2364643-system-frontpage-4.diff14.53 KBznerol
#1 2364643-system-frontpage.diff7.73 KBznerol
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

znerol’s picture

znerol CreditAttribution: znerol commented
Issue summary: View changes
Status: Needs work » Needs review
FileSize
2364643-system-frontpage.diff7.73 KB

Status: Needs review » Needs work

The last submitted patch, 1: 2364643-system-frontpage.diff, failed testing.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented 
+++ b/core/modules/system/src/Controller/DefaultFrontpageController.php
@@ -0,0 +1,41 @@
+    return array(
+      '#markup' => $this->t('No front page has been configured yet.'),
+    );

I thinkwe should we should link to the frontpage configure page, in case the user has the permission to do so.

znerol’s picture

znerol CreditAttribution: znerol commented
Status: Needs work » Needs review
FileSize
2364643-system-frontpage-4.diff14.53 KB
interdiff.txt7.54 KB

we should link to the frontpage configure page, in case the user has the permission to do so.

Done. Also fixed the installer tests.

Status: Needs review » Needs work

The last submitted patch, 4: 2364643-system-frontpage-4.diff, failed testing.

znerol’s picture

znerol CreditAttribution: znerol commented
Status: Needs work » Needs review
FileSize
2364643-system-frontpage-6.diff18.36 KB
interdiff.txt3.83 KB

Fix remaining tests:

  • LanguageSwitchingTest::doTestLanguageBlockAuthenticated() assumed that we are redirected to the user profile when accessing the front page with an authenticated user.
  • ContentNegotiationTest::testBogusAcceptHeader() assumed a login-form and did not even care to check the HTTP response code.
dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented
Status: Needs review » Reviewed & tested by the community

I really like the general idea to not have a special route like user/login or nodeby default.

On top of that the message is kinda similar to the other normal frontpage already.

Dries’s picture

Dries CreditAttribution: Dries commented
Version: 8.0.x-dev » 8.1.x-dev
Priority: Major » Normal
Status: Reviewed & tested by the community » Postponed

This patch makes sense to me; it actually makes for a nice little usability improvement. Looking at https://www.drupal.org/node/1397862 and #375397: Make Node module optional, changing it to "/user" was just an an easy/reliable thing to do.

However, I don't think this is "major" so I'm making it "normal". Evaluating it in terms of #2350615: [policy, no patch] What changes can be accepted during the Drupal 8 beta phase?, it does not improve performance, security, performance, etc., nor fix an actual bug. However, there is a case to be made that this is a small usability improvement, and it also improves testability. So in this case the question we should ask ourselves is whether the impact of this change is greater than the disruption it introduces. (See: https://www.drupal.org/node/2350615#disruption) To me, it does not seem that the impact of this issue merits the disruption. So, I am postponing this issue. If you disagree, please update the issue summary and set it back to needs review.

znerol’s picture

znerol CreditAttribution: znerol commented
Version: 8.1.x-dev » 8.0.x-dev
Issue summary: View changes
Status: Postponed » Needs review

It is necessary for #2288911: Use route name instead of system path in user maintenance mode subscriber, therefore should have the same priority. Because the other issue removes instances of the _system_path request attribute, I think this should be included in 8.0.x. Updated user interface changes section of issue summary.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented

Thank you znerol to stay strong!

ITs a good point that this is required for a major issue, but there is more.
This also removes the amount of brittleness and based upon that reduces the maintenance cost of the longrun.

For example its just ridiculous that system module configuration relies on user module being installed.
So for example in case we would do proper config validation installing system module in the installer should fail, because system.module
does not require user module.

To me, it does not seem that the impact of this issue merits the disruption

Which disruption does that cause? No custom site updating their config would have to change anything, because config is never load out of
the module folder, but there is just all the active config.

znerol’s picture

znerol CreditAttribution: znerol commented
Status: Needs review » Needs work
Issue tags: +Needs reroll
znerol’s picture

znerol CreditAttribution: znerol commented
Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
2364643-system-frontpage-12.diff18.28 KB
znerol’s picture

znerol CreditAttribution: znerol commented

We need this to #2371629: [meta] Finalize Session and User Authentication API.

znerol’s picture

znerol CreditAttribution: znerol commented
FileSize
2364643-system-frontpage-14.diff18.29 KB

Reroll after #2354597: Remove usage of form_set_value()..

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented
Status: Needs review » Reviewed & tested by the community

Code looks good. I think the benefits have been explained and the disruption is non-existent.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented

+1

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented
Status: Reviewed & tested by the community » Needs work 
+++ b/core/modules/system/system.routing.yml
@@ -410,6 +410,14 @@ system.timezone:
+  path: '/system/frontpage'

We need to prevent access to this page once the frontpage has been set to something esle.

effulgentsia’s picture

effulgentsia CreditAttribution: effulgentsia commented

While I like this patch, I think it should be re-postponed to 8.1.x, because I don't agree with #9 or #10.

It is necessary for #2288911: Use route name instead of system path in user maintenance mode subscriber

I posted a patch in #2288911-58: Use route name instead of system path in user maintenance mode subscriber to move that issue along without this one.

For example its just ridiculous that system module configuration relies on user module being installed.

user.info.yml lists user module as required. So while the coupling isn't clean, it doesn't create any real problems AFAICT.

znerol’s picture

znerol CreditAttribution: znerol commented

Thanks @effulgentsia. I will postpone this as soon as #2288911: Use route name instead of system path in user maintenance mode subscriber gets committed.

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.

raphaeltbm’s picture

raphaeltbm CreditAttribution: raphaeltbm commented
Related issues: +#1503146: Aliased paths cannot be set as front page

I guess this issue is related in some ways.

My own last comment #1503146-21: Aliased paths cannot be set as front page.

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.

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

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.