Chris Van Patten versus The World

Theme wrappers sans spanning

Chris — Fri, 27 Apr 2012 13:52:20 +0000

Last night at the Buffalo WordPress Meetup I did a little talk about theme wrappers. I briefly alluded to the dangers of tag spanning but didn’t follow up on it, and when I live-converted a theme to use theme wrappers I didn’t convert it to the format I typically use that repurposes header.php and footer.php to help prevent tag spanning. I thought I’d go over it here to help clear that up!

In the final example I showed, where I converted a site to the theme wrapper method live, tag spanning was still in place because I used the get_header and get_footer functions for their typical purpose (and the way I had originally used them in the theme). This is totally okay if that’s how you like to work, but I actually ended up modifying that base.php file this morning to make it a little more sane.

Here’s how you can do that too.

First, create a new file: head.php. Head.php is a partial that contains the entire content of the HTML tag, and the opening and closing tags themselves. Now where that markup would normally be included in header.php, I just add to pull in the head.php partial.

There’s no real reason to do this other than keeping a lot of code out of my base.php file and keeping things a little cleaner. I think it just overall makes it easier to parse through a file and get to relevant content faster, but that’s just me. And because the tag gets opened and closed right within the head.php partial, you don’t have to worry about spanning. I also like it because I can easily copy head.php between projects that often start with the same basic needs.

Now in your header.php file, copy everything over to your base.php. Keep you header.php file, you’ll probably want it, but ignore it for now. Replace your call to get_header with what you just copied. Do the same with get_footer and footer.php.

So now your base.php file is a whole lot bigger. But we can trim it back down by looking in your header and footer (in your markup, not those files yet) for the actual header and footer markup that closes itself. That’s what you want to copy back into your header and footer files, and replace that markup in your base.php file with get_header and get_footer.

Here’s a gist that shows the finished base.php.

I hope this makes some sense. Let me know if you have any questions and what you think of this method!

Even better DRY for WordPress

Chris — Wed, 25 Apr 2012 15:07:03 +0000

So I posted a week or so ago about DRY themes for WordPress. Turns out, this has been done already (I thought it might have been), and in an even more awesome way that avoids my conditional-filled logic statements.

Check out scribu’s Theme Wrappers, the most brilliant handling of this issue yet.

With a little bit of extra code in your functions.php file (or in a plugin–after a little more testing I’ll probably incorporate this into the rach5-helper) you have a perfect setup that lets you define a base php file (wrapper.php in his example, but I prefer base.php) and use WordPress standard template names to fill in the gaps, saving you time and energy and keeping you from needing to maintain a 20 line conditional check.

This is an awesome system and absolutely worth checking out if easily maintainable themes is something that matters to you!

DRY WordPress Themes

Chris — Fri, 20 Apr 2012 17:54:10 +0000

I’ve been working out a new process for developing WordPress themes and I wanted to share it here before I take it over to the Van Patten Media blog. I’d love to get feedback and tweak it as much as possible!

I’ve been developing WordPress themes for a lot of years–almost as long as I’ve been doing professional web development. One of the biggest problems I’ve run into (especially lately) is writing themes that are easily maintainable.

Sass and Compass have helped in the style sheet department (see my introduction to them) but the WordPress themes themselves still are full of heavily repeated content. What do I mean?

Well, a WordPress theme generally has a few base items:

index.php
page.php
single.php
header.php
footer.php
page-{your-template}.php
etc.

“So where’s the problem?” you might ask. “Your header and footer are included in every file, and that solves every problem.” Yes, but I have one requirement that stumps things: I want no tags spanning across files.

What do I mean? Simple: if I open a

in one file, I don’t want to close it in another. And with header and footer.php files, that’s exactly the situation you end up in. You probably open up your , , and a number of wrapper

That gets unmaintainable quickly when you’re bouncing between multiple projects a day and don’t remember what the third closing div tag lined up with in your footer.php file. So I’ve implemented a new system, visible in the most recent Rach5 commits.

This system forgoes the traditional page.php and single.php templates, and instead makes extensive use of conditionals called from index.php. Now if you are familiar with the WordPress template hierarchy, you know that conditionals in an index file are doing double the work, as WordPress has already tried to find an appropriate file. But by putting the majority of your theme structure in index.php (think of it as your base file) you save yourself a massive amount of work down the line.

You can see in the gist how my files are laid out: header.php now includes the visible header within the tag. And I’m now using a new template part, head.php, to serve the tag. You can see an example of the head.php from Rach5 here (Note: with this method, you could easily include the tag directly in your base file, but I choose not to for maintainability reasons).

Then every time I want to include new content in the “content area” of the site, I have conditionals that determine which file to include. I have two default loop files, loop-page.php and loop-post.php which handle basic loops, and a pg-front.php template part. Calling these conditionals from here causes some extra logic to be executed (duplicating logic that WordPress executed previously, in a way), but caching will make that negligible, and this means I can minimize duplicated template code.

I’ve only loosely sketched out the concept, but you can see it and try it for yourself by downloading the latest Rach5. I’d love to hear what others think!

Sexy Style Sheets with Sass (and Compass)

Chris — Sat, 14 Apr 2012 20:23:55 +0000

Today at BarCamp Rochester I gave a talk outlining some of the awesome features of Sass and Compass (the style sheet preprocessor and the preeminent framework built for it, respectively) with lots of examples and lots of code.

The slides are online here (built with DeckJS). They discuss some basic Sass features and some additions Compass brings to the table as well.

Considering the fairly dense nature of the material and the speed I had to rush through them, I think the talk was fairly well received. If I could have another go (and I may soon) I would consider reformatting the presentation so it’s less “here’s a feature, here’s another feature, and yet another feature” but instead connects the features so you get a better sense of how they’re used in a workflow. Demonstrating the process of building of a page in realtime with Sass and Compass would be more fun and accomplish this, but it would have to be carefully scripted.

I left out three major things in the discussion (but touched briefly on one of them):

Partials
Sass vs. SCSS syntax
Getting started (installation for Sass and for Compass)

I’ve linked to some resources above that will guide you to the right places for beginning your own exploration of those topics.

I had a great time at BarCamp Rochester, reconnecting with folks from the Rochester tech community and hanging out with friends from Buffalo. And the swag is awesome: I walked away with three new t-shirts (thanks BarCamp Rochester, Puppet Labs, and Stack Overflow!), many new stickers (thanks jQuery UI, Puppet Labs, and Stack Overflow!) and a killer beer stein (thanks Stack Overflow!).

I’m already looking forward to the next BarCamp, and hopefully we can get one running in Buffalo regularly again soon!

Thoughts on licenses

Chris — Mon, 09 Apr 2012 00:02:37 +0000

I was going to write this post here, then I thought I’d post it at the Van Patten Media blog, then I changed my mind and cancelled the whole post. Finally, I’ve decided to write a shorter version of my thoughts here. Bear with me.

I’ve been thinking a lot lately about open source software licenses. Aside from using open source all day err’ day, Van Patten Media has also released several open source software components; most of these in connection with WordPress.

So why think about licenses? Well, they’re the framework that defines a piece of open source software. Essentially they are what opens it. And when VPM has been so active in ensuring compliance with the open source ecosystems we’re apart of (our publicly available plugins and theme utilities are entirely GPL or GPL-compatible, as circumstances dictate) I get annoyed when other services in this same ecosystem (the WordPress ecosystem, usually) violate what I believe is the spirit of the GPL, the license that governs most WordPress activity.

What leads me to feel this way? Three things:

Dual-licensing of themes.

Admittedly the Software Freedom Law Center has given the thumbs-up to dual-licensing themes, under the logic that the PHP files require WordPress to run, but the CSS/images/javascript can stand alone. They have valid technical reasons for their assessment of why PHP code in a theme is assuredly GPL, but I think their analysis of static content is critically flawed.

Much in the same way that removing WordPress removes the functionality of a theme, removing a theme’s static content removes the very essence of what makes it unique and usable. Without (at the very least) CSS, a theme can hardly be considered a “theme” at all. And the GPL has this important passage:

If identifiable sections of that [modified] work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License

This is taken from section 2, which is the section that initiates virality. And to my mind, that passage sets it up quite clearly that GPL is all or nothing, unless the components are distributed separately. (The emphasis above is mine.)

Misleading users

This one is a personal pet peeve. Certain theme repositories that will not be named lead users to believe that their WordPress theme purchases can only be used a limited number of times before they must purchase new licenses.

Remember how WordPress themes are GPL? Even if you don’t share my opinion that all components of publicly distributed themes should be GPL (and admittedly, many do not) this practice is still misleading. While you may be restricted by a secondary license on reuse of static content, make no mistake: you can use theme PHP files as many times as you want to. Any copy that confuses users and leads them to believe otherwise is morally suspect and just plain shady.

Paywalls

This last issue is another one that bothers me (and I know others): the issue of the paywall. It’s an incredibly touchy issue, as paywalls (or perceived paywalls) are probably the number one way WordPress developers can create quick revenue streams.

My concern is that paywalls, in congress with the issues I’ve mentioned above, are antithetical to the openness and virality that the GPL is designed to promote.

Yes, the GPL permits charging for distribution. The GNU website even has a fascinating article encouraging individuals to charge for their open source software. But it’s key to understand their perspective: they’re encouraging you to charge so as to support the community around the program and donate to future developments. In fact, their article assumes you’re charging for redistribution. In their scenario, the software is already out and available in the public sphere, ready to be used and picked apart by those with the know-how. As a redistributor, you’re just helping to make it more readily available.

In the WordPress ecosystem, this is rarely the case. Software developers are the distributors, so you have no choice but to pay to get it from the source. While this is permitted by the letter of the license, I think it’s a violation of the spirit of the license, which is designed to perpetuate the spread of free software, not lock it behind a door.

To me, the paywall is the manifestation of an attitude I get from many WordPress theme and plugin developers: the GPL (and licensing) is just an inconvenience; a requirement from on high to satisfy some arcane legal nonsense. To me, the paywall is the physicalization of the search for loopholes in the license so you can squeeze more money out of your end users while consolidating control and restricting access.

And furthermore, I’m frustrated by the services that refuse to sell me a theme or plugin without also selling me some sort of support package that I don’t need. Frankly, I’m not sure that is at all within the letter of the GPL. Forcing me to buy bundles with support and plugin access is price gouging, and taking advantage of end users. Sell support separately.

Ultimately…

I would love nothing more than to see plugin and theme developers start developing their wares out in the open on Github or their own code repositories. I would love to see “purchase upgrades” or “buy this theme/plugin” become a thing of the past.

The emphasis should be on personalization. Upselling is the name of the game, right? Instead of asking users to spend $200 on a theme, why not spend $200 and take an hour or so with every user to actually help them get their website live. Offer more than just “support when it breaks” but “support before you need it.” Be the concierge for your product.

Admittedly my opinions on licensing are a bit extreme in the WordPress ecosystem. Even some members of the core team have expressed opinions that are contrary to my own. And that’s okay.

But when you set out to make a buck, and you’re doing it on the backs of hundreds if not thousands of folks who collectively built a piece of software that your creation depends on, give it some thought… are you making your thing in the most ethical way possible? Are you treating your customer with respect and without misleading them? Are you contributing to the software ecosystem that you’re apart of?

If you can’t answer yes to those questions, you may need to stop and seriously re-examine your approach. I know we have at Van Patten Media, and I sleep better at night for it.

Local WordPress Development Dilemma

Chris — Fri, 06 Apr 2012 03:24:06 +0000

My current web development workflow is a little sloppy, I admit. Traditionally, you have four stages: dev, QA, staging, and production. My workflow completely eliminates one of those stages (QA) and combines two (dev and staging are just one stage for me). And–the pièce de résistance–I don’t keep my combined dev/staging setup on my local machine; it’s all on my remote server.

Sure, it works… but it’s not ideal (as Paddy has been very quick and all too eager to point out). And as I’m on the hunt for a new text editor (my beloved Espresso 1.x is not Lion-friendly) and get to know Git better, I’ve decided to overhaul my development workflow (and eventually institute the changes across Van Patten Media… I’m sure Peter will be happy to see me attempting to standardize this process a bit!). The goal? Local dev, remote staging and production, with deployment between the three handled by Git and Git hooks (as much as possible) with Vagrant handling the local server environment (as opposed to MAMP or something like that).

Now the conventional wisdom is “just install WordPress and go wild!” But remember–Van Patten Media is primarily dealing in WordPress, so there are a few hiccups along the way (I love WordPress, but it’s making this a pain in the neck!). Among them:

WordPress sets the site URL in the database… so every time I want to push database content between dev.*, staging.*, and the production site, I need to change that item in the database.
Whenever you insert an image in the editor, it uses the absolute URL (e.g. site.com/path/to/image.ext). Remember that last item? Same situation, but even more fun: I’ll need to scan every post for the site’s hostname and switch it out based on whether I’m at dev.*, staging.*, or on production.
I like to arrange my WordPress projects in a specific way, because I often have custom humans.txt/robots.txt files and maintenance.php files that live outside the theme root. You can see an example of this at the Github repo for the Van Patten Media website.
I absolutely do not want to keep WordPress core (or plugins) in version control. WordPress core needs to be managed separate for each website, and plugins as well (updates to custom developed plugins are handled by a local update API I have in place).

If you’re doing a little critical thinking, you can see where things start to fall apart… it’s all in steps 3 and 4. It should be easy to handle database syncing with tools like Liquibase or database diff tools (and that’s really only for merging staging into production, I think). The problem is what files I like to keep around, and what files I don’t like to keep around. The natural solution would be just to set up a WordPress install and symlink the theme folder, but remember how I keep other things around outside the theme folder? Enter frustration, stage right.

So I appeal to you, internet community. What’s the best way to handle this sync? The ability to have a local Vagrant-managed replica of my server, send the vagrant up command from a project directory, and get a fully working dev environment without ever seeing a WordPress core file is my ideal situation.

And then of course, that introduces another question–how do I handle this sync up to the server (and between staging and production)? It’d be one thing if I just had the remote theme folder set as the Git remote, but, again, that’s just not how I’m handling things. Ideas?

Thanks!

Quick Suitcase Fusion 3 tip

Chris — Sat, 17 Mar 2012 21:58:27 +0000

I was working on a mockup today and got this message while in the process of activating a font in Suitcase Fusion 3, my font manager of choice (well, by necessity, but that’s another story):

Suitcase Fusion Client encountered an unexpected error. 83914764

Google lead me to a forum thread that discussed the issue, but I wasn’t too interested in accepting the thread’s “reinstall the program” advice so quickly.

After a bit of playing, I found a solution that was a lot more painless. No guarantees it will work for you, but it’s worth a shot!

Simply open your Suitcase Fusion 3 preferences (⌘+comma), navigate to the Type Core tab, and click the Stop FMCore… button. That will kill FMCore (the process that handles type activation when Suitcase Fusion is closed) and Suitcase Fusion itself. Then just open Suitcase Fusion again to restart FMCore.

If your setup is anything like mine, you’ll be back in business, error-free!

Europics

Chris — Sun, 19 Feb 2012 16:18:48 +0000

For the curious, nosy, or just plain bored, I’ve posted pictures of my December/January trip to Europe (primarily central/south Italy) on Picasa.

The pictures are broken up into three galleries:

All the pictures were taken from my phone, a rooted HTC Thunderbolt (affiliate link). For the majority of the trip I used the stock camera app, but midway through the trip (I believe in Rome?) I installed HDR Camera+ which got impressive results.

Van Patten Media goodies

Chris — Sun, 05 Feb 2012 05:23:22 +0000

Van Patten Media has really been busy lately!

I just posted our second week in review. See what we’ve been up to the past seven days (and if you really care, the seven days before that).

For those who don’t know, Van Patten Media is the website design firm I run. We’re targeted toward actors and theatre people, but have worked and continue to work with just about anyone. We also have a strong commitment to the open source software community. And we love WordPress.

We’re available for March and beyond – feel free to contact Van Patten Media directly for more info.

Comma-separated tagging in the Delicious Chrome extension

Chris — Tue, 31 Jan 2012 02:47:24 +0000

Do you use the Delicious extension for Google Chrome? I am (still, 6 years later) a Delicious-lover, but the Chrome extension has been–admittedly–neglected while the team builds up other elements of the service to modern standards.

The current plugin is a rebuild of the previous plugin that works with current APIs, but still has a few holdovers from the Yahoo days. Unfortunately, one of those holdovers is the enter-to-autocomplete function, which still retains the space separator instead of the recently instated comma separator. Fortunately, it’s a quick fix. Follow the steps below to make enter-to-autocomplete easy again!

Fixing enter-to-autocomplete

First you need to find where the extension is located on your computer’s hard drive. Here are some probable paths:

Older Windows: C:\Documents and Settings\*UserName*\Local Settings\Application Data\Google\Chrome\User Data\Default\Extensions
Windows 7: C:\Users\*UserName*\AppData\Local\Google\Chrome\User Data\Default\Extensions
Mac OS X: /Users/*UserName*/Library/Application Support/Google/Chrome/Default/Extensions

You’ll need to figure out which folder is the Delicious extension next. Take note of the ID: mnaelnkmidnndgikjbiifihgklnocljdTo check yourself, open your Chrome extensions list by clicking here (careful, it’ll take you to a new window). Find the Delicious extension in that list, and click the arrow to see a few more options appear, as seen in this picture:
See that ID? That’s the folder you want in your Chrome extensions directory. Open it up, and you’ll see another folder (hopefully called 1.1_0). Open it up, and you should have a list of files that looks something like this:
Still with me? Great! Now we’re at the good part. Open the file called del-chrome.js in your text editor of choice.
Search for the text “delimChar” – there are two instances of it in the file, one at line 838, and another at 1052. It’s pretty easy to guess what delimChar does – it sets the character that delimits the tags! Here’s how it looks now:
```
delimChar : " "
```
And here’s what you should change it to:
```
delimChar : ","
```
Got it? Changed in both places (lines 838 and 1052)? Perfect. Save that file. You’re almost done.
Restart Chrome! That’s it! You’re done! Open up a page and enter-to-autocomplete to your heart’s content.

Hopefully Delicious launches an updated extension quickly, but in the meantime this is a quick way to speed up your tagging and bookmarking.

Thanks for stopping by, and let me know if you have questions in the comments below!