This is a followup issue to http://drupal.org/node/469242 as that issue was already 2 pages long.

Comments

mcrittenden’s picture

mcrittenden CreditAttribution: mcrittenden commented

Sub. Webchick just moved #522006: Conditional Styles in .info files, since drupal_add_css has it back to D8 so we'll need to document the correct way to add conditional styles in this new system, which will most likely involve overriding html.tpl.php, correct?

alexanderpas’s picture

alexanderpas CreditAttribution: alexanderpas commented

Adding them during the preprocess stage is another method. (template.php)
for example, garland does it like this:

function garland_process_html(&$vars) {
  [...]
  $vars['styles'] .= "\n<!--[if lt IE 7]>\n" . garland_get_ie_styles() . "<![endif]-->\n";
}

function garland_get_ie_styles() {
  global $language;

  $ie_styles = '<link type="text/css" rel="stylesheet" media="all" href="' . file_create_url(path_to_theme() . '/fix-ie.css') . '" />' . "\n";
  if ($language->direction == LANGUAGE_RTL) {
    $ie_styles .= '      <style type="text/css" media="all">@import "' . file_create_url(path_to_theme() . '/fix-ie-rtl.css') . '";</style>' . "\n";
  }

  return $ie_styles;
}
alexanderpas’s picture

alexanderpas CreditAttribution: alexanderpas commented

nice usecase from a themer here:

how could I add a class to the <body> only when there is $tabs in the page ?

documenting this is important (and ofcourse knowing how too ;) i guess it's another case of template_preprocess_html())

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

thanks for reposting this here alexanderpas.

Another very similar user case scenario, I want a body class "with-primary" and "with-secondary" if main menu or secondary menu are displayed in the page. It actually comes from using the ZEN layout technic, that is used also in Basic. As the primary links are loaded after the content, you need to add margin to the top of the content, but if there is no menu, to remove the margins.
As I mentioned in the other thread : "I know you could wrap your content into an extra <div> with the page classes, but what if I actually don't want to, because I don't want to add markup where I don't need to ? It feels like Drupal would force me to have extra markup, and IMHO, this is not a good thing."

NaheemSays’s picture

NaheemSays CreditAttribution: NaheemSays commented

@couzinhub - two things:

1. From what I understand, the two new regions of page_top and page_bottom are supposed to be full browser width, so if the body tag has something limiting it's width, the blocks in them regions will need to make sure they have additional markup to make sure (but they generally will have that markup anyway)

2. You are still allowed to edit html.tpl.php, so if you don't want to have extra markup you don't need to.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

@nbz

1 - not sure why you mention the regions width here, I didn't say anything related to this (?). I was only taking a css example that would require margins on specific conditions.

2 - Of course I can, but how do I use a page.tpl.php variable into html.tpl.php ? That's my real question. If possible, we should document how to do this.

Another example if you prefer, let's say I want the <body> to have a class="with-footer" when there is a block in the footer region. Before I could just add a condition in theme_preprocess_page :

  if (!empty($vars['footer']) {
    $body_classes[] = 'with-footer';
  }

But now, I can't access the footer within theme_preprocess_html as it is in theme_preprocess_page... so I can put a conditionnal class to the <body> and I have to apply it in an extra wrapper in page.tpl.php.

SO basically, something very easy to do in D6 like adding body classes becomes impossible to do in D7... when so much have been done in order to make it more easy and flexible.

Any solution ?

alexanderpas’s picture

alexanderpas CreditAttribution: alexanderpas commented

according to http://api.drupal.org/api/function/template_preprocess_html/7 this should work.

template_preprocess_html(&$variables) {
  if (!empty($variables['page']['footer']) {
    $variables['classes_array'][] = 'with-footer';
  }
}
Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Tested. This works for regions. That a very good news, it seams like all the regions are present and usable there.
I had a closer look at the $vars from html. The only missing element that still bothers me is the navigation. Going back to my first message, I can't check if there's navigation or not on the page.
Not a big deal, just wanted to mention this.
Thanks for your help !

whatdoesitwant’s picture

whatdoesitwant CreditAttribution: whatdoesitwant commented

Just subscribing.

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented
Priority: Normal » Critical

Someone filed a separate issue stating:

At http://drupal.org/update/theme/6/7#rdfa_header is talk about changes in page.tpl.php while global structure of HTML document is now defined in html.tpl.php.

(I've closed that seprate issue as a duplicate of this one, since it looks as though doc follow-ups to #469242: Move <head> outside page.tpl.php are supposed to be filed here.)

Also, it looks like the theme update guide doesn't yet mention this (rather major) change to page.tpl.php -> html.tpl.php at all. It should.

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented
Component: theme system » documentation
Category: task » bug
catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented
Priority: Critical » Normal

#653068: Update documentation is incomplete

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented
Component: documentation » theme system

Moving to the Theme System queue for follow-up, since this is (as I understand it) a request to get the update from that other issue documented on the module/theme update guides, and not a request for better documentation for api.drupal.org

The "Needs Documentation" tag should stay, which is how we're grouping issues having to do with update docs.

JohnAlbin’s picture

JohnAlbin
he/they/他
Primary language English
Location Taipei, Taiwan
CreditAttribution: JohnAlbin commented

Re: comment #3

To be honest, I'm not sure how to get changes to html.tpl.php's $classes var if you want to base those changes on something that happens in page.tpl.php. That was one of my arguments against the split originally.

And I haven't played around with that particular issue to say how to do it. If anyone has any code snippets to share, I'd love to see them.

laura s’s picture

laura s CreditAttribution: laura s commented

Following up on this, I propose the following:

Revise and possibly split item #4 on http://drupal.org/update/theme/6/7:

RDFa requires some changes at the beginning of page.tpl.php

  1. This is incorrect and needs to be changed. These items are part of the content in html.tpl.php. This can be a simple rewrite.
  2. The existence of html.tpl.php is not mentioned anywhere on the page, so perhaps a new point should be inserted in the list that describes html.tpl.php and how stuff has been removed from page.tpl.php.
  3. The page should be reviewed to make sure mention of other things like $page_top and $page_bottom are clear. Currently the $page_top etc description (#22) doesn't really mention which template is affected. (Related discussions re $page_top etc specifically: http://drupal.org/node/519782 (and http://drupal.org/node/511284 as relates to admin toolbar)).

If this seems reasonable (and it does to me), next step is drafting the actual change so it's clear and doesn't need to be revisited. I hope to get to that today and will follow up on this issue with proposed language changes.

sillygwailo’s picture

sillygwailo
Location Toronto, ON
CreditAttribution: sillygwailo commented

Bumping this up.

Here's a first stab at documenting the newly available html.tpl.php.

html.tpl.php takes the place of page.tpl.php in providing the structure for the HTML header (the <!DOCTYPE> and the <html>, <head>, and <body> elements. See the documentation at api.drupal.org and the source code for the default html.tpl.php file. Themers can drop in a replacement html.tpl.php (and clear the theme registry) to override the HTML that it produces.

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented
Issue tags: -Needs documentation +Needs documentation updates

tagging for theme update guide

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented
Title: Provide documentation for <head> moved outside page.tpl.php » Fix theme update docs so they are correct on what is in page.tpl.php/html.tpl.php

I just added a section pretty much like #16 (thanks!) to http://drupal.org/update/themes/6/7#html-tpl -- so at least we now have a section explaining the existence of html.tpl.php. This is also item #2 of comment #15.

It looks like someone else already took care of item #1 of comment #15.

So the remaining need is item #3 of comment #15:

The page should be reviewed to make sure mention of other things like $page_top and $page_bottom are clear. Currently the $page_top etc description (#22) doesn't really mention which template is affected. (Related discussions re $page_top etc specifically: http://drupal.org/node/519782 (and http://drupal.org/node/511284 as relates to admin toolbar)).

So, leaving this issue as "active" until that is done (and changing title).

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented
Status: Active » Fixed

I've gone through the theme update guide and I think it's all clear with respect to html.tpl.php vs. page.tpl.php now. The only section I updated was
http://drupal.org/update/themes/6/7#closure
(the section mentioned in the previous comment).

So I think this issue is finally fixed.

Status: Fixed » Closed (fixed)
Issue tags: -Needs documentation updates

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue tags: +Needs documentation updates

Restoring issue tags, see #2125755: System messages removed all issue tags during D7 upgrade.