Experimenting with the WP REST API

As a quick weekend project, I added some ajax-y goodness to my site with the help of the WP REST API plugin (set to be included soon in WordPress core) and History.pushState. There are some bugs, namely I still need to get the appropriate Jetpack gallery, related posts and share button features to load when accessed via javascript, if possible.

EDIT: I’m no longer experimenting with the REST API on this blog. Because I’m lazy, and it didn’t really bring any value to the site.

Simple Conditional Loading in WordPress

Over a year ago, Jeremy Keith wrote an excellent post on enhancing the performance of responsive sites by checking for a minimum screen width before loading secondary content such as related news and latest tweets. Mobile devices would just show a link to the content, thus keeping it accessible. In this post I’ll show how to do a similar thing in WordPress.

Method 1: Custom page templates

I thought there should be an easy way to delay the loading of any secondary content, and my first thought was to use the very simple .load() method in jQuery along with a custom page. For instance you could create a special template to show related blog posts, and display a link to that page. On wide screens this link can be replaced with the content of your custom page using ajax. This is a perfectly valid way of doing it, especially if you have only one or two pieces of secondary content.

Method 2: Custom Endpoints

What if I want to conditionally load the WordPress sidebar on every page, and the contents of the sidebar is not necessarily the same everywhere? Creating page templates and pages for all that secondary content can become messy and error-prone. My esteemed colleague (and boss) Aki suggested a better way of doing this would be to check for a specific parameter in PHP and generate either the main content or the sidebar. All we need is the sidebar version of the page to have its own URL. Enter Sandman WordPress Endpoints!

URL endpoints are part of the Rewrite API, and are used for many things, among others to generate feeds (via /feed/) and paging (eg. /page/2/ to see older posts or the second part of split post). The following code will register a new endpoint /part/.

The above code should go in the theme functions.php file, or better yet, a separate plugin. To make the endpoint actually work you might have to clear your rewrite rules — simply opening the WordPress Permalinks settings and saving should do the trick.

Now the endpoint is registered, you can access it in PHP using the built-in WordPress function get_query_var(). For example, you could construct your sidebar.php template like this:

In the above example, when we access a URL ending /part/sidebar/, the condition will evaluate to true. So now we have an accessible, functional solution with cacheable URL’s. We’ll just add some jQuery magic to load the sidebar content in place on wider screens:

If you also want to support ajax loading on smartphones, add this to trigger it with a tap/click:

That’s all! A functioning demo can be seen on this blog: try loading it on a small screen vs. a wide screen.

Flexible fluid layouts with CSS and jQuery (Part 2 in series)

2012 Update: This techniques outlined here have been mostly outdated by CSS3 Media Queries, which I recommend using instead.

This is a follow-up to last week’s post, Should we design for wider screens?. In this post I’ll demonstrate with a simple example how easy it is, with CSS and a bit of jQuery, to make layouts that adapt to the many different screen sizes out there.

Example HTML

At the top level, my example HTML page has a #wrapper div, which contains a #header, #main div containing all the interesting stuff, and a #footer. The main section has #content, #primary, #secondary and #tertiary divs for the different content areas of my page. The first two content areas, #content and #primary are wrapped up in an additional #container div, but your own markup may obviously differ.

Prepare your styles

The basic idea here is to have different CSS styles for each width. The styles could be changed directly through jQuery, but that would quickly result in a lot of messy code. Instead, we’ll use jQuery only to change one class attribute. Initially I’ve added the class ‘normal’ to the body element to ensure a sensible default for browsers with JavaScript disabled, but we’ll also need styles for ‘wide’, ‘slim’ and ‘narrow’. This is easy to do with CSS descendant selectors:

Unfortunately versions 7 and older of Internet Explorer deal differently with percentage widths compared to most other browsers, and can result in some funny behaviour. I see two primary ways to deal with it: either feed IE 6 and 7 it’s own rules (e.g. a tested, fixed-width layout) or just make sure that the percentages never add up to 100 %. A nice explanation of this annoying feature can be found over at OJTech.com.

The jQuery

First of all I need to include jQuery, and perhaps the easiest way is to use Google’s jQuery for this. The main bit is a function, checkWidth() that (you guessed it) checks the width of the browser window and sets the body class attribute accordingly. The code below should be pretty self-explanatory.

In addition to this, all I need is some code that will tell the browser when to run the checkWidth() function.

That’s it! View the finished demo EDIT: I’ve managed to lose the demo at some point in time. Anyway a better and more flexible way of doing this is CSS3 Media Queries, and you should use them.

After starting to write this post, I read the latest issue (#200) of .net magazine and noticed a mention of a very cool way to do a similar trick using only CSS media queries! Media Query demo by Bruce Lawson. Haven’t tried it out yet, but I definitely will.

Hope you liked the post, feel free to tweet it, or leave a comment below.

Experimenting in HTML5 and CSS3

I decided to experiment with some of the new elements in HTML 5 and built my blog theme from scratch (with the help of the Carrington framework though). I’m now rolling article, section, header, footer and other stuff. Because IE needs a Javascript hack to enable support for these elements, I wouldn’t consider doing this in any client work, but hey, this is MY blog! Continue reading “Experimenting in HTML5 and CSS3”