Move is_front variable to template_preprocess_page()

Good catch!

RTBC, makes a lot of sense, we need to be more careful about this now.

+++ b/core/includes/theme.inc
@@ -1773,6 +1762,16 @@ function template_preprocess_page(&$variables) {
+  // drupal_is_front_page() might throw an exception.
...
+    $variables['is_front'] = drupal_is_front_page();

It should be \Drupal::service('path.matcher')->isFrontPage() now.

Thank you for the fix.

We need a change record for this.

Small nit...

+++ b/core/includes/theme.inc
@@ -1773,6 +1762,16 @@ function template_preprocess_page(&$variables) {
+    $variables['is_front'] = Drupal::service('path.matcher')->isFrontPage();

Should be \Drupal::service() right?

Change draft added. Am I correct in thinking that because this is in template_preprocess_page now instead of template_preprocess that the variable isn't accessible everywhere now, by default?

That is correct, but needed else every cache item is potentially 'PER_PAGE' suddenly ...

Just modifying some comments.

Otherwise, I'm fine with the change. I played with it some and it seems to work fine for page templates. On the negative side, this reduces the availability of the variable, but the performance improvement outweighs that concern. Any module/theme depending on the variable is easily fixed by checking for the front page directly.

While searching I noticed there are still a number of references to drupal_is_front_page(). Since that function is deprecated now, shouldn't those be changed? (out of scope for this issue) I didn't see an issue for it.

Forgot to upload the patches.

Looks good to me

This issue addresses a major bug and is allowed per https://www.drupal.org/core/beta-changes. Committed 90a26b4 and pushed to 8.0.x. Thanks!

Any module/theme depending on the variable is easily fixed by checking for the front page directly.

Yes, but as soon as they do that, they will need to ensure that the cache granularity of all objects on that page has the CACHE_PER_PAGE cache context.

Fabianx, how do you do that? I want to add that information to the change record, but I'm not finding documentation for it or an implementation to use as an example.

I honestly don't know how to do that.

I only know that core is setting #pre_render and #cache keys and that that contains cache contexts.

Wim: ^^
Nat: ^^

I am currently trying to figure out a good way to check for front page in a template other than page.html.twig.

Going to preprocess functions for each template that is needed?

I also tried to make a custom Twig Extension that checks with \Drupal::service('path.matcher')->isFrontPage(); for the front page but this is not working, probably due to caching.

Is there still an easy way to check for frontpage like in D7?

Would be great if someone can give me a hint.

#22:

So whenever you check the front page you will also need to add a cache context so that the caching layer knows that your block or entity or whatever is encompassed is varied by 'route'.

However per route would be a lot of granularities.

Therefore dawehner proposed that in your contrib twig extension you also register a new cache context:

route.is_front

which just returns two states: TRUE if its the front-page or FALSE otherwise.

Your code in the extension would then need to add the cache context and the easiest is to just render a render array with that, like:

$build = [];
$build['#cache']['contexts'][] = 'route.is_front';
\Drupal::service('renderer')->render($build);

And thats it.