Aliased paths cannot be set as front page

See drupal_path_initialize(), it updates $_GET['q'] first.

It indeed does not and here is the bug.

Take a look at what happens:

function drupal_path_initialize() {
  // Ensure $_GET['q'] is set before calling drupal_normal_path(), to support
  // path caching with hook_url_inbound_alter().
  // $_GET['q'] --> string(0) "" 
  if (empty($_GET['q'])) {
    $_GET['q'] = variable_get('site_frontpage', 'node');
    // *** $_GET['q'] --> "home" ; It's the alias and that is OK
  }
  $_GET['q'] = drupal_get_normal_path($_GET['q']);
  // *** $_GET['q'] --> "node/2" ; returns back to source.
}

As you see, the output is 'node/2' not 'home'. first it set $_GET['q'] to variable_get('site_frontpage', 'node'); that's exactly what is checked by drupal_is_front(), but then it reverts back to the source by calling drupal_get_normal_path().

It's apparent the following code simply fails:

function drupal_is_front_page() {
  // Use the advanced drupal_static() pattern, since this is called very often.
  static $drupal_static_fast;
  if (!isset($drupal_static_fast)) {
    $drupal_static_fast['is_front_page'] = &drupal_static(__FUNCTION__);
  }
  $is_front_page = &$drupal_static_fast['is_front_page'];

  if (!isset($is_front_page)) {
    // As drupal_path_initialize updates $_GET['q'] with the 'site_frontpage' path,
    // we can check it against the 'site_frontpage' variable.
    $is_front_page = ($_GET['q'] == variable_get('site_frontpage', 'node'));
    // *** $_GET['q'] --> 'node/2', variable_get('site_frontpage', 'node') --> 'node/2'
  }

  return $is_front_page;
}

The only case I can think of that you might run into this is if the variable site_frontpage is manually set to a url alias, e.g. via "drush vset" or calling variable_set() directly.
When you submit the Site Info config page, any alias gets normalized, so that Drupal need not compare normal paths AND the aliases.

Please verify that your site_frontpage variable is a system path, and not an alias, by re-submitting the Site Info config page (admin/config/system/site-information). And please verify that you are not calling variable_set() to programatically set this variable to an alias.

Does this apply to D8 as well?

Use of $_GET['q'] was removed, I'm not sure that it is also broken?

Even if it isn't broken, it would be best to write tests to prove it.

Then the tests and a fix can be backported.

That's exactly the problem. The config page.
I have 'node/2' aliased as 'home'.
In Site Config page I set the homepage as 'home' and it accepts it. As you say it should normalize it (change it to 'node/2') but it does not.
It behaves exactly reverse; When I try to set homepage as 'node/2' it changes it back to 'home'!

The only way to get around this is to clear alias from 'node/2' and then set 'node/2' as homepage. So as you see this is a bug. I haven't set any variable manually, there is no custom module and I haven't use drush commands you told. It's a fairly fresh install and is happening to me in each project.
I think it worth to mention that I have two languages defined and the default language is not English in my projects.
And a list of contrib modules in two of my projects that have this problem:

addressfield    ckeditor            commerce_option              entity            job_scheduler  pathauto          views
admin_language  ckeditor_link       commerce_product_attributes  feeds             l10n_update    README.txt        views_field_view
auto_nodetitle  commerce            commerce_shipping            field_collection  menu_block     rules
backup_migrate  commerce_examples   ctools                       field_group       nodeblock      taxonomy_display
block_class     commerce_flat_rate  ds                           filefield_paths   panels         token

admin_language  ckeditor_link  entity             filefield_paths   link      README.txt       taxonomy_menu  xmlsitemap
backup_migrate  ctools         entityreference    google_analytics  metatag   registration     token
block_class     ds             field_group        insert            panels    rules            views
ckeditor        elements       field_permissions  l10n_update       pathauto  select_or_other  webform

Can you reproduce on a clean install?

I could not able to reproduce this on fresh installation
I have installed a fresh drupal 8.
I have 'node/2' aliased as 'home'
In Site Config page I set the homepage as 'node/2'.
then I print $variables in preprocess function. it print
[is_front] => 1
After that
In Site Config page I set homepage as 'home' and save it.
Then I print $variables it print
[is_front] => 1

Either you set homepage as node/nid (node/2) or its aliased (home) it returns true.

Are you still this is in the case in an up to date Drupal 8?

I noticed this glitchy behavior too, in D7.

I have a custom Context plugin reaction changing the site_frontpage in this manner:

$frontpage = $context->reactions[$this->plugin]['site_frontpage'];
$_GET['q'] = drupal_get_normal_path($frontpage);

When I set the contextual front page through this to 'node/7' in the UI, visiting the root of the website (clicking the logo) renders as 'front'

But visiting that page directly does NOT - it renders as 'not-front'

However when I save the contextual front page in the UI as 'my-custom-path/my-page' (the alias for that same node), neither the clicking the logo nor visiting the page directly by it's alias or system path result in the page rendering as 'front' (it's rendered as not-front).

In both cases visiting the page set as front page globally in Site Information also renders as 'front' - which is more likely a problem with this custom plugin.

So something's up with how D7 is reacting to system paths vs. aliases in the front_page value.

Can't speak to Drupal 8, sorry.

Let's move it to d7 then.

I can't reproduce this in either Drupal 7 or 8.

If you look at:

https://api.drupal.org/api/drupal/modules!system!system.admin.inc/functi...
https://api.drupal.org/api/drupal/modules!system!system.admin.inc/functi...
(Drupal 7)

or:

https://api.drupal.org/api/drupal/core!modules!system!src!Form!SiteInfor...
https://api.drupal.org/api/drupal/core!modules!system!src!Form!SiteInfor...
(Drupal 8)

You can see that when the form is displayed to the administrator, the path alias (e.g. "home") with always be shown as the default value of the field, but when it is saved, the actual system path (e.g. "node/2") will be saved. Thus what is noted in #5 → :

That's exactly the problem. The config page.
I have 'node/2' aliased as 'home'.
In Site Config page I set the homepage as 'home' and it accepts it. As you say it should normalize it (change it to 'node/2') but it does not.
It behaves exactly reverse; When I try to set homepage as 'node/2' it changes it back to 'home'!

is expected behavior and does not indicate a bug. Since the system path is always saved, everything should work as intended.

Can anyone reproduce this without custom code, or otherwise explain what the bug is (in either Drupal 7 or 8)?

I don't think it is a bug. The problem is the expected behaviour must be updated as frontpage can be set in several ways directly to the variable site_frontpage (Features, drush, settings.php, etc.) and not passing from the form.

The solution above is suggesting to move the alias-to-internal translation step from the administrative form to the drupal_is_frontpage() function, and so from a mapping approach on saving the form to an universally checking one on loading the page.

Then whatever is the site_frontpage value - alias or internal - the drupal_is_front_page will always return correctly.

EDIT/UPDATE: I've carefully read all the comments and I can see someone is tripping over some unclear bugs. I can't reproduce them on 7.x, haven't tried on 8.x but linked code is clear. The only issue I see here is still the one on the description of the issue related to drupal_is_frontpage_code(). Other core modules check both internal and alias paths on evaluating a page (i.e. block module on block_block_list_alter() when matching request path against $block-pages).

I've run into this issue, too. For whatever reason, some of my sites have the site_frontpage variable stored as the alias to the front page node, in my case 'home'. I don't know if this is from an older version of drupal that allowed this or something. Either way, wouldn't it be safe to change the code in drupal_is_front_page to

$is_front_page = ($_GET['q'] == drupal_get_normal_path(variable_get('site_frontpage', 'node')));

since drupal_get_normal_path() will return the node path regardless of which path is passed to it?

When looking at the drupal_is_front_page function you see it performs a check on

($_GET['q'] == variable_get('site_frontpage', 'node'));

So it only returns true if there is an exact match.

You can recreate the function and use something this instead, to check if the frontpage url is a part of the request url:

(strpos($_GET['q'], variable_get('site_frontpage', 'node')) !== false)

All other code in drupal_is_front_page is for static caching. You want to copy that if you intend to call this function often. If it is for one check you can do with this simple function:

function drupal_is_front_page2() {
$is_front_page = (strpos($_GET['q'], variable_get('site_frontpage', 'node')) !== false);
return $is_front_page;
}

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now 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 → .

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now 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 → .

#15 I don't understand your solution.

to check if the frontpage url is a part of the request url

An URL beginning (or ending) with the frontpage path is totally unrelated to this issue.

The issue is about drupal returning FALSE on either D7 and D8 on checking if path is frontpage, when the site frontpage setting (system.site.page.front/site_frontpage) is an alias.

To reproduce in D8:

1. Pick up a node and add its alias to the Basic site settings Default front page i.e. /foo/bar
2. Getting system.site.page.front returns the internal path /node/123, while Basic site settings Default front page shows its alias
3. Go to the page and drupal correctly recognises the page as front page i.e. it has the body class "path-frontpage"
4. drush cset syste.site page.front /foo/bar, use same alias as step 1
5. re-do step 2 and drupal doesn't recognise the page as front page i.e. the body class path-frontpage is missing

Step to reproduce in D7 are similar, just use drush vset site_frontpage and paths don't start with "/".

Proposed solution:

• D8: use \Drupal::service('path.alias_manager')->getPathByAlias($path); on PathMatcher::isFrontPage() for matching with system.site.page.front
• D7: use drupal_get_normal_path(variable_get('site_frontpage', 'node'))); on drupal_is_front_page()

EDIT/UPDATE: I've removed the "Bug" type as I don't think is a bug, but it's not clear if system.site.page.front MUST be an internal path or it can be anything. The form itself is misleading (you add an alias, it stores its internal path but still show the alias on the form field after submission) and even if we make it clear it's easy for the developer to forget it must be internal, store an alias and break the website.
Feel free to restore "Bug".
Besides I'm thinking internal path can change - for instance between different environments - while alias can stay the same - you create a node with the same title/alias -, so I can see why a developer want to store the front page url using alias and not internal path. I'm more keen to restore the "bug" type... thoughts?

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now 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 → .

I was able to reproduce this bug on D8.4.5, here is how:

• I had a page with alias /home and Default front page under /admin/config/system/site-information was already pointed to /home
• I edited this node and change its alias to /home-old, then create a new node (different content type) and use the /home alias for it
• Clicking on the site logo was in fact redirecting to the new home page, but \Drupal::service('path.matcher')->isFrontPage() was returning false
• I went back to Default front page and change /home for /node/xxx, after clicking "Save configuration" the value automatically changed to /home again
• Visiting the home page was still giving the same results (not front page).
• Went back to Default front page, delete the value (left empty) and saved the form
• Add /node/xxx again, and again it changed to /home automatically after saved
• At this point when I visited the home page \Drupal::service('path.matcher')->isFrontPage() was returning true.

I hope this helps to find out what is wrong.

I guess that the basic site settings form should not alias the url, it brings a lot of confusion as it is now.

See closed duplicate issue: #2958253: When exporting configuration site frontpage converts to node/id →

In SiteInformationForm.php, see:

$front_page = $site_config->get('page.front') != '/user/login' ? $this->aliasManager->getAliasByPath($site_config->get('page.front')) : '';
$form['front_page']['site_frontpage'] = [
  '#type' => 'textfield',
  '#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(),
];

At the minimum the aliasing part should be removed to stop confusion with this screen. I don't see the point to alias the internal path. Was there a reason?

If it's really wanted to show the language-aware aliased url of the targeted content/page, it could be added below the field in the description area. Knowing than a frontpage is mostly pointing directly to <front> (plus when a module like redirect is enabled with the option "Enforce clean and canonical URLs." checked).

If the possibility to use an alias for the frontpage settings is done, it will brings some problematics to be aware with the multilingual case too:

- make the frontpage field translatable (to be able to manage a different alias for each language) :

EN > /home
FR > /home-fr or /accueil

- how to manage a case where the frontpage will be set on different kind of entities/object ?

EN (default) : / => node/2 
FR : /fr => node/3
ES : /es => view/4
BE : /be => webform/5

>> maybe on the saving, just forbidding it when an alias is filled but don't target the same internal path than on the default frontpage setting? Or should it be just ok to allow that?

And the \Drupal::service('path.matcher')->getFrontPagePath() should then returned the internal path it the path is aliased via a getPathByAlias().

By the way, currently, if you really need to set a different frontpage following your environments, you should take a look to config_split and/or config_ignore modules.

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule → and the Allowed changes during the Drupal 8 and 9 release cycles → .

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule → and the Allowed changes during the Drupal 8 release cycle → .

One way the page.front variable can be set to the alias rather than the internal path is when the configuration is being set in concert with default content, as in an installation profile or a feature (ran into this with the Drutopia → distribution).

It's such a bizarre bug i think Drupal core does need to do more to process incoming front page configuration, no matter what its source, or to flag an alias as an issue on the status report dashboard or something.

Drupal 8.9.0-beta1 → was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now 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 → .

My issue is related to redirect from domain.com to domain.com/home. Which is happening due to $this->pathMatcher->isFrontPage() in src/EventSubscriber/RouteNormalizerRequestSubscriber.php returns false on frontpage.

Steps to reproduce.

1. Install Drupal & redirect module.
2. Create node with url alias "home" & set default home page to "home" admin/config/system/site-information
3. Export config using drush cex
4. front: /node/1 in system.site.yml
5. Go to homepage domain.com it stays on domain.com
6. Change front: /home in system.site.yml & run drush cim
7. Go to homepage domain.com it redirects to domain.com/home

Its more of core bug which fails to detect frontpage with above steps hence redirect module fails for me.

Hello.
I face off this issue on one of my d8 websites. Usually I don't set a specific as FP, and I use a FP template to display content.
On 894 then on 895, FP don't detect varaible and display login page instead.
Details are there: https://www.drupal.org/project/drupal/issues/3170184 →

Drupal 9.3.0-rc1 → was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule → and the Allowed changes during the Drupal core release cycle → .

Drupal 9.2.0-alpha1 → will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule → and the Allowed changes during the Drupal core release cycle → .

Drupal 9.1.0-alpha1 → will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule → and the Allowed changes during the Drupal 9 release cycle → .

Long time has passed and this issue now requires IS updates either to reflect changes required and properly scope out solutions based on 9.x OR focusing this issue to D7 and moving D9 work somewhere else ( #3170184: Homepage replaced by login page, why ? → maybe?).

Checking both the internal path and the normal path in PathMatcher::isFrontPage seems to do the trick. Haven't added any tests yet.

I added a patch of the current state of the MR for easy inclusion in projects.

Setting to NW for, at least, the issue summary update. A title change is needed as well because drupal_is_front_page was removed in #2388629: remove drupal_is_front_page(). → .

I changed the title and issue summary. Feedback on my proposed fix is welcome.

I updated the form to stop automatically resolving aliases to paths. I added a patch of the current state of the MR for easy inclusion in projects.

I noticed this approach doesn't work when using language path prefixes. I experimented a little bit, but I don't think we can do this without a dependency on the path_alias module. A couple ideas:

• a new hook, something like hook_front_page_alter, with an implementation in the path_alias module
• A PathMatcher service override in the path_alias module

I went with the PathMatcher service override in the path_alias module, seems to work great.

Fixed CS errors.

@ranjith_kumar_k_u development is happening in the MR, only posting the patches for use with composer-patches.

The last submitted patch, 42: 1503146-42.patch, failed testing. View results →

In this commit:

• Include CS fixes from #42
• Addressing testing failure from #42
• Changing visibility to PathMatcher::checkFrontPage(). As this is not in the interface, it shouldn't really be public. So changing it to protected. If needs to be public, then we better add it to PathMatcherInterface too.

This still needs test.

Before checking those failures, here a test-only patch. setting it for Needs Review just to trigger the testbot. This is Needs Work.

Oops. Needs Review, for the testbot.

I'm not sure I understand correctly this bit of the IS:

causing the front page path to not redirect to the root path if an aliased path is used. Internal paths like /node/1 work fine.

With Standard profile, if I visit a /node/1 path configured as front page there is no redirect. Neither with the system path /node/1, nor with an alias. Anyone has got different behaviors? If I'm right, do we need an IS update?

No, that's not what I meant:

• With /node/1 as front page, visiting / does not redirect
• With /homepage (path alias) as front page, visiting / redirects to /homepage

@DieterHolvoet it doesn't on Standard profile?

With standard:

1. Create a Basic Page
2. add an alias
3. in Basit Site Settings, configure the alias as front page
4. visit /

The site settings form automatically transforms the alias to the node path, can you check the form again to make sure that didn't happen? Because now the node ID is stored in config, and that's exactly what I'm trying to prevent from happening.

If I understand correctly the issue you are describing, then no. The alias is not changed into the node path in the Basic site settings form.

Not in the form because it's automatically being converted to the path alias, but did you check the actual system.site config?

% ddev drush cget system.site
_core:
  default_config_hash: VDJxTZtQR21qB4lvOq8zszJZLvLKrSPQpdn2E3T71Ww
langcode: en
uuid: 6db72c80-119d-4beb-9b22-f0c310f1e3df
name: 'Drush Site-Install'
mail: admin@example.com
slogan: ''
page:
  403: ''
  404: ''
  front: /ciao-mamma
admin_compact_mode: false
weight_select_max: 100
default_langcode: en

Putting in the form /node/1 converts it to its alias /ciao-mamma.

I'm tempted to close this as "cannot reproduce". The issue doesn't seem to happen anymore, at least in 9.4.x.
The steps to reproduce don't trigger the issue.

The behavior either you use the system path or an alias is exactly the same, as exception of the scenario where you set a system path through the form which is replaced with its alias if one exists.

Feel free to re-open, showing exactly what the issue is and how to reproduce it.

Thanks everyone!

The steps to reproduce do trigger the issue. I set up a site for demonstration purposes: https://master-ypsdica8tvhdqv2vcikdh68sjrl2mniq.tugboat.qa/ (login admin, password admin)

I changed the front page to a node alias: https://master-ypsdica8tvhdqv2vcikdh68sjrl2mniq.tugboat.qa/en/admin/conf...

When trying to export the system.site config, you'll see page.front is set to /node/11: https://master-ypsdica8tvhdqv2vcikdh68sjrl2mniq.tugboat.qa/en/admin/conf...

@DieterHolvoet yeah, you are right. Probably I was running on top of the 1503146-drupalisfrontpage-does-not branch.

So, on Basic Settings form:

• on 9.4.x: when setting /page-alias (or its /node/ID), system.site page.front is /node/ID
• on this issue branch: when setting /page-alias (or its /node/ID), system.site page.front is /page-alias

This patch address this issue, which mainly focus on decoupling the config from the content. Using an alias rather than an internal content path in config is preferable. 👍

RE url redirects:

• on 9.4.x: when setting /page-alias as frontpage, visiting /page-alias does not redirect to /
• on 9.4.x: when setting /page-alias as frontpage, visiting /node/ID does not redirect to /
• on 9.4.x: when setting /node-ID as frontpage (page WITHOUT an alias), visiting /node/ID does not redirect to /

So my understanding is yes, there is an issue with the form, but not with URL redirects? In this case we still need to update the IS and remove all mentions to "redirect" since are misleading.

Adding Needs Issue Summary Updates due notes on #58, still pending confirmation if anyone can test my assumptions?
Also keeping Needs Tests since the tests I posted #46 don't focus on system.site page.front changes we are trying to achieve.

Drupal 9.4.0-alpha1 → was released on May 6, 2022, which means new developments and disruptive changes should now 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 → .

Fixed an issue when there's no active route match.

Drupal 9.5.0-beta2 → and Drupal 10.0.0-beta2 → were released on September 29, 2022, which means new developments and disruptive changes should now 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 → .

Sending back to NW. Patch #60 appears to be failing tests. ANd it needs tests of its own.

I took the code from the merge request, rebased it against 10.1.x and added a fix for a unnecesary named argument but now I can't edit the MR to be against 10.1.x. Should a new MR be opened?

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, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule → and the Allowed changes during the Drupal core release cycle → .

Only the person who opened the MR can edit it. I just did.

The merge request rerolled as SiteInformationForm.php had a conflict.

Going to work on the test failures.

Looking at the test failures, it seems like the failures in both TaxonomyDefaultArgumentTest and DisplayPageTest could be fixed by adding path_alias to the test's modules list. I'll test this locally first.

I made a few additional changes and was able to get the tests to pass locally. Whether we want to make these changes to the tests is another question.

The last submitted patch, 69: drupal-n1503146-69.patch, failed testing. View results →

The last submitted patch, 72: drupal-n1503146-72.patch, failed testing. View results →

That's weird - InstallerExistingConfigSyncDirectoryMultilingualTest passes locally, and didn't fail on previous test runs, e.g. https://www.drupal.org/pift-ci-job/2673595 → from #69.

Anyways, next off we need test coverage.

neclimdul → changed the visibility of the branch 11.x to hidden.

neclimdul → changed the visibility of the branch 11.x to hidden.

neclimdul → changed the visibility of the branch 11.x to hidden.

sorry for the noise. Forcing a 11.x branch to the issue fork to work around a bug in the core gitlab config.

The patch seems to be working great. Note about how we can make it better in the review.

#72 works nicely for me!

Just one note: The config page needs to be visited in the language of the content that the aliases content is in. E.g. I have path prefix enabled, if I visit /en/admin/config/system/site-information and I insert /start which is alias of a content on de, than the form throws a validation error: Either the path '/start' is invalid or you do not have access to it.

Oof. So the alias validation is tied to the site language in the admin interface? That sounds complicated.

Note that the current MR will disable core's alias pre-loading optimization, see #2508217-14: AliasManager should use the current route match for outbound alias pre-loading cache keys → for details.