Adding a Time Start to WordPress Media Embeds

Ever have those times that you’d like to share a piece of media but have it start at a particular time? I did recently, and figured I’d share my solution.

It turns out, WordPress does not support this feature out of the box (though you could argue, theoretically, that it should).

We just remembered the 50 year anniversary of the Selma march which was nicknamed Bloody Sundy as 600 civil rights marchers were attacked viciously by law enforcement in 1965. It seems appropriate to sample the MLK “I have a dream speech for this demo.

Now of course, it’s all a great speech worth listening to, but what if I want to start the audio at the place we all know?

Boom, just like that. The nuts and bolts of this are tied up in this code:

Simply, I filter the shortcode attributes for the audio and video shortcodes adding a new argument – “start”. This is in seconds.

The second adds a little snippet of Javascript after each embed that moves the internal time pointer to the appropriate spot in the supplied media.

Caveat: This will not work for media that is simply cut and paste. While WordPress will translate appropriate media URLs into embeds, it does not pass anything more than the required `src` argument.

Full source code, as a WordPress plugin, can be found on Github. (Pull requests encouraged)

The Internet is About to Become WAY Faster

Earlier this week, the big news in the tech space surrounded the completion of the HTTP/2 Spec.

Gibberish, gibberish, gibberish.

What does this mean for the internet? The short version is: it’s about to become way faster.

Faster is extremely important if you want to make money from traffic to your site. Or, you know, if you use the internet at all. No one wants to wait for a website that just sits there and spins while it’s trying to load. We all hate that. And importantly, Google hates that.

Several years ago, Google invented and implemented the SPDY protocol. Simply, SPDY allows for the compression and efficient transmission of requests between browser and server. I’ll get into the technical details later, but for the sake of summarizing why the Internet is about to get faster… Google’s SPDY technology is the cornerstone of HTTP/2.

Now that the spec is finalized, it goes to editorial for cleanup and publishing… but the nuts and bolts of the spec will not change going forward. That means browsers and servers can start rolling out these changes as soon as… today.

Technical explanation

If you are not interested in the technical explanation for HTTP/2, please skip to the next section. I don’t want you falling asleep and drooling on your keyboard.

In the original days of the internet, there was the HTTP/1.0 spec. This spec defined how clients (browsers) and servers communicated over a network. We still use 1.0 quite a bit today, though 1.1 is the current preferred.

When it comes to HTTP, the concept is simple… a client requests a resource (image, html, mp3, whatever) from a server, the web server interprets the request, goes back into a storage closet, finds the resource, has the requestor sign for it and then sends the resource on it’s way back to the client. A simple understanding is….

BROWSER: “Hey, server… can I get that image named image.jpg? You should find it in this folder.”

SERVER: “Sure, let me go look. Oh, here it is. There you go”

BROWSER: “Thanks, dude”

If the server can’t find the image in the directory, it sends the client a 404 (Not Found), but that’s just a sidenote.

HTTP/1.0’s Problem

The problem with HTTP/1.0 however, was that it only allowed for a single request on a single connection to the server. To put it in another way, The web page has 10 images on it. In order to get those 10 images from the server, it would have to send 10 requests. That creates a lot of requests for the server and if the server wasn’t optimized for that kind of capacity, it could crash… or at least be in the weeds. It was bad all around for bandwidth as well. All of those requests add up to high bandwidth costs!

So God gave us HTTP/1.1.

HTTP/1.1’s Problem

Given this inherent problem with HTTP/1.0, HTTP/1.1 enhanced the original spec by adding the concept of pipelining. Imagine, if you will, a highway tunnel. Generally, there’s no passing in a tunnel. While HTTP/1.0 only allowed a single car through the tunnel at a time, HTTP/1.1 allowed multiple cars in the tunnel, but dictated no passing. And because the web server on the other end of the tunnel can only process requests as they come in, you end up with a stacked up queue of requests waiting to get processed and… you still have the same problem where the server gets in the weeds and slows down.

In both the case of 1.0 and 1.1, server technology evolved to allow concurrency of requests. This gave us multiple lanes in the tunnel, but 1.1 still dictated no passing. So requests in one lane, had to stay in that lane but there could be more than one lane which allowed us to bandaid the inherent weakness in the HTTP/1.x stack.

Enter HTTP/2

When Google started giving SEO benefits to sites based on speed, they also ate their own dog food and invented SPDY. SPDY allows for compression of resources in a much more efficient way if both server and client supported it. It also allowed for single requests to get many resources at a time. That page that had 10 images and had to make 10 requests for those 10 images could now make a single request to get all 10 images at once. Efficiency, I tell you.

As with any working group, the task force that put together HTTP/2 had representation from Google. Google, as a good citizen, shared it’s knowledge and spec for SPDY with the working group and it became the basis of HTTP/2. In fact, Google will now eliminate SPDY in favor of HTTP/2.

In fact, clients are supporting HTTP/2 now. Well, a lot of them are anyway… and that’s because of Google’s implementation of SPDY. Internet Explorer 11+, Firefox 36+, and Chrome all implement SPDY-HTTP/2 support, but none are currently enabled by default. Safari and Mobile Safari will likely soon get the support.

Most web servers also implement SPDY-HTTP/2 with the exception of lighttpd.

What does it mean to me?

The new HTTP spec is probably not anything you need to worry about at this point. System administrators will want to make sure their web servers are up to date and their TLS certificates are upgraded. Though the working group does not require HTTP/2 to use TLS, I’d expect most server manufacturer’s to require them in their own implementation… for security reasons.

On the client side, HTTP/1.1 still works. The working group was very careful to ensure backwards compatibility with prior versions of the spec. So if your browser makes a 1.1 request to a 2.0 server, the server will still answer in 1.1 with the same limitations I described above.

As developers, we will most likely want to use 2.0 when we can. The finalization of the spec is so new that it remains unclear what that means yet. For instance, what does this mean for the WordPress WP_Http class? Probably nothing in the short terms, but I’d expect enhancements to start rolling in as optional “toys” for developers.

Are you a developer or engineer? What are your thoughts on the new spec?

Looking for a Top Notch WordPress/PHP Developer

If you’re in Baltimore and are a developer, or if you are in Baltimore and know someone who is a developer… Heck, if you’re in DC and are a developer or know a developer, we need you. (You can be to work in under an hour on the MARC train).

Some of you know what I do and who I do it for. I work for a company that has consistently been rated in the top 3 companies to work for. We’re fun and relaxed and our content producers focus on publishing in the financial industry.

Dogs are regularly in the office. We wear shorts and sandals to work. It’s an a-political group – as in office politics. Everyone works well together from the execs down to customer service.

We believe in “Fail cheap and quick” as a lean startup sort of mentality and everyone is empowered to just try stuff if it makes sense.

What *I* do is build awesome web technology to support the business. Plenty of WordPress but now we’re building out huge APIs for reporting and consumer-facing tools. And that’s not WordPress. That’s Laravel and MVC, if you’re curious.

We are looking to add another developer with real chops. PHP, JS, REST APIs, SQL for now with NoSQL as a viable thing for the future. We largely operate on Rackspace and Amazon EC2.

I’d love to hear from you or your developer friend. Send me your resume and cover letter but let me see your github as well!

abrazell@agorafinancial.com

Sublime 2 Power Tools

This is a very advanced technical article.

For years, as a developer, I used the fantastic Textmate software for writing code. I got used to it. It’s a power editor for Mac OS X and has bundle support (think of bundles as extensions or plugins) that enhance the functionality of the software) for just about every technology, from Subversion to Git to a bunch of things I don’t use in a PHP environment like C/C++ mallloc (memory allocation), Python, Ruby, etc. It’s even got a WordPress bundle!

The problem with Textmate, however, is that active development is slow. Like, extremely slow. Like, molasses slow. After five years of using version 1.5x, an alpha version of 2.0 finally emerged last year. It’s still in alpha. Pace of development is still painfully slow, and what is in the 2.0 alpha version is not ground-breaking compared to what is in the current stable version.

Along came Sublime 2. This is, by far, my favorite text editor ever. I’ve been using it for about six months. It emulates virtually everything Textmate does. Textmate does snippets (think of them as macros). Sublime 2 also does snippets and supports the Textmate style. (Hint: If you’re a WordPress developer, my favorite – and still most commonly used – snippet comes from Mark Jaquith who wrote this snippet to create WordPress widgets on the fly. It works in both Textmate and Sublime 2).

The great thing about Sublime 2 is that it is truly a hacker’s paradise. All the config files are JSON objects, so if you can write JSON, you can configure Sublime 2. None of this namby pamby UI/click/select from dropdown bulldookie. Write your code and mean it. Related is that the master configuration file is extremely well documented and you can override everything in it, not by editing this file, but by providing new values in the user configuration file.

Ok, let’s back up and get y’all up to speed on what I do when configuring my Sublime 2 environment.

Config Files

First, I recommend you look at the entire Default configuration file. Read all the settings and comments and understand all the possibilities you have. Your most comfortable environment won’t be mine. For me, I see the following configuration settings that I’m going to want to override. Keep in mind, I never edit the default configuration file. It gets overwritten on upgrade.

To access this file, go to Preferences >  Settings – Default 1.

Note that I have included the related Sublime 2 default comments along with the settings I wish to override.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// While you can edit this file, it's best to put your changes in
// "User/Preferences.sublime-settings", which overrides the settings in here.
//
// Settings may also be placed in file type specific options files, for
// example, in Packages/Python/Python.sublime-settings for python files.
{
// Note that the font_face and font_size are overriden in the platform
// specific settings file, for example, "Preferences (Linux).sublime-settings".
// Because of this, setting them here will have no effect: you must set them
// in your User File Preferences.
"font_size": 10,

// OS X only: When files are opened from finder, or by dragging onto the
// dock icon, this controls if a new window is created or not.
"open_files_in_new_window": true,

// Characters that are considered to separate words
"word_separators": "./\\()\"':,.;-<>~!@#$%^&*|+=[]{}`~?",

// When drag_text is enabled, clicking on selected text will begin a
// drag-drop operation
"drag_text": true,
}

These settings and their related comments may seem self-explanatory, but in case they are not…

font_size: This setting controls the font size in the editor. Derp.

open_files_in_new_window: As a developer on an 11″ MacBook Air, I hate this setting. As the name suggests, everytime you open a file, it’s going to be in a separate window. This may be okay if you have a ton of screen real estate, but if you don’t… well, I like to have windows open up in a new tab of my editor so I can access them quickly and easily without consuming precious real estate.

word_separators: This is a list of characters that serve as word separators. I don’t mean code word separators. We’re talking about in the editor. I want to be able to click a CSS selector that often comes with a dash in the middle, and highlight/select the whole selector. By default, if there’s a hyphen, only the portion of the word clicked will be highlighted.

For instance, if a <div> has a class="foo", and I click on foo, foo will, by default, be selected. But if that div has a class="foo-bar", then clicking on foo will only highlight/select foo (up to the hyphen) and not all of the, more contextually accurate, ‘foo-bar’. In my user configuration file, I’m going to remove the hyphen, and thus remove this annoyance from my life.

drag_text: This is an edge case setting, but it has bitten me a few times. If you’re in a window in Sublime 2, and you have a block of code selected, when this default configuration is in play, you can drag that text into another window. I can see the use for this, but it’s also thrown me for a loop more times than it’s been useful. I override this to prevent that from happening. If I really want text in another window, I’ll jkust do the traditional copy and paste.

Overriding Defaults

Knowing I want to change these settings, I can write my own JSON object into my User configuration (Preferences > Settings – User):

1
2
3
4
5
6
{
"drag_text": false,
"font_size": 15.0,
"open_files_in_new_window": false,
"word_separators": "./\\()\"':,.;<>;~!@#$%^&*|+=[]{}`~?"
}

Easy Peasey!

Installing Packages

Where Textmate had Bundles, Sublime 2 has Packages. Packages are extremely powerful.

NOTE: Install this first 2. Trust me. And get familiar with this.

There are a million and one different packages out there, depending on what your needs are. Installing a package is as simple as going to Preferences > Package Manager > Install Package. Note that you can also add new external repositories of external packages that Sublime 2 can also search.

Sublime 2 - 4 Pane Grid View
Sublime 2 – 4 Pane Grid View

Summary

Sublime 2, of course, has hundreds of different setups. It kinda just depends on your taste and not being afraid to try things. Because everything is based on text file configurations and settings, everything can be reversed. Don’t be afraid to break things. You can always back out. You can even set it up so that you have multiple files open in the same tab. Set it up the way you want it and go be more productive!

Notes:

  1. Sublime 2 works on Mac OS X, Windows and Linux. All options will be similar, if not identical, to what I’m providing here from an OS X perspective. If you can’t find what I’m referring to, think about where logically it might be in your menus.
  2. Specific installation instructions can be found here.

Working With HTML5 Forms

html5I’m going to start a series of tutorials over the next weeks and months about HTML5. A lot of web developers are not leveraging HTML5 for a variety of reasons. We have been so trained over the past decade to embrace XHTML 1.0 that we’ve avoided the new DOCTYPE as something new that needs to be learned.

The good news is, XHTML is still valid in HTML5. The better news is now you have much more fun toys to play with.

Admittedly, I was one of those people who delayed jumping on the HTML5 bandwagon. In the past few months, however, that has changed. This series of articles will hopefully help the web developer to rethink how they develop on the web. Much of the stuff I’m about to talk about does not require a lot of extra heavy lifting.

Use the Correct DOCTYPE

Just as a remedial exercise of laying out the premise, your HTML must have the correct DOCTYPE. In XHTML 1.0/1.1, the first line of the HTML page had to be something along these lines

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

That’s relatively confusing, huh? Makes you want to go drink spoiled milk with lumpy crud in it just because it’s tasty, right?

To declare a web page as HTML5, you do the same thing you did with the old 1990s era HTML4, before the web embarked on the XHTML idea of doing work. HTML5 is, essentially, a reset to HTML4 with all kinds of additional goodness. You simply start a web document with:

<!DOCTYPE html>

A lot easier, right? Heck, you can type that in your sleep once you’ve typed it enough (I know you already do that with your drivers license and credit card numbers).

Form Field Types

With all that remedial knowledge in play, let’s take a look at HTML5 forms. The importance of this might be lost if the only thing you think about, when building HTML pages, are computer browsers. But if you recognize we live in a mobile world, you own an Android or iPhone and have tried to do any kind of form filling on those devices, then you might start to realize the importance of field types.

In XHTML, you might have a form that looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<form action="" method="post">
    <label for="name">Full Name:
        <input type="text" name="name" id="name" />
    </label>

    <label for="phone">Phone Number:
        <input type="text" name="phone" id="phone" />
    </label>

    <label for="email">Email Address:
        <input type="text" name="email" id="email" />
    </label>

    <label for="website">Web URL:
        <input type="text" name="website" id="website" />
    </label>
</form>

In XHTML, we didn’t have a lot of field types. We had text (which everything above is), hidden, password (*’s entered in the input), checkboxes and radio buttons. You could add other types of inputs (That don’t use the <input> tag and include <select> and <textarea>.

This works in HTML5 too, but you’re limited by one default keyboard – which is fine, but fairly bland and not at all contextual.

What would happen if we changed that form to use different field types? HTML5 support a bunch. The four fields above can more sematically have the following types, in order: text, tel, email, url.

Watch what happens on the iPhone when the HTML looks like this (Android is similar):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<form action="" method="post">
    <label for="name">Full Name:
        <input type="text" name="name" id="name" />
    </label>

    <label for="phone">Phone Number:
        <input type="tel" name="phone" id="phone" />
    </label>

    <label for="email">Email Address:
        <input type="email" name="email" id="email" />
    </label>

    <label for="website">Web URL:
        <input type="url" name="website" id="website" />
    </label>
</form>

For a standard text field, your keyboard will look like this:

iOS "text" field
iOS “text” field
For a phone number, using the tel type:
iOS "tel" field
iOS “tel” field
For an email address, using the email type:
iOS "email" field
iOS “email” field
And for a URL field using the url type:
iOS "url" field
iOS “url” field

There are, of course, other field types that I’m not going to go into too much here. But to whet your appetite, there is a color type that attaches to a color picker. There’s a date type that binds to a date picker. There’s even a range type which binds to a slider picker.

Important: Not all browsers support all types. In the event that a browser does not support a specific type, it falls back to standard text type and you can bind other external Javascript to make the same functionality happen.

Reference: All HTML5 field types with browser support.

Form Field Placeholder

Another useful feature is the placeholder. In XHTML, we might have a form that looks like this:

1
2
3
<form action="" method="post">
    <input type="search" name="search" id="search" value="Search for your term" />
</form>

This would create a simple field that would be pre-populated with “Search for your term”. From a usability standpoint, when a user brings that field into focus, the text is supposed to disappear and allow the typing of a search term. If nothing is typed and the focus is switched to a different element, then that phrase should re-appear.

XHTML Placeholder Text
XHTML Placeholder Text

You can’t do this without a little Javascript help (I like jQuery for this) – which is outside the scope of this article. But in HTML5, you only have to add placeholder="Search for your term". Different browsers handle this slightly different, but they all insert some dummy text that can be replaced by the user’s own input.

1
2
3
<form action="" method="post">
    <input type="text" name="search" id="search" placeholder="Search for your term" />
</form>
HTML5 Placeholder Attribute
On iOS, the Placeholder attribute plays light grey text in the field that is replaced as the user types.

Form Field Validation

Validation is such a tedious thing for developers. You can do all kinds of ugly things to make sure fields that are required actually have a value or that a field meets a certain criteria (for instance, a zip code field having 5 numeric characters to match the U.S. format).

In terms of requiring a field, it’s as simple as adding required to the input tag. In HTML5, you don’t have to have an explicit value for an attribute as you do in XHTML. You can if you want, type <input type="text" name="zip" required="required" /> but this is a habit that does not need muscle exercise. Just use:

1
2
3
4
<form action="" method="post">
    <input type="text" name="zip" required />
    <input type="submit" />
</form>
Firefox "Required" Error Bubble
Firefox “Required” Error Bubble
Chrome "Required" Error Bubble
Chrome “Required” Error Bubble
Browsers handle this differently but they all pop up a notice if the field isn’t populated on submission. On the right, you’ll see how Chrome and Firefox handle this respectively.

Let’s validate that zip code field, though, because this is where HTML5 really shines.

Using the pattern attribute, you can designate a regular expression to match formatting needs. If we want to limit the zip field to 5 numbers (most simplistic example – it could also have a potential extra dash and 4 numbers too), you might use this HTML:

1
2
3
4
<form action="" method="post">
    <input type="text" name="zip" required pattern="\d{5}" />
    <input type="submit" />
</form>

You can find a list of helpful regexes at html5pattern.com.

Summary

There’s a lot more we could get into here, but the point of this exercise is to prove that it doesn’t take much to start using HTML5 in development. Doing so will also push the boundaries of what has been more commonly possible and the barrier to entry is so low that I struggle to find a reason why HTML5 should not be used more commonly.

I’ll have more of these in the days and weeks to come so stay tuned, subscribe to the RSS feed and, as always, if you’re interested in hiring me for a full time gig or contract basis, please reach out to me. I am actively looking.

HOLIDAY WORDPRESS DEAL: 30 Minute WordPress Consultation

As the holidays kick into full gear, and people start looking at a short sprint to gift times with family, I am offering a 30 minute phone consultation related to WordPress for $100. This is a great thing for someone who needs to figure out how to do something that may be unfamiliar for them or if they are just getting setup with WordPress and need plugin recommendations, or the like.

To setup your 30 minute appointment or to inquire about gifting that appointment, fill out this form. For the description, just reference this deal.

For longer term commitments or consulting engagements, including custom plugin development, I am booking clients for Dec and Jan, so feel free to ask about those opportunities as well.

This offer is only good today, Friday Nov 23, 2012 until midnight Central Time.

This offer is good through Midnight, Monday, November 26, 2012 – Cyber Monday.

Most Commonly Used Git Commands

A lot of chatter about using Git and Subversion from the command line versus clients. Folks, take your time and learn the command lines. There’s a lot of stuff you can use the UI clients don’t always wrap into UI. Things like post-commit hooks, etc make the command line way more pure and powerful.

Here’s the same list for Subversion.

But for Git/Github, you can get most of what you need out of git clone, git commit, git push, git pull, git status, git diff and git merge.

Learn these and you won’t know everything about git, but you’ll be most of the way there.

Most Commonly Used Subversion Commands

A lot of chatter about using Git and Subversion from the command line versus clients. Folks, take your time and learn the command lines. There’s a lot of stuff you can use the UI clients don’t always wrap into UI. Things like post-commit hooks, etc make the command line way more pure and powerful.

Here’s the same list for Git/Github.

But for Subversion, you can get most of what you need out of svn co, svn ci, svn commit, svn diff, and svn status.

Learn these and you won’t know everything about svn, but you’ll be most of the way there.