WordPress turning “next” into “previous”

One of my favorite WordPress themes is Twenty Thirteen and I’ve been using it as the parent of my child themes lately. However, on my most recent project, Illinois Doberman Rescue Plus, I discovered a weird little thing with how this theme’s archive pagination function is operating. (Also true for this website‘s theme. However, I’m keeping it here as my post sorting is always chronological descending.)

No matter how you sort your postings, when you get to the bottom of the page, the link that is supposed to take you to the next page of posts is labeled “Older posts”, it’s in the lower-left corner and pointing towards the left (just like the browser’s “back” button). This only makes sense for one narrow case, when the newest post is at the top of page 1. (Even then I could argue that the link to next page of results should not be displayed like a “back” button.)

So for cases when the sorting is different depending on the type of archive page, let’s simply change the “Older posts” and “Newer posts” labels to something more generic… but to what? Hmm, how about “Next page” and “Previous page”? Yes, that makes sense. Err wait, the link pointing to the next page (page 2) is down in the lower-left corner and pointing to the left (just like our browser’s “back” button). This is getting goofy… a link called “Next page” but it’s pointing backwards.

I suppose we could redesign all the templates and re-work the CSS but I think we need to take a closer peek at the workings of the twentythirteen_paging_nav() function which is located in Twenty Thirteen’s functions.php file. This function is called by the various archive template files to automatically create these pagination links as needed. Ignore the “older/newer” labels for now.

Did you catch that? They’ve place the next_posts_link() function inside of a div with the nav-previous class. And conversely, the previous_posts_link() function is contained within the nav-next class. This certainly explains a lot.

In defense of Twenty Thirteen, the context of the newest post being on top, the “next” page would be “older” posts. In this theme, the link to the “next” page is labeled “Older posts” and it’s pointing to the left signifying “back”. I call it “goofy” because it will break when posts are sorted in any other fashion. When oldest posts are on top or when they’re sorted alphabetically, etc., the “older” label is rendered totally meaningless. Since it, technically, always goes to the next page of the results query, it should be labeled as “next” and indeed the next_posts_link() function is how it’s created. However, simply re-labeling it as “next” is not good enough as it’s in the lower-left corner and pointing backwards towards the left.

My fix is simple. I copied this entire function into my child theme’s functions.php file. Since the original is wrapped inside if ( ! function_exists( 'twentythirteen_paging_nav' ) ), the version in the child theme will take precedence. Then I rearranged the function a bit…

Now using this slightly modified version, I get a “Next page” link that always points to the right and it always goes to the next page in the results. The link in the lower-left corner is labeled as “Previous page” and always goes to the previous page in the results. This is the most logical way as that it breaks all dependance on the sorting order.

As you can see my proposed arrangement perfectly corresponds to more traditional numbered pagination with “previous” on the left and “next” on the right…

You’ll still need to adjust your CSS a bit as Twenty Thirteen makes the “previous” link in the lower-left corner (formally called “Older posts”) about 60% larger than its mate. I think their idea was to make the button going to the next page larger. Since their positions and labels are flipped, you must adjust the CSS sizes.

Since you’re over-riding the parent theme, you’ll need to over-ride everything dealing with spacing and size. The following is the bare minimum required in the child theme to flip the sizes to correspond with our previous changes.

jQuery Nivo Slider has broken effects within WordPress

I’m using the jQuery Nivo Slider plugin on a WordPress project. Keep in mind that this is the free jQuery plugin version, not the WordPress plugin version, so I’m doing the integration myself into a child theme of the stock Twenty Thirteen WordPress theme.

To make it align properly with the other page entries, I used the standard WordPress classes on the wrappers…

The problem is, although the slider is nicely positioned on the page, the transition effects are broken. The slider is still working but just before each transition animation is supposed to start, you get a flicker of a tiny thumbnail in the upper-left corner and then the new slide appears… no slicing, no boxing, no wiping… nothing but sadness.

I was able to recreate my exact slider code in a jsFiddle and it worked flawlessly. After much troubleshooting, I discovered that the WordPress class .entry-content in the parent theme was the culprit.

However, the removal of .entry-content fixes Nivo slider, it also breaks the layout. By the time I figure out how to recreate the necessary parts of .entry-content to fix the layout, I’ve a whole bunch of unnecessarily redundant CSS.

Another look at the default CSS for the parent Twenty Thirteen theme reveals line #659…

Yes, this is it. This one CSS rule is completely breaking Nivo slider’s animation effects.

The fix is to simply un-set max-width to the default value of none by very specifically targeting the slider img elements. I placed this rule in my child theme’s style.css file.

Since .entry-content #slider img is more specific than the original selector, .entry-content img in the parent theme, it will automatically take precedence.

Nivo slider is now working as designed.

CSS shorthand for margins

When you specify margins for an element in your CSS, it might look like this…

Where each item above is pretty self explanatory. As you may already know, the order & format of the list above is totally arbitrary. It’s the same as this…

If you’re interested in making your code more compact, simply use the “shorthand” by writing “margin:” and following it with the specified margins in this exact order…


like this…


Specifying margins using CSS shorthand is explained in exact detail here at the W3 Schools website. However upon your first reading it may not seem clear how you could possibly remember the shorthand rules.

I’m going to attempt to break it down, hopefully making it easier:

Follow these two very simple “rules of thumb”:

1.  Always start at the TOP side of the element.
2.  Always move Clockwise around the element’s sides.

…top, right, bottom, & left

Got it?

But what if some or all of your margins are equal to each other- can you compact the shorthand even further?

Yes, you can. (Don’t forget the Rules of Thumb above)


Case #1. If left & right margins are the same:

TOP (10 pixels)
RIGHT & LEFT (12 pixels each)
BOTTOM (8 pixels)

To remember this, apply the rules of thumb (start at top and move clockwise) but stop after the third side. Top, Right (same as Left), Bottom, stop.


Case #2. If top & bottom margins are the same AND right & left margins are the same:

TOP & BOTTOM (10 pixels each)
RIGHT & LEFT (12 pixels each)

To remember this, apply the rules of thumb (start at top and move clockwise) but stop after the second side. Top (same as Bottom), Right (same as Left), stop.


Case #3. If all four margins are the same:

TOP, RIGHT, BOTTOM, & LEFT (10 pixels each)

To remember this is obvious; one number specifies all four sides… or simply following the rules of thumb (start at top and move clockwise) but stop after the first side. Top (same as Right, Bottom & Left), stop.

And to remove all default margins,


Case #4. If top & bottom margins are the same:

Unlike, Case #1 above, there is no special shorthand for this.


Other Examples:

All of the above examples assume you are specifying all four sides. What if one or more are zero?


TOP (no margin), RIGHT (12 pixels), BOTTOM (no margin), LEFT (12 pixels):


TOP (no margin), RIGHT (12 pixels), BOTTOM (no margin), LEFT (no margin):


(however, without specifying a zero margin for the other three sides, any default margins will apply)


TOP (12 pixels), RIGHT (12 pixels), BOTTOM (no margin), LEFT (no margin):


TOP (no margin), RIGHT (12 pixels), BOTTOM (no margin), LEFT (14 pixels):
(note that even though TOP & BOTTOM are the same, they cannot be combined in this case because RIGHT & LEFT are different from each other)


Notes: Zero can be written as simply "0" without the units on the end. I prefer to leave the units off because in this case, they are simply ignored.  As per the W3C, “The format of a length value (denoted by in this specification) is a (with or without a decimal point) immediately followed by a unit identifier (e.g., px, em, etc.). After a zero length, the unit identifier is optional.”


Reference: http://www.w3.org