Rename 'page' render element to 'body', page.html.twig to body.html.twig

Initial stub on rename - renamed element. let's see test coverage

Suppose we can easily rename element in beta because this code introduced in 8.x
Renames of templates is tricky, maybe we can provide BC shim for old ones and "assert" some message to user that used theme has "deprecated templates" somehow

Hm i guess there is a need for renaming all the theme_preprocess_page hooks as well. Actually the body content is the page content. You won't find anything really necessary in that can be rendered in your browser.

For history reasons i'd not suggest to change that.

Should fix a lot of tests

This needs a beta evaluation to get in now. If it does not, this is such a BC break that it will have to wait for Drupal 9.

Unless there is a backwards-compatible way to do this.

Fix more tests and clean-up comments

About BC - I'm pretty sure that element type should be "body" so maybe better to split the issue into rename type and rename templates (suppose here a lot of bikeshed)

@Wim yep, that's why I said about split

@Wim I see no BC for #3 otoh that's not a hook so looks fine. so no idea how to fit in beta and 8.x

Templates are not frozen so I think this should be acceptable. And changing element might not have to be considered as a API change.

+1 to this because of the page.html.twig has been very confusing always.

Even though I'm +1 to this, I talked quickly with Lewis and few ideas/problems bumped in:

• Body might be confusing between body field
• Calling #type => 'body' might be a little confusing, how ever its being called in very rare circumstances
• Might be worth investigating what other CMSs and frameworks are doing if there is something which makes more sense

Anyway this makes sense since html.html.twig is creating the html element and body.html.twig would be creating the body element.

I do not agree. We are way too late in the process to rename the page template. That is a huge change.

It is a drupalism we've been stuck with for a long time, and I'd like to change it as much as anyone else, but not weeks before RC.

What advantage would there be to renaming it internally, if the template isn't changed. That sounds like an inconsistency we can do without.

I prefer body over html_body. I think body is still something we can use if we don't come up with a better name.

@davidhernandez: it should be easy to adopt for the new name of the template. It means in most of the cases only renaming the template.

There is more to this than simply renaming a template. It is an entire conceptual change. People have become accustom to the existence of the page template. The documentation, tutorials, books, etc, all reference it. Changing it pre-beta or early beta when some features were still being worked out would have been fine, but doing it now without a lot of discussion or fanfare could be very confusing.

It depends on your point of view. For all intents and purposes the body tag is the whole page, for someone concerned with content or theming. There have been many discussions in different issues about how the whole html/page combo needs to be completely redone, but we've been too far into development to do it.

My concern is simply disruption versus benefit. This will be disruptive, so the benefits need to be clear. Are we gaining more than just renaming something? Does this resolve any internal conflict, or benefit a particular use case?

if we wanna do anything on the page issue -then it should not be to rename page.html.twig to body.html.twig but instead merge page.html.twig & html.html.twig to remove that exatra template that dont gives us any benefits (and those can be fixed with a twig block)

I have a hard time seeing a win by renaming page to body at this point, yes its a drupalism but calling it body would also suggest that its where the body tag gets rendered ... and then html.html.twig makes even less sense.

calling it body would also suggest that its where the body tag gets rendered

Yeah, that's a good point regarding more confusion. The tag it seems to reference isn't even in there.

I think body sounds fine. That being said, I think most Drupal themers will get it. The real question is if it's going to make sense to non-drupal frontenders

page exists just because we use 4 hooks but all of them are for HTML template (build and rendered here)
https://api.drupal.org/api/drupal/8/search/hook_page_
hook_page_top()
hook_page_bottom()

hook_page_attachments() and hook_page_attachments_alter()

Also maintenance and install pages re-use this but there's separate issue #2231853: Rename maintenance-page template into page--maintenance + install-page into page--maintenance--install

Another suggestion is "layout" for element name - looks the exactly what it is

I think the HTML tag is sticking as close to frontender knowledge as you can get. Having said that, I see layout a lot in static site generators like Jekyll, Middleman and other tools like Squarespace

@LewisNyman the last 2 examples use actually the same naming - layout that contains regions

Also "render element" for our page contains of "page" variable that contains regions, that's why I suggest to use layout

  foreach (\Drupal::theme()->getActiveTheme()->getRegions() as $region) {
    if (!isset($variables['page'][$region])) {
      $variables['page'][$region] = array();
    }
  }

Can we still make that change?

I would also question the lateness of such a change; however, it is something many of us have wanted to do. Whenever it was previous brought up, I believe the reason not to do had to do with caching, but I don't remember the specifics.

I'd honestly prefer effort put into that than arguing over renaming page. The split is the bigger WTF. For example, all of the page level CSS classes get printed in html.html.twig because that is where the body tag is. We are also doing a lot of work right now to remove most of the variables in the page templates, so the code there will get a lot smaller. Merging them wouldn't make the result unreadable at all.

Will try to attack that, I see the best to merge hook__preprocess_page() into hook__preprocess_html()

Most of them are slim so disruption is not big

I think it would be a good idea to get sign off from both theme system maintainers and core committers before putting too much effort into it. I can easily see the committers saying, "This isn't critical, so why are we doing this now?" And if they don't think it is a good idea at this stage, it has to be pushed back to 9.x. We can't touch the templates in a point release.

Is there justification besides TX/DX? Can we get a performance boost merging them?

not so much left to convert

Looks the issue is a duplicate of #2090967: Extend page.html.twig with html.html.twig
The issue above pushed to 9.x, but now most of reasons are resolved so maybe better to proceed there?

Worth trying a bc layer + deprecation.

Not really sure about this merge or rename.

How will this work with layouts? ATM {{ page }} is dead easy to take over and control, not so easy if this is all one big template, not a DRY approach repeating head etc for the sake of a layout.

Actually renaming this to layout is not a bad idea also, but personally I have not noticed a whole lot of confusion with regards to page.html.twig naming. None actually.

The effort I would like to see, personally, is to get rid of page.html.twig entirely and just have a notion of layout plugins, like Panels in core sort of thing.

@Jeff Burnz don't worry the merging thing was hashed out in #2090967: Extend page.html.twig with html.html.twig, this is only about renaming (only about what's in the issue summary).