24 pointsStarting to get into this DEV thingI'm new here
MonkeyPickles
Member
—
7th February 2012 10:58
We are in the process of creating a new styling withe the Network Theme and Buddy Press enabled. Im having a development company help with integrating a new styling. and we are running into a bit of a hiccup.
Do you see this issue in the Network Theme?
If so can we get an update?
If not, what can we do?
I have no problem giving you guys access, or giving you their contact information if at least on a email basis.. Whatever we need to do Im up for it you guys have been great to work with other little issues ive needed help with.. Let me know. We are pushing for a Release date of the new social network for March 1st. Thanks
Here is the message from Development Company...
"Good news first – the new theme is mostly in place and looks pretty solid right now:
Bad news – you’ll notice the background doesn’t meet the footer properly. This seems like an easy fix, except there’s a problem in the page markup (which I’m trying not to touch at all, in order to allow updates easily). I eventually traced it to unclosed div tags screwing up the structure. And even worse, the problem varies depending on which page you’re looking at, so it’s impossible to hack around :P
Anyway, long story short, this is a bug in the Network theme itself. Best long-term path would be to report it to them, and wait for an official fix. Anything I do to fix it would probably be overwritten in the next update. Bummer. "
We are in the process of creating a new styling withe the Network Theme and Buddy Press enabled. Im having a development company help with integrating a new styling. and we are running into a bit of a hiccup.
Do you see this issue in the Network Theme?
If so can we get an update?
If not, what can we do?
I have no problem giving you guys access, or giving you their contact information if at least on a email basis.. Whatever we need to do Im up for it you guys have been great to work with other little issues ive needed help with.. Let me know. We are pushing for a Release date of the new social network for March 1st. Thanks
Here is the message from Development Company...
"Good news first – the new theme is mostly in place and looks pretty solid right now:
Bad news – you’ll notice the background doesn’t meet the footer properly. This seems like an easy fix, except there’s a problem in the page markup (which I’m trying not to touch at all, in order to allow updates easily). I eventually traced it to unclosed div tags screwing up the structure. And even worse, the problem varies depending on which page you’re looking at, so it’s impossible to hack around :P
Anyway, long story short, this is a bug in the Network theme itself. Best long-term path would be to report it to them, and wait for an official fix. Anything I do to fix it would probably be overwritten in the next update. Bummer. "
Looking at this it's a little hard to see if you are confirming Timothy that you can recreate. However, let me clarify what exactly is expected here.
First up the footer is not linked to the main content by design so that's actually not a bug. It's designed to work with one background image not be in the content main wrapper. As a result if that is what you are expecting it's not a bug and it won't be fixed. You'd be looking to get a custom fix for that. It's a bit weird the person doing the changes considers this a bug if that is the case. It's got the following styling so you can see it would by default have padding and margins:
I will also underline that the validator is showing some plugins and other issues that aren't theme related so it's a little hard to see in that. I can't find an issue in my initial tests so really need to see what exactly you are expecting here @MonkeyPickles.
I'm not really sure about that so lets get on track a little. That's just got padding like that as not a 'true grid' just a floating one.
The first image to this post shows the footer wanting I think to be fixed to the bottom content to add a 'bevel' of sorts like a shelf I think. @MonkeyPickles can you confirm what you are trying to achieve. Do you want it to be right against the bottom of the content right - or are you referring to it aligning at the sides? If you can confirm that will help get us all on one or other of the tracks :)
Correct so the Footer aligns right up to the content.. Here is early mock ups of the new design... this is with no Widgets in the Footer.. but we will have achievements recent comments etc.. in the Footer and would like for it to align snug as a bug with content section..
Just to confirm... We will have to edit the Parent Theme slightly to get the theme to work as proposed in design? Its fine if thats the case just needed to confirm..
Is there anyway to make it work on a child theme.. To allow for easy updating as new releases happen?
Hey WPMU team! My name's Ben, posting as the designer/UI dev for the new MonkeyPickles site.
Looks like this thread got started off on the wrong foot... the alignment is just a symptom of the underlying problem, from what I can see. Let me back up a little:
The goal with this child theme is to style your awesome Network 1.7.4 theme specifically for MP. 99% of this is done in child.css, keeping markup changes and overrides to an absolute minimum for items like text/copy only.
Here's what I ran into:
While working on the footer section of the theme, I noticed that it doesn't stay consistent within the page DOM. On the home page, the #footer-wrapper divs are children of the #headerContainer div. On other pages, the footer containers are located under #headerContainer > #container. (It's that inconsistency that makes it tough to align & connect the footer visually)
Digging through the parent theme, it looks like a few of the content div tags aren't actually being closed. Thinking that it might have been something we did, I ran the stock Network home & blog pages through the validator, and it confirmed unclosed tags on each.
The validator isn't the full story on things. However, as already stated what you want to do for the design shown above needs a customisation in the child theme no matter what the validator says. We'd recommend that this is the approach you take. Anything we change will not allow you to get the footer aligning as if you look in the CSS it's designed to be in sections.
You can be sure though if you do a change in the child theme it won't be an issue with the parent you can be safe none of your changes will be updated if updates are only on parent themes. That is the approach we'd recommend here.
We will look at the theme for a tag review but that aside what you want you will have to accomplish in child customisation. Looking at the design posted here you will have to do that all in the child theme. Even if everything was in the headercontainer (which we will review) you would never be able to get it to align as it should be using a background image position bottom to get that design correctly and without too many images. This is what we'd recommend is your course of action there.
Update: I just reviewed and fixed one div. However, this was all the issues and only if you used branding-header.php. I still would strongly advise a customisation like the design should be done using child themes. Also this will not make the footer reach the content or in the same wrapper.
Thanks for the quick reply, Tammie. We are indeed using the branding header, so I'll update and take a look. The validator definitely isn't the end-all be-all, but even so the rendered page should at least have balanced tags, right?
And yes, all the design customizing is my court, and will continue with the child theme approach.
The only thing holding me up was footer hopping around in the DOM. A moving target is hard to hit ;)
Home page looks good now, but all other pages still show signs of an unclosed div and the .footer-wrapper still doesn't know who it's daddy is ;)
The main thing we need to move forward on the design is a consistent parent for the #footer-wrapper divs so we can position the footer consistently throughout the site (not just on the home page).
If the home page is working as intended, then the #container div is missing a closing tag on the 'normal' pages (blog, etc) somewhere, causing the browser to grab the #site-wrapper's closing tag and using it for the #container instead. This makes the .footer-wrapper divs children of the #container instead of the #site-wrapper.
TL;DR, I need the footer to stay out of the #container :)
Sorry for the trouble, just trying to get this out the door!
And you're right, it's easy to select the .foot-wrapper class - it's positioning that's the problem. If I line it up on the homepage (relative to its parent, #site-wrapper) then it's off everywhere else (since my styles are now relative to its new parent, #container).
I can't confirm what you say with no plugins active can you work on your child theme with this as I think it's specific to your case on that one. The footer is meant to be outside and is in my testing. I really think if you go the child theme route you can get your customisation.
Assigning a background color to #container makes it easier to spot in the stock theme, you can see red in the screenshots.
Themetastic still seems to be running 1.7.4 so your branding header fix isn't reflected there, but the issue I'm struggling with remains the same: the #container div is closed properly on the home page, but isn't on the rest of the content pages.
As requested can we look at the current theme not the demo please - its not as you say been updated yet. If you can test on a site with no plugins and show the results that would be preferable at this point. Please also provide a link don't just provide screenshots those aren't as easy to see things hands on with.
Just to clarify here is a screen shot with a page view on the latest version and one of a blog view. You will notice the divs you claim to be open are not. We will make sure the demo is updated once you confirm what I see using the latest version (1.7.5).
I think the confusion is you expect the same on the front and internal pages - this has different to a little extent a layout.
The browser DOM inspector will *never* show unclosed tags - the browser itself auto-closes all open tags in order to actually display the page. Check out the screenshots & look at the difference between the source & the inspector.
In my quick example, the validator checks the actual page source for balanced tags, and simply reports what it finds (100% accurate, in this case).
I was showing inspector screenshots earlier, because it demonstrates the fact that the browser is placing the page footers (and everything after #content opening tag) INTO the #content div. Since there's no closing tag for #content (except on the homepage), the browser incorrectly assumes the closing tag for the #site-wrapper div is intended for the #container div, and then auto-closes the #site-wrapper div when it hits the closing body tag.
I just showed you in Firebug how the latest version works. Can you please grab that version put on a site and lets get the link without any other plugins. I will then look at that for you. Please don't attach anymore screenshots lets look at what I've requested and get on track.
I have also tagged another one of our staff to do non developer testing for me as a second pair of eyes. They will report back here their findings.
Unbalanced markup w/ unclosed tags should never be 'by design' :(
I have a complete child theme developed already, but I can't close the container div (or change the page structure at all) through CSS. This needs to be addressed at the parent theme level, or I'll have to patch the offending core parent theme files and include them with my child theme. But this then breaks any chance at a nice, easy update flow for our client :/
Anyway, if the answer is simply 'as intended', I'll quit bugging ya.
I never said it should. What I am referring to is the footer wrappers being in a different location. You are hanging onto the div being site-wrapper/container when actually that message could mean the div is actually anywhere the validator is without judgement just going div to div. This is a common situation with the validator trust me I have experienced it.
What I am saying clearly and absolutely and have been since the start of this thread is there is no issue with that div or with the divs identified. Also that in a vanilla testing I could not find any open divs/unclosed divs.
If you do a child theme then your updates will never be changed feel free to do whatever you want there just instruct the person doing upgrade to never update the child and make sure you keep track of significant changes. In the case of headers / footers which would be the case here. As you are going to do that lets wrap this up and get on with getting your clients site live. Just instruct them to open a new thread should they need any further assistance with their child theme.
Responses (34)
Support Chimp — 7th February 2012 12:09 #
Hey there. I was just having a test and a play.
Thanks for the feedback there, I'll ping the theme developer on this.
Take care.
Theme Designer — 7th February 2012 12:20 #
Looking at this it's a little hard to see if you are confirming Timothy that you can recreate. However, let me clarify what exactly is expected here.
First up the footer is not linked to the main content by design so that's actually not a bug. It's designed to work with one background image not be in the content main wrapper. As a result if that is what you are expecting it's not a bug and it won't be fixed. You'd be looking to get a custom fix for that. It's a bit weird the person doing the changes considers this a bug if that is the case. It's got the following styling so you can see it would by default have padding and margins:
I will also underline that the validator is showing some plugins and other issues that aren't theme related so it's a little hard to see in that. I can't find an issue in my initial tests so really need to see what exactly you are expecting here @MonkeyPickles.
Member — 7th February 2012 12:27 #
Great.. Let me get this back to the guys.. I will follow up shortly...
Theme Designer — 7th February 2012 12:38 #
Well... lets get confirmation of what Timothy saw also then we can be clear what you need to get back with.
Support Chimp — 7th February 2012 12:44 #
Hi Tammie as I mentioned over Skype, I dropped you an email with screenshots. There should have been screens on my post :-(
I believe we are confirming the alignment between the boxes and the footer. The alignment on the second image looks fine to me.
Take care.
Theme Designer — 7th February 2012 12:46 #
I'm not really sure about that so lets get on track a little. That's just got padding like that as not a 'true grid' just a floating one.
The first image to this post shows the footer wanting I think to be fixed to the bottom content to add a 'bevel' of sorts like a shelf I think. @MonkeyPickles can you confirm what you are trying to achieve. Do you want it to be right against the bottom of the content right - or are you referring to it aligning at the sides? If you can confirm that will help get us all on one or other of the tracks :)
Member — 7th February 2012 12:59 #
Correct so the Footer aligns right up to the content.. Here is early mock ups of the new design... this is with no Widgets in the Footer.. but we will have achievements recent comments etc.. in the Footer and would like for it to align snug as a bug with content section..
Member — 7th February 2012 13:02 #
The other screen shot i had selected didnt upload.. to large.. so i resized.
Theme Designer — 7th February 2012 13:03 #
You will need to do some file editing to get that - it may be achievable mostly using CSS.
Member — 7th February 2012 13:40 #
Just to confirm... We will have to edit the Parent Theme slightly to get the theme to work as proposed in design? Its fine if thats the case just needed to confirm..
Is there anyway to make it work on a child theme.. To allow for easy updating as new releases happen?
Theme Designer — 7th February 2012 14:08 #
You should be able to do it using the child theme. No editing of the parent should be required.
Member — 7th February 2012 14:31 #
Great Thanks Tammie for the Help greatly appreciated.. you guys... rock..
Member — 7th February 2012 21:30 #
Hey WPMU team! My name's Ben, posting as the designer/UI dev for the new MonkeyPickles site.
Looks like this thread got started off on the wrong foot... the alignment is just a symptom of the underlying problem, from what I can see. Let me back up a little:
The goal with this child theme is to style your awesome Network 1.7.4 theme specifically for MP. 99% of this is done in child.css, keeping markup changes and overrides to an absolute minimum for items like text/copy only.
Here's what I ran into:
While working on the footer section of the theme, I noticed that it doesn't stay consistent within the page DOM. On the home page, the #footer-wrapper divs are children of the #headerContainer div. On other pages, the footer containers are located under #headerContainer > #container. (It's that inconsistency that makes it tough to align & connect the footer visually)
Digging through the parent theme, it looks like a few of the content div tags aren't actually being closed. Thinking that it might have been something we did, I ran the stock Network home & blog pages through the validator, and it confirmed unclosed tags on each.
This clip shows the W3C report run on your demo Network theme page source (so you can ignore the first error, since that's part of the demo). The lower two warnings are the same I get on our child theme. https://www.evernote.com/shard/s13/sh/40733e6e-602c-4bf2-908a-f42e2d8c6d06/1218f4a6a5fad9fd306d99e82994fa8f
Easy enough to fix, but probably not something I should try to fix in a child theme :)
Theme Designer — 7th February 2012 21:36 #
The validator isn't the full story on things. However, as already stated what you want to do for the design shown above needs a customisation in the child theme no matter what the validator says. We'd recommend that this is the approach you take. Anything we change will not allow you to get the footer aligning as if you look in the CSS it's designed to be in sections.
You can be sure though if you do a change in the child theme it won't be an issue with the parent you can be safe none of your changes will be updated if updates are only on parent themes. That is the approach we'd recommend here.
We will look at the theme for a tag review but that aside what you want you will have to accomplish in child customisation. Looking at the design posted here you will have to do that all in the child theme. Even if everything was in the headercontainer (which we will review) you would never be able to get it to align as it should be using a background image position bottom to get that design correctly and without too many images. This is what we'd recommend is your course of action there.
Theme Designer — 7th February 2012 22:09 #
Update: I just reviewed and fixed one div. However, this was all the issues and only if you used branding-header.php. I still would strongly advise a customisation like the design should be done using child themes. Also this will not make the footer reach the content or in the same wrapper.
Member — 7th February 2012 22:22 #
Thanks for the quick reply, Tammie. We are indeed using the branding header, so I'll update and take a look. The validator definitely isn't the end-all be-all, but even so the rendered page should at least have balanced tags, right?
And yes, all the design customizing is my court, and will continue with the child theme approach.
The only thing holding me up was footer hopping around in the DOM. A moving target is hard to hit ;)
Thanks again,
-Ben
Theme Designer — 7th February 2012 22:30 #
I'm not sure why it was not able to be targetted you can target #footer-wrapper if you're talking about DOM. However, yes please update.
Member — 7th February 2012 23:04 #
Home page looks good now, but all other pages still show signs of an unclosed div and the .footer-wrapper still doesn't know who it's daddy is ;)
The main thing we need to move forward on the design is a consistent parent for the #footer-wrapper divs so we can position the footer consistently throughout the site (not just on the home page).
If the home page is working as intended, then the #container div is missing a closing tag on the 'normal' pages (blog, etc) somewhere, causing the browser to grab the #site-wrapper's closing tag and using it for the #container instead. This makes the .footer-wrapper divs children of the #container instead of the #site-wrapper.
TL;DR, I need the footer to stay out of the #container :)
Sorry for the trouble, just trying to get this out the door!
---
Ben
Member — 7th February 2012 23:21 #
forgot to check the re-open box :P
And you're right, it's easy to select the .foot-wrapper class - it's positioning that's the problem. If I line it up on the homepage (relative to its parent, #site-wrapper) then it's off everywhere else (since my styles are now relative to its new parent, #container).
Theme Designer — 7th February 2012 23:23 #
I can't confirm what you say with no plugins active can you work on your child theme with this as I think it's specific to your case on that one. The footer is meant to be outside and is in my testing. I really think if you go the child theme route you can get your customisation.
Member — 8th February 2012 00:53 #
You can see it yourself on the WPMU demo site (select NETWORK from the dropdown).
Compare the structure of this page:
http://themetastic.com/buddypress/
to any subpage:
http://themetastic.com/buddypress/welcome/
http://themetastic.com/buddypress/blog/2010/07/25/we-make-high-end-design-accessible-to-all-with-our-themes/
Assigning a background color to #container makes it easier to spot in the stock theme, you can see red in the screenshots.
Themetastic still seems to be running 1.7.4 so your branding header fix isn't reflected there, but the issue I'm struggling with remains the same: the #container div is closed properly on the home page, but isn't on the rest of the content pages.
Theme Designer — 8th February 2012 01:02 #
As requested can we look at the current theme not the demo please - its not as you say been updated yet. If you can test on a site with no plugins and show the results that would be preferable at this point. Please also provide a link don't just provide screenshots those aren't as easy to see things hands on with.
Theme Designer — 8th February 2012 01:12 #
Just to clarify here is a screen shot with a page view on the latest version and one of a blog view. You will notice the divs you claim to be open are not. We will make sure the demo is updated once you confirm what I see using the latest version (1.7.5).
I think the confusion is you expect the same on the front and internal pages - this has different to a little extent a layout.
Member — 8th February 2012 18:28 #
The browser DOM inspector will *never* show unclosed tags - the browser itself auto-closes all open tags in order to actually display the page. Check out the screenshots & look at the difference between the source & the inspector.
In my quick example, the validator checks the actual page source for balanced tags, and simply reports what it finds (100% accurate, in this case).
I was showing inspector screenshots earlier, because it demonstrates the fact that the browser is placing the page footers (and everything after #content opening tag) INTO the #content div. Since there's no closing tag for #content (except on the homepage), the browser incorrectly assumes the closing tag for the #site-wrapper div is intended for the #container div, and then auto-closes the #site-wrapper div when it hits the closing body tag.
Theme Designer — 8th February 2012 18:45 #
I just showed you in Firebug how the latest version works. Can you please grab that version put on a site and lets get the link without any other plugins. I will then look at that for you. Please don't attach anymore screenshots lets look at what I've requested and get on track.
I have also tagged another one of our staff to do non developer testing for me as a second pair of eyes. They will report back here their findings.
Member — 8th February 2012 18:46 #
Got it, will do...
Member — 8th February 2012 19:31 #
http://bendrex.com/sandbox/wp/
Bone-stock 3.3.1 install, with Network 1.7.5 and a single menu added.
Below are 2 rules that were added to style.css help visualize the container structure:
Theme Designer — 8th February 2012 19:36 #
Yes.. that's by design as said that's not missing divs/ unclosed divs causing that. You need to create a child and do your modifications there.
Member — 8th February 2012 19:39 #
Home page: no unclosed divs, all good here.
http://validator.w3.org/check?uri=http%3A%2F%2Fbendrex.com%2Fsandbox%2Fwp%2F&charset=%28detect+automatically%29&doctype=Inline&group=0&user-agent=W3C_Validator%2F1.2
Sub pages: one unclosed div - #container. The report (last error in the list) says that #-site-wrapper is unclosed; this is because #container is stealing the #site-wrapper's closing tag.
http://validator.w3.org/check?uri=http%3A%2F%2Fbendrex.com%2Fsandbox%2Fwp%2F%3Fpage_id%3D2&charset=%28detect+automatically%29&doctype=Inline&group=0
Theme Designer — 8th February 2012 19:43 #
Actually no. Internal pages are as I said designed differently. If you want them the same please use a child theme file for that.
Lets leave the validator to one side for a minute and look at my attached image showing you the divs closing.
I have flagged the support lead also here to get them to come in to this thread and provide their opinion.
Member — 8th February 2012 19:50 #
Unbalanced markup w/ unclosed tags should never be 'by design' :(
I have a complete child theme developed already, but I can't close the container div (or change the page structure at all) through CSS. This needs to be addressed at the parent theme level, or I'll have to patch the offending core parent theme files and include them with my child theme. But this then breaks any chance at a nice, easy update flow for our client :/
Anyway, if the answer is simply 'as intended', I'll quit bugging ya.
Member — 8th February 2012 19:52 #
That's a screenshot from Firebug (the DOM inspector) - please read my earlier post about that :(
http://premium.wpmudev.org/forums/topic/footer-not-aligning-with-background?replies=32#post-179517
Theme Designer — 8th February 2012 19:55 #
I never said it should. What I am referring to is the footer wrappers being in a different location. You are hanging onto the div being site-wrapper/container when actually that message could mean the div is actually anywhere the validator is without judgement just going div to div. This is a common situation with the validator trust me I have experienced it.
What I am saying clearly and absolutely and have been since the start of this thread is there is no issue with that div or with the divs identified. Also that in a vanilla testing I could not find any open divs/unclosed divs.
If you do a child theme then your updates will never be changed feel free to do whatever you want there just instruct the person doing upgrade to never update the child and make sure you keep track of significant changes. In the case of headers / footers which would be the case here. As you are going to do that lets wrap this up and get on with getting your clients site live. Just instruct them to open a new thread should they need any further assistance with their child theme.
Member — 8th February 2012 21:15 #
Fixed.
The div #container-background is opened at the top of all content pages, except home page.
This div has no closing tag, anywhere.
I added a #container-background div tag to the top of home.php (to match all other pages), then added an extra closing div tag to the footer.php.
Home.php
footer.php
Problem solved - page structure is uniform across the site, and validates properly now.
Become a member