Three Challenges facing Apple

I’ll pay you money if you provide me content I’d like to enjoy.

A fantastic accounting of the challenges facing Apple these days. Everyone I know who uses iTunes hates it, and most of the TV watchers I know use Netflix almost exclusively. Apple is certainly at the top of their game, but these holes need to be plugged asap.

Don’t miss the rest over at KickingBear.

The future of web hosting

On this, the 15th day of May, 2012, I have seen the future of web hosting. I think (hope?) it looks something like OpenShift.

While browsing HackerNews this morning, I came across this link to OpenShift, a “cloud-centric” web/app host from Red Hat. I had a look. I liked what I saw.

WordPress on OpenShift

I’ll run through what I did this morning—install WordPress—in about 5 minutes.

1. Signup
2. Create a new application (PHP)

3. Select a name/url for your new site

4. Clone a copy of the empty application to your local computer with Git

5. Download WordPress into the php folder that comes after you’ve cloned the empty application (ie: /php is your public web folder).

6. git commit -am 'Added WordPress files, first commit!'

7. git push.

8. Add a mysql ‘cartridge’ to your application. Make note of the username/password/url info after you add the cartridge! You’ll need that info soon.

8. Visit your address, under the ‘Accessing your application’ area of the welcome screen to go through the normal WordPress install.

In short: Create a new application in OpenShift, download, commit and push WordPress up to your OpenShift account, install WordPress. How about that. There’s obviously more to the story than that—hooking up your own domain name, configuring a cache system, etc…but the basics are looking pretty impressive.

I thought this post was about the future?

And it is. This hosting setup is extremely futuristic for a number of reasons:

  1. Cloud = pay for what you use
  2. Git is baked right into the workflow—just as Heroku has gotten baked into the Ruby on Rails workflow (at least for beginners)
  4. Worry-free scalability. Let someone else worry about your site getting Fireballed

While I have no idea what OpenShift is “up to” — they haven’t yet published a pricing model — I really think that this is the future of web hosting. An easy, cloud-based, scalable solution, centered around a workflow with Git.

Welcome to the future. I hope.

ps: My WordPress install was blazing, blazing fast.

Autonomy, mastery, purpose

A must-watch video if you’ve ever wondered why you hate your job. Spoiler: autonomy, mastery and purpose are the three elements you need for job success.

Adobe, the new face of Yesterday

Adobe recently launched its Creative Cloud and Creative Suite 6. One of the biggest attention getters from the launch events was news that Adobe looks to taking a good hard look at how we layout content in HTML.


Call me skeptical, but I’m really not optimistic about Adobe’s ability to make the ground move under the the huge HTML silo. But they bought PhoneGap you say, and that’s pretty cool. And they bought Typekit, which everyone uses, so that must be cool too! Right? It might be enough for you, but it’s not enough for me.

All the counter-evidence I needed, I saw yesterday: Adobe filtered live tweets into the launch page while they were giving product demos. The catch? They used Flash to import them.

I just can’t see how a company so rooted in the old way of doing things, and so entrenched in their own (sinking) technology can be the ones to lead the way to a better web.

I’ll be happy to eat these words in 5 years time when Adobe has pushed the web forward and really made a useful dent in this huge ecosystem. But I’m not holding my breath.

Tighter and leaner WordPress templates with get_template_part()

Update: This article is a little dated now. As of a few months ago, I’ve stopped using Victoria Park and now use a fork of Underscores from Automattic. I’d recommend starting there. That said, everything else in the article still applies!

I use Victoria Park, a very slightly modified fork of Automattic’s Toolbox, for all of my projects. But every now and then when starting something new, I’ll go shopping around for a theme that’s custom-built for the task at hand. If I’m making a portfolio site, or a knowledge base, for example, I’ll often look to see if there’s a ready-made solution out there, rather than starting from scratch.

A lot of the themes I find out there seem like they’re ready to just drop into place, but so far, at least for me, they’ve always been fool’s gold.

Using something other than your tried-and-tested base theme is a bit like cooking in someone else’s kitchen. Sure, things will get cooked, and the meal will most likely turn out just fine, but it won’t be the same. You won’t find the same frying pans you’re used to, the stove will be different, the cutting board too small, the knives not sharp, etc. Cooking in someone else’s kitchen just won’t feel natural to you, and neither will using someone else’s WordPress theme.

Pots, pans and knifes, all your own

I’ve directed lots of people to Toolbox and its successor _s. I’m still using Toolbox at the moment, but plan to take _s for a spin on my next project. The two are very similar and _s looks on the surface to add nice, minimal enhancements to an already good theme.

Even if you don’t fully adopt these themes as your own starting point, I will recommend (encourage? implore?) that you follow Automattic’s lead in these few important ways:

1. No more loop.php

For too long, loop.php was a melting-pot for a huge pile of logic and conditionals that made modifying it a chore. Ten lines of code that say, “if the user is logged in, and not in the admin area, and not looking at a blog post, and not didn’t have a sandwich for lunch, then show them this content”, make things hard to read and modify. There’s a better way to naturally abstract that logic away. WordPress already knows about and expects files like single.php, page.php, front-page.php, etc, so references to them don’t need to be coded into a loop.php file. There’s no need for conditionals like is_single(), or is_front(), for example, because these already have their own template files. Any code you put in front-page.php or single.php will be picked up automatically, no need for conditionals.

2. Start with a good index.php file.

index.php is usually your first port of call. This is where you want your loop. Like so:

<?php /* Start the Loop */ ?>
<?php while ( have_posts() ) : the_post(); ?>

		get_template_part( 'content', get_post_format() );

<?php endwhile; ?>

Looks simple enough, but there’s a small bit of magic in there. For a good description of this magic, please see item 3, below.

3. get_template_part()—the heart of your theme.

Though not a huge, or terribly powerful function, get_template_part() has become a core part of all of my themes. get_template_part() is more than a function, it’s a way of thinking about structuring your themes. Instead of including the markup for your blog posts, asides, or galleries directly inside index.php (or formerly loop.php), leading to huge, unreadable files, you include their contents in a separate file: content-{post-type}.php. An example will clear things up.

Imagine trying to have different markup in a standard blog post and an aside, where you remove the title, tags, and category:

To achieve this, an old loop file might look like this (I’ll write this in English instead of PHP, for understandability):

while ( have_posts() ) : the_post();

if post-type = 'aside'
	<footer> The date, the tags, etc </footer>

if post-type = 'blog post'
		<h2>Post title</h2>
	<footer> The date, the tags, etc </footer>

if post-type = 'gallery'
		<h2>Post title</h2>
		.....the gallery.....
	<footer> The date, the tags, etc </footer>

While your shiny, new index file will be much simplified. Containing just this tiny loop:

while ( have_posts() ) : the_post();

get_template_part( 'content', get_post_format() );

Using this example, WordPress will still loop through all of your posts, but it will examine each one to see what post format it has (aside, image, article, gallery, link, etc). Each time, it will go looking for a corresponding content file:


Now, all of your template code is neatly abstracted into individual files. You know, for example, that you don’t want to have titles on aside posts, so to get rid of them, just delete the post title from content-aside.php.

The obvious next question you might have is, what if I don’t have a template file for each post type I have? The beauty of this method, is that you don’t need one. If you want asides to look just like blog posts, then don’t have a content-aside.php file. WordPress will simply look for it, not find it, and serve the plain content.php instead. The only file you need is content.php—you’ll only need the others if/when you want that post type to look different.

This all probably sounds a bit like we’re splitting hairs. What’s the difference between having one really long file and having a bunch of really small files? It might not make much difference to you at all, but it makes a big difference to me. As I keep adding more and more post types, including more and more custom post types (outside the standard ones: aside, gallery, links, etc), using this get_template_part() pattern becomes really useful. Instead of scrolling through potentially hundreds of lines of template code, you now just need determine the post type and find its corresponding content-{post-type}.php file.

To sum up

Have a look at _s to see how this is done, or have a look at Victoria Park to see how I do it. My rule of thumb is, whenever I’m doing something like adding/removing a post tile, or post tags/categories, or the date, or otherwise changing a post’s markup in any way, I make sure I’m doing it in a content-{post-format}.php file instead of in index.php or loop.php. Note, of course, that this works just as well for custom post types as for the different post formats. Just put your custom post type content in: content-{my-custom-post-type}.php

This is an excellent habit to get into and will lead to much more readable, maintainable and sharable themes.

The proper way to email someone about a problem with your website

Problem with your website? This is the proper way to email your developer and tell them about it:

Hey web developer!

Hope the weather is good in (that place where you live)!

There’s an issue with the ___________. You can see it half way down the page.

Screenshot attached.


And that’s it. A quick hello, one single sentence describing the problem, and a screenshot.

Using CSS Preprocessors

Jeff Croft wrote an article today outlining the various ways in which you can process LESS/SASS.

There’s a fair amount of confusion surrounding css preprocessors like Sassand less, and I think some of it has to do with the fact that there are so many different ways you can use them.

Of course he’s 100% right—and it doesn’t need to be confusing at all. When I was first trying this stuff this stuff out, it took me a long time to figure out the ‘best’ way to get my LESS processed into plain-old CSS and get my CSS up to the web server, and thence to the browser. I started compiling it with Javascript at the browser end—but that’s not at all what you want to be doing.

Very simply, here’s precisely what I do with all my WordPress sites:

  1. Write my css to LESS file— called style.less
  2. Use LiveReload to compile it immediately upon hitting save to a style.css file. Every time I hit save, my .css file automatically gets overwritten by the new changes.
  3. I commit both the .less file and the .css file to git and then to Github.

In doing it this way, WordPress never, ever needs to know I’m using LESS. I link to the style.css file in the header as normal, and LiveReload happily serves it up every time I hit save.

Just as easy as that.