Flat Shadow jQuery Plugin

I really dig this Flat Shadow jQuery plugin. You can find a demo here. It can be found on GitHub, too.

Saw this on DesignerNews earlier today and knew I’d have a use for it. Will probably use it to replace the image on the Work With Me page.

The plugin was originally released in August of 2013. It hasn’t seen much for updates, the most recent was in January 2014 and was a simple change to the README to include a license.

Searched on codepen.io quick to see if I could find anything using this plugin. One pen, Long Shadow Icon Prototype, looks to be using the plugin. It was created about the same time that the plugin was pushed to GitHub.

I haven’t used this yet, but the demo is super simple and looks really easy to use. Looking forward to playing around with it.

Detailed usage instructions and other customization options can be found on GitHub.

Add Schema.org Markup To Any WordPress Theme

Make Google, Yahoo, and Bing like you more!

The last post I made on this topic was a bit too specific to the Independent Publisher theme and was more editorial like, which made it really hard to follow. So, at the request of Manish Suwal ‘Enwil’, I’ve decided to write a more generic version that should apply to most, if not all, WordPress themes.

Please note that the class names used below could be different in the theme you’re using, so it’s mostly important to just pay attention to the HTML tags themselves, unless you’re doing something with a div, span, etc.

There’s 6 steps, although step 6 has a few different parts to it.

1. First, you’re going to want this PHP function, a slightly modified version from Paul Lund. This function defines the schema type based on the type of content being displayed (article, author profile page, search results page, etc). Add this function to your themes functions.php file. The function is named html_tag_schema(). You can find it here:

2. Find the <html> section of your theme and add our html_tag_schema() function. This will output the proper result from html_tag_schema(). It should look like the following:

<html class="no-js" <?php schema_org_markup(); ?> <?php language_attributes(); ?>>

3. The page title tag is usually the same as the title of the page, so you can add this to your titletag:
<title itemprop="name"><?php wp_title(''); ?></title>

4. Now you’ll need to find the part of your theme that contains the_content() function. It could look something like this:

<div class="entry-content" itemprop="mainContentOfPage">
  <?php the_content(); ?>

5. It’s generally a good idea to let Google (and other search engines) know when an article/post was published. You can also tell them if/when an article has been updated. Both of these can be taken care of with schema.org markup:

<time class="entry-date" datetime="<?php the_date('c'); ?>" itemprop="datePublished" pubdate><?php the_time( get_option( 'date_format' ) ); ?></time>

6. You can apply schema.org markup to any image, but it’s easiest when your theme supports featured images. I think most themes do support Featured Images now, and if your theme doesn’t, just add Featured Image support yourself, or kindly ask the theme developer to add support. I could probably help you out, too.

6a.If your theme supports Featured Images, it should make use of the the_post_thumbnail() function. Find that function in your theme and replace it with this:
the_post_thumbnail( ‘thumbnail’, array(‘itemprop’=>’image’ ) );

6b.If the ‘thumbnail’ parameter value in your existing the_post_thumbnail() function is something other than ‘thumbnail’, make sure to keep that original paramater value. For example, if your the_post_thumbnail() call looked like the_post_thumbnail( array( 700, 700 ) );, adjust your the_post_thumbnail() function call to the following:
the_post_thumbnail( array( 700, 700 ), array(‘itemprop’=>’image’ ) );

6c.The array( 700, 700 ) piece can be replaced by whatever size you want. The first array value is the width, and the second is the height. There’s a variety of image sizes pre-defined by WordPress:

The default image sizes of WordPress are “thumbnail”, “medium”, “large” and “full” (the size of the image you uploaded). These image sizes can be configured in the WordPress Administration Media panel under Settings > Media. This is how you can use these default sizes with the_post_thumbnail() and schema.org markup:
the_post_thumbnail(); // without parameter -> 'post-thumbnail'

the_post_thumbnail(‘thumbnail’,array(‘itemprop’=>’image’ )); // Thumbnail (default 150px x 150px max)
the_post_thumbnail(‘medium’,array(‘itemprop’=>’image’ )); // Medium resolution (default 300px x 300px max)
the_post_thumbnail(‘large’,array(‘itemprop’=>’image’ )); // Large resolution (default 640px x 640px max)
the_post_thumbnail(‘full’,array(‘itemprop’=>’image’ )); // Full resolution (original size uploaded)

the_post_thumbnail( array(100,100), array('itemprop'=>'image' ) ); // Other resolutions (100x100)

That’s it!

If you want to know more about schema.org, have a look at my original post. Schema.org is also a wonderful resource, their documentation is excellent and would advise that you read through the Getting Started Guide, it provides a great overview of the concepts behind structured data and schema.org.

Other Resources

Google has this little post about adding schema.org markup for organization logos. If you’re an organization, you should probably see what that’s all about.

Craig Bradford at Moz.com says you’re behind if you’re not using schema.org yet. That post from Craig also has a lot of really good information for those new to schema.org and structured data.

Google also has a post about adding schema.org markup to videos, which could be really useful if you run a site with a lot of video content.

Searching the Google Webmaster Central Blog for “schema” yields some pretty useful results, too.


That’s all there is to adding basic schema.org structured data to your WordPress theme. You could obviously extend it to support more schema.org “things”, but I’ll leave that for you. If you did every step in this post, you’ll have schema.org markup for featured images, article publish and update time, main content declaration and structured data enabled title and head HTML tags.

Should more WordPress theme developers start building schema.org markup into their themes?

View Results

Loading ... Loading ...
No structured data? You suck.

Have any questions, comments, or maybe even praise? Comments are open, as usual.

WordPress Theme Devs: Add Schema.org Markup To Your Themes

I’m using the Independent Publisher theme. I made a child theme to add schema.org markup a few days ago. Instead of hoarding it, I sent a pull request on GitHub with the schema.org markup for inclusion in Independent Publisher.

Not sure what schema.org is? It’s a widely adopted microdata format, similar to microformats. Schema.org, however, is supported by all the major search engines, giving it a definite edge over other microdata. The FAQ at schema.org is definitely worth checking out.

Structured Data Markup HelperGoogle also has a Structured Data Markup Helper that helps you add structured-data markup to a sample page. Just give it a URL, select an element and choose which structured-data to apply.
Structured Data Markup Helper Interface
It’s not like there’s no WordPress themes without schema.org markup built-in, but there’s certainly not many. I don’t even have this built into my WordPress themes, I should update Rootdip with schema.org markup. Unwakeable, however, hasn’t been maintained in forever, and schema.org didn’t even exist back then.

There’s plenty of plugins for adding schema.org markup to your WordPress site, but I think it makes sense to just integrate it right into the theme. The theme developers know exactly where their tags are, preventing the need to add additional info to the end of the post that’s wrapped in schema.org markup.

I tried out the All In One Schema.org Rich Snippets plugin, but it would require me to enter duplicate content (title, description, etc). It would also display a box at the end of each individual post page containing that extra, unnecessary content.

Because of that, I decided to just add the schema.org markup myself. It’s really very simple and only took about 15 minutes to do. Google likes schema.org data, and making Google happy is important to the ranking of your site. 15 minutes is definitely worth the time to do it right.

Paul Lund has an excellent write up on adding schema.org to your WordPress theme. This post by Isabel Castillo basically spelled out how to add the proper attributes to images, which was one thing missing in Paul’s post.

Anyway, here’s what I’ve put together as a basic starting point for integrating schema.org into your WordPress theme. Stuff is probably missing, some stuff may be incorrect. If so, please let me know in the comments.

Should more WordPress theme developers start building schema.org markup into their themes?

View Results

Loading ... Loading ...

Before you begin

If your theme doesn’t include some of the tags mentioned below, like <header>, <footer> , <article> , and <time> , you can use regular <span> tags instead. Just make sure you keep the itemscope attributes and their values.

Modify single article file

This is usually single.php, content-single.php, or something similar. Find the <article> tag and add the following to the end:
itemscope=”itemscope” itemtype=”http://schema.org/BlogPosting” itemprop=”blogPost”

If your theme supports post thumbnails, find the_post_thumbnail(); function and replace it with something like this:
the_post_thumbnail( ‘thumbnail’, array(‘itemprop’=>’image’ ) );

Now find where the post date/time is being displayed. You’ll want to wrap it in a <time> tag like below. You can also use a regular <span> tag as well, just be sure to add the itemprop=”datePublished” and pubdate attributes.
<time class=”entry-date” datetime=”<?php the_time(‘Y-m-dTH:i:sO’); ?>” itemprop=”datePublished” pubdate><?php the_time( get_option( ‘date_format’ ) ); ?></time>

Next find where the title is printed, usually between h1 tags, add an itemprop attribute with a value of name, like so:
<h1 class=”entry-title” itemprop=”name”><?php the_title(); ?></h1>

Now add another itemprop attribute wtih a value of mainContentOfPage to the div containing the_content(); WordPress function:
<div class=”entry-content” itemprop=”mainContentOfPage”>

Modify header.php

Only a few easy changes in this file. First, change your <html <?php language_attributes(); ?>> to look like this:
<html <?php html_tag_schema(); ?> <?php language_attributes(); ?>>

Next, change your <body> tag to this:
<body <?php body_class(); ?> itemscope=”itemscope” itemtype=”http://schema.org/WebPage”>

If your theme has a <header> element, change it so it’s similar to this:
<header id=”masthead” class=”site-header” role=”banner” itemscope itemtype=”http://schema.org/WPHeader”>

Modify footer.php

If you theme has a <footer> element, modify so it resembles the code below:
<footer id=”colophon” class=”site-footer” itemscope=”itemscope” itemtype=”http://schema.org/WPFooter” role=”contentinfo”>

functions.php addition

Paul Lund wrote this function to define the schema type automatically for the type of content being displayed (ie: article, contact page, etc). You can see the <html <?php html_tag_schema(); ?> <?php language_attributes(); ?>> function in the functions.php file in the demo repo.

Ideal Implementation

Don’t modify the core files of the theme you’re using. It’s seriously wrong and makes upgrading your theme almost impossible. Instead, create a child theme. It’s really, really easy to do and will inherit all the functionality and styles of the parent theme. For your convenience, I’ve put an example child theme up on GitHub, tlongren/wordpress-child-example.

Since it’s a child theme for Independent Publisher, you’ll want to fork it and modify it to fit your theme. If you’re already using Independent Publisher, you should be good to download the repo, upload it to WordPress, and activate the new theme from the WP dashboard.

Why Implement Schema.org?

Because Google says so:

Historically, we’ve supported three different standards for structured data markup: microdata, microformats, and RDFa. Instead of having webmasters decide between competing formats, we’ve decided to focus on just one format for schema.org. In addition, a single format will improve consistency across search engines relying on the data. There are arguments to be made for preferring any of the existing standards, but we’ve found that microdata strikes a balance between the extensibility of RDFa and the simplicity of microformats, so this is the format that we’ve gone with.

It also helps you define the default image that’s pulled when sharing a link on Google+ or Facebook. Users will still have the option of choosing another image, but probably won’t when the featured image from your post is automatically there. And this is just one example of why you should at least consider implementing schema.org markup.

As usual, comments are open, so please let me know what I got wrong and what could be improved. I appreciate whatever feedback people offer.

This post is a mess

This one is much more concise and much easier to implement, you’re probably better off starting there.

Basic Routing in PHP with AltoRouter

Routing in PHP using AltoRouter

I’ve been using AltoRouter for help with building simple API’s. A full framework (even a micro-framework), like Slim, is usually overkill for my needs, and often, any kind of routing class is overkill. A .htaccess file with the proper rewrite rules will usually suffice.

When I do need a bit more control than a .htaccess file provides, I usually go with AltoRouter. AltoRouter is really easy to use.

First thing to do when using AltoRouter, or pretty much any PHP routing class/script, is to direct all requests to index.php. We do this with a .htaccess file. Here’s the .htaccess file I usually use with a project using AltoRouter:

That will direct all requests to your site to index.php. Inside index.php is where we setup AltoRouter, define our routing rules, and specify any parameters that we want to capture. A basic example of an index.php file using AltoRouter can be seen below.

Lines 10-15 are just standard routes being setup, we could easily do this with a .htaccess file. The next block, with the “Special” comment title, is a little more involved. But only because we’re passing a parameter or two to our PHP controller.

When I say PHP controller, I’m referencing the third parameter in the AltoRouter map() method. The first parameter is the HTTP request method, usually either GET or POST. The second parameter is the route we want to watch for. The third parameter is the controller, or the PHP file that we want when the route from parameter two is matched. And the fourth parameter is just a unique name for that route.

If you’re using named parameters in your routes, like you see being done on lines 18 and 19 in the index.php gist, you’re going to want to access them within your controller. Notice the very end of the index.php gist, specifically, everything below the /* Match the current request */ comment. That’s where we’re doing the actual matching, if the current URL matches a defined route, then we require the controller.

Before that though, we’re actually setting the $match variable. Since we’re setting $match before including our controller, $match should be available for use within our controller, which is awesome!

Say we’re charging a customer, and this is done by hitting /charge/the_customer_id/, where the_customer_id is an actual customer ID. In our controller, charge.php, we can access the_customer_id named parameter as seen below. It’s available in $match['params']['customer_id'].

You can use all sorts of limits on your named parameters, like integer matching, alphanumeric matching, and even hexadecimal character matching. A useful list of named parameter limits and some examples can be seen in the AltoRouter readme. Comments are open, so please let me know if I’ve missed something or am just totally off base somewhere. Thanks!!

How-To: Continuously Monitor System Load And Track Down Resource Hogs

I’ve been using Linux for 12+ years. In all that time I’d never used, or even heard of, a program called tload. tload is similar to the top program, in that is sits running in your terminal, showing you the current system load.

tload gives you a basic text “graph” of the current system load average. It uses data from /proc/loadavg to operate. If you’re really into how tload operates, check out this post by Baron Schwartz.

I’ll usually open up a connection to a server via SSH and just let tload run for a while. If the load gets to be too high, I’ll usually use top to see which processes are sucking up all my resources, processor resources typically. I usually just run top like so:
top -H

After that, there’s a couple commands that I use to find how many threads are running under a specific user or under a specific service. To find the users (5 in this case) with the largest number of threads running under them, run the following:
ps aux | awk '{print $1}' | sort | uniq -c | sort -nk1 | tail -n5

To get the processes with the most threads running under them, run the code below. It’ll also show the top 5 processes. Change the tail -n5 part to tail -n10 to see the top 10 instead.
ps aux | awk '{print $11}' | sort | uniq -c | sort -nk1 | tail -n5

That’s really all I use when I encounter extremely high loads, whatever the reason may be. They should work nicely for you too. tload comes bundled with pretty much every linux distribution in existence. And from the info you gather with top and the awk commands above, you can easily narrow down what the issue is. Figuring out why that issue is happening in the first place is an entirely different story though.

There’s one other really good method involving top that is discussed at Joomlaperformance.com. The code example they give is top -b -i -n 20 >> ./top_procs. It basically saves information from top into a file, top_procs, and runs the top command 20 times. They describe it better than I do.

What that does is tell TOP to run in “batch” mode (not look for any user input), show only running processes, loop 20 times, and append the output to the file /top_procs. Run that command when you are experiencing a high server load. Then you can view the contents of that file to tell you some information.

So that’s that. Should be relatively easy for you to track down what’s causing high load on your vps, server, desktop, or whatever other linux system you use.