ecuk

Hi Fran,

It was my pleasure to help, and thank you for the very kind words. Having spent many years working in the speech sciences, and having taught many aspiring speech therapists, I am all too aware of the difficulties faced by those who have suffered strokes as well as various head injuries.

Rest assured that you did all of the hard work. After all, you had figured out the vast majority of what needed to be done to develop your child theme on your own. This is no small feat for anyone, let alone for someone with no little or no background in such things.

Keep up the blogging, and I wish you the best of success with your new and improved website.

Best,
Eric

I am not sure if you have found these already, but if not they are great places to start looking at how things fit together:

• Theme Development
• Templates

You also want to make sure that you make your changes in a child theme and not to the original TwentySixteen files themselves (i.e., wp-content/themes/twentysixteen/). This way updates to the TwentySixteen theme will not overwrite your modifications. Have a look at the page about Child Themes for more on this.

From the sound of what you are trying to do, you might want to start by looking at ‘header.php’, which is generally where the header and navigation are generated.

Hope that helps,
Eric

If I understand correctly from looking at the page on your site that you provided a link to, the problem you are having is that your header images are not the full width of the window. They are, in fact, inside a div with class ‘container’ that has a max-width (set by Bootstrap from the looks of it) and that has margin-left/right of auto. This means that all of your content, including the header image, are constrained to have a width of 100% of the containing container’s width (if that makes sense). The container’s width is set by one of several @media queries that help to make your theme responsive to the width of the window or device screen. On my screen at the moment it has a max-width of 1140px, but this will obviously get smaller when you switch to narrower devices.

The containing container has, somewhat confusingly, an id of ‘container-inside’ and a class of ‘container’. It appears to be the class of ‘container’ that is providing the width in the CSS. Because the margin-left and margin-right are both auto, this container is centred, with equal margins on either side.

What you are wanting to do, however, is not to set the width of the header image to 100% of its container but to 100% of the viewport. Modern browsers more or less support doing this (see below for what I mean by more or less) using the ‘vw’ unit, which is expressed as a percent of the viewport width. That is, 100vw is the full width of the viewport, 50vw is one-half, 33.33vw is roughly one-third.

The problem is that if you simply set the width of the header image to 100vw, meaning the full width of the window or device screen or whatever, you still have a margin to the left and right provided by the container that the image is within, which just pushes your now-the-correct-width header image to the right. (Try it. Set your header_image width to 100vw instead of 100% and see what happens.) To compensate for this you need to figure out the width of the viewport (i.e., 100vw), the width of the container (i.e., 100%), take the difference and divide by 2 because you have both left and right margins. If you calculate this so that it is a negative number and use it as your margin-left, your header image will then shift left to line up with the edge of the viewport. In theory.

Fortunately, using the calc() function in CSS, most modern browsers more or less support calculations almost anywhere you use units in CSS. (Again, see below for what I mean by more or less.)

So, in an ideal world you would put the following into your child theme’s style.css file (or, perhaps better, its front-style.css, which seems to be where you have been playing around):

.header_image {
    width: 100vw;
    margin-left: calc((100% - 100vw) / 2);
}

Unfortunately, we do not (yet) live in an ideal world, and this will not work on some browsers. See Can I use… calc for details, noting in particular the Known Issues tab below the pretty table. The Usage relative button above the table can also be very informative, as it gives you a better feel for how many people are using the browsers that work (and how many are using those that do not). You should also look at Can I use… vw for similar information about the support of viewport units such as vw. Again, make note of whatever it says in the Known Issues tab below the colourful table. (For what it’s worth, the developers of Can I use… provide a link in their footer to enable accessible colours for those with colour blindness. Bravo!)

Off hand I can think of no good alternative to the above, mostly because without having 100vw to indicate the true width of the viewport, and without having calc() to do the calculation on the fly, I can see no simple way to do what you would like to do without resorting to JavaScript, and even then I am not sure it would be possible. Perhaps someone else will have a better clue. I do most of my work in current and future CSS, and I don’t really do much with ensuring backwards compatibility for browsers that are older and out-of-date but still being used by a small minority. On the other hand, you might want to make sure that you do support them.

Hope that helps,
Eric

You might also want to look at this post from earlier today: [resolved] Seeing this? “unexpected T_ENCAPSED_AND_WHITESPACE in …”.

If it is the same problem, you might have a curly quote ( ‘ or ’ ) instead of a normal quote ( ‘ ) in your meta.php somewhere near line 161.

Hello Fran,

I will try to walk you through the process so that you understand what you are doing as well as doing it…

In the parent theme folder, themes/twentyeleven/, is a file called functions.php. It is very much more extensive than your child theme’s functions.php, but some of the PHP functions in it can be ‘overridden’ by providing a function of the same name in your own functions.php file.

Normally in PHP you cannot have two functions with the same name, but WordPress wisely wraps these functions in the parent theme with an ‘if’ statement that looks to see if you already defined a function of the same name in your child theme. Because your child theme functions.php loads before the parent theme functions.php, the child theme’s function will therefore come first and override the one in the parent.

Looking through the parent theme’s functions.php you will find a function called twentyeleven_posted_on. This is the function that generates the line with the ‘Posted on <date> by <author>’ text. (I am using angle brackets to indicate where the date and author name are inserted.) To override this in your child theme the simplest thing to do would be to copy and paste the original function definition from the parent theme’s functions.php into your own functions.php, then edit away to your heart’s content. Your child theme’s twentyeleven_posted_on function is then used, not the one in the parent theme. Make sense?

To save you a load of bother, however, I have already done this and tested the result. With any luck you should be able to copy and paste the following at the end of your child theme’s functions.php, and it should just do what you want:

<?php
if ( ! function_exists( 'twentyeleven_posted_on' ) ) :
/**
 * Print HTML with meta information for the current post-date/time and author.
 *
 * Overrides twentyeleven_posted_on in the parent theme
 */
function twentyeleven_posted_on() {
	printf( __( '<span class="by-author"> <span class="sep"> Posted by </span> <span class="author vcard"><a class="url fn n" href="%1$s" title="%2$s" rel="author">%3$s</a></span></span>', 'twentyeleven' ),
		esc_url( get_author_posts_url( get_the_author_meta( 'ID' ) ) ),
		esc_attr( sprintf( __( 'View all posts by %s', 'twentyeleven' ), get_the_author() ) ),
		get_the_author()
	);
}
endif;
 ?>

(I do hope that looks right. I haven’t before tried wrapping a large chunk of code in backticks and pasting it into this support site, and there doesn’t appear to be any way for me to preview my post.)

(For what it’s worth, I personally do not like the way that the original parent theme’s twentyeleven_posted_on function is written because it contains one line that is very long and not overly easy to edit. On the other hand, it works, and it wasn’t really all that much bother to edit the one super-long line. C’est la vie.)

You had also suggested changing the CSS (in your child styles.css) so that the date would be ‘display: hidden’, but this is now unnecessary. It seems to me far better simply to not generate the HTML with the date in the first place, especially as you need to override the twentyeleven_posted_on function in order to remove the ‘Posted on’ label anyway. Kill two birds with one stone and all that. This way there is no need whatsoever for CSS tomfoolery because there is no HTML generated with the date in the first place.

It is worth noting that I used the phrase ‘Posted by <author>’ instead of ‘By <author>’ because the latter didn’t look good to me. You can of course play around with the text if you like.

So that’s it. Easy peasy.

As to your question about making changes and being able to return to the old theme if you break your site, you needn’t worry. If you make a change to your child theme and all goes awry, you should be able to re-activate the original twentyeleven theme from the dashboard. You might suffer a brief interruption for anyone visiting your site, of course, but only for the few minutes it takes you to change themes.

If you truly, truly mess things up and you break your site badly enough that you cannot even get to the admin dashboard, you can always go into the Bluehost ‘File Manager’ and delete the folder with the child theme. WordPress is then smart enough to use one of its built-in themes, which will then allow you to start over from something stable. Because all of your posts and comments and whatnot are stored in the database, not as files within the wp-content folder, everything important should remain intact whenever you change from one theme to another.

As you can see, I can ramble on as good as anyone…

I do hope that helps, and happy child-theming!

Cheers,
Eric

Your code for both style.css and functions.php appear to be correct. Just to be sure, I copied and pasted directly from your message into new files in a folder called twentyeleven-child. I did this in my local development environment, but I can see no reason why it should behave differently on Bluehost. Everything works as it should: the child theme appears amongst my available themes and seems to work correctly when I activate it. I am therefore thinking that you somehow did not have your functions.php file in the right place, but it is impossible to say for sure.

I suggest that you follow the steps that you did above, then verify using the Bluehost ‘File Manager’ (mentioned in step 4 of the Anthony Baldor post) that you have two files in the wp-content/themes/twentyeleven-child folder, functions.php and style.css. If these are both there and both contain exactly what you wrote above, it really ought to work.

You might also consider using a text editor that is intended for writing code instead of using either Notepad or Wordpad, neither of which is meant for dealing with PHP and CSS code. Features such as syntax highlighting, for example, can save you a load of bother tracking down little things like missing parentheses and such, and this will become much more important when you begin writing the PHP code to not show the dates on your posts. Assuming that you are on a Windows computer, I generally recommend Notepad++.

Hope that helps,
Eric