Problem/Motivation

As discovered in #3493615: Front page always redirects to /home, if you set page.front directly in config, via drush or a recipe, the alias does not get stored as a system path. If you are using Redirect module, then visiting the home page results in a 301 redirect to the alias. The validation to convert the alias to the system path runs in the form submit, so this does not happen if you make the change outside of the form.

Steps to reproduce

  1. Install Drupal
  2. Create a node with the alias '/home'
  3. Using drush, run drush config-set system.site page.front '/home'
  4. Run drush config-get system.site page.front and see the value is '/home'
  5. Visit the site settings form and save the form with no changes
  6. Run drush config-get system.site page.front and see the value is '/node/{nid}'

Proposed resolution

Per #3493615-8: Front page always redirects to /home: Core should have a config listener that resolves aliases to system paths (where they exist) instead of the logic happening in the form.

Remaining tasks

  1. Create an MR with tests
  2. Review
  3. Commit

User interface changes

None

Introduced terminology

None

API changes

None

Data model changes

None

Release notes snippet

None

Comments

pameeela created an issue. See original summary.

pameeela’s picture

pameeela commented
Title: Updating page.front » Resolving page.front alias to system path only works if you set it via the form

Oops, didn't finish writing the title.

pameeela’s picture

pameeela commented
Issue summary: View changes
Related issues: +#3495421: RouteNormalizerRequestSubscriber redirects away from the front page when it's set to an alias
amateescu’s picture

amateescu commented
Related issues: +#1503146: Aliased paths cannot be set as front page
berdir’s picture

berdir
Primary language German
Location Switzerland
commented

Note: As commented in the Drupal CMS issue, there is the order of execution problem to consider. This is about a recipe setting config and I think also providing the default content. config is set first, so /home doesn't yet exist as an alias in that scenario and can't be resolved.

Also note that config save event happens after config has already been saved in \Drupal\Core\Config\Config::save. I'm not aware of a use case where we alter config in that event, usually we just trigger something else. This would need to resave that config again. Not sure if that's really a good idea.

pameeela’s picture

pameeela commented
Status: Active » Closed (won't fix)

This issue directly conflicts with #3495396: Resolving page.front alias to system path only works if you set it via the form which is trying to do away with this behaviour altogether. I'm going to close this since the other issue has much more activity, and we've got a workaround in Drupal CMS.