Tag: essay

Entry Level Hosting

I’m going to preface this entire post with a statement that may annoy my boss: I don’t care who you pick for a webhost, I care that you pick the right host for your needs. With that in mind, I won’t be naming hosts by name.

But explaining what that means is complicated and weird, so let’s go through the ‘entry level’ hosts and what all this means for you, but also for your clients. After all, part of helping people get set up on a new webhost means actually helping them figure out what they need, and getting it installed

What is an ‘Entry Level’ Host Anyway?

The basic definition here is the smallest, cheapest, least robust hosting you can possibly get.

In general, this is where we all start. We need inexpensive hosting because we don’t know how much the site we’re proposing to build is going to need. To be honest, I detest being asked to ‘spec’ something with regards to hosting. “How much do I need to run a community site for..” Couldn’t tell ya. In fact, really, no one can tell you. It’s like “How much gas do I need to drive from Chicago to Cleveland?” I did it on one tank in my car, but my cousin stops three times. It’s got to do with gas milage, engines, traffic, and weather (gas expands and contracts, etc etc).

So starting out entry level for most of us is just fine. In fact, I recommend it. They can run as low as $4 a month, though I tend to point out “You get what you pay for.” Otto once said “Look here, if you’re paying less than $300 a year to run a website, then why bother? How serious are you about your website anyway?”

Paying $50 a year for a website is the cost of about 12 lattes from an overpriced coffee house. It’s around five pounds of decent-to-good coffee beans. It’s just over one tank of gas for a larger car. If your website is your life, and not a hobby, this is too cheap. And yes, I work for a company who has low cost hosting. The hosting is not the only cost, though, so when I say “Spending $300 a year is reasonable.” I’m not just talking about the host. We’ll get to that in a second.

What am I paying for?

The basics. Space on a server with access to the internet. PHP, SQL, email, and some sort of ‘control panel.’ You’ll pay around $8-10 minimum for a host with cPanel or Plesk. Less if they made their own (or have a deal). You’ll also have limits, even if they say ‘Unlimited,’ and let’s talk about that for a moment.

Unlimited does not mean there are no rules, so put your shirt back on. In general, unlimited means “We’re not going to give you all sorts of nit-picky rules about how many images you can have, or how much CPU you can use, because those things are nigh impossible for you to understand. Instead, we’re going to make sure you don’t do things that will crash the server, and if you do, we’ll tell you.” So while there are no ‘limits’ there is ‘monitoring.’

Someone is going to say “Then there are limits!” and in a way, yes. But the trick is those limits change based on your neighbors. Allow me to explain with an analogy. When you’re in college, it’s okay to be noisy at weird hours at the frat house because the acceptable noise level is higher. When you’re living in an apartment in the city, though, suddenly you have neighbors who work the night shift, and you have to be quieter. Shared hosting, the cheap seats, are very much where you need to be quieter, respect your neighbor, and don’t do your laundry at 2am.

In addition, you’re paying for server and service support. Email not working? PHP needs upgrading? Those are things your host can, and should, do for you. Got a weird question like “Is httpd.conf set up with AllowOverride All or AllowOverride Options All?” A good host will have the answer! They’ll help you get to your error logs and maybe, maaaybe, if they’re not super busy, help you read them.

What am I not paying for?

Rock-solid Backups. Dear holy monkey socks, please make your own backups. I cannot stress this enough. Look, here’s the deal. No one cares about your data more than you do. Okay? So when you find out that some plugin you’re using doesn’t sanitize data, and Bobby Tables signs up for your site, you don’t feel like this schoolboard:

Why? Because if you have a backup taken every day, you can restore and only lose a little data! Then you can perhaps convince Mrs. Roberts to be so nice as to help you figure out what went wrong. But regardless, your data, the important stuff, is safe.

Also, you’re not paying your host’s support people for consultant level work, you’re paying them to keep your webserver up and running. That means if PHP, SQL, email and the like are working? Hey, your website sucking is actually not their problem. Now, most hosts are nice and will bail you out a little, but they won’t be coding your site, and surprisingly to many, if WordPress gets hacked, they won’t reinstall for you. There’s a line here. If your server is hacked, most hosts will fix it. If your webapp is hacked, often they will not. So some of your $300 a year may end up going to someone like Sucuri for a bail out ($89.99 a year? It’s worth it).

Finally you’re not paying them to have an opinion. This is weird to say, but I get a lot of emails at work asking me for my opinion on their site. “Does this look okay?” You know … I don’t know, and to a degree, I don’t care. You really don’t want my opinion on your penis appreciation website (not a joke), and that’s okay. You’re also not paying the host to make your design prettier. Again, not consultants.

But .. How do I know this is all right for me?

Entry level is barebones stuff. And that’s not bad, it’s just what it is. Be prepared for it, and one day you’ll outgrow it… but that’s another post. Entry level is right for you if you’re new, if you want to get started and play around, if you want to learn. It’s great for beginners, and unless you get that nastygram from your host telling you that you crashed the server (which yes, I have had happen to me), you’re fine on it for a long time!

Should you run your company’s entire business off shared hosting? No. This is the basics, and expect to run the basics on it, and little more.

17 September, 2013
Whois On First
Sometimes when I’m helping people out with their website, I feel like I’ve walked into an old Vaudeville act and we’re trying to figure out the answer to a question they don’t understand. The Internet gets newcomers every day and my conversations feel like this:

Ipstenu: Strange as it may seem, they give computer terms nowadays very peculiar names.

Costello: Funny names?

Ipstenu: Code names, geek names. Now, to figure out everything about your site, we start with whois on first, What’s Your Host is second, I Don’t Know your app is third —

For those of you who have never listened to Abbot and Costello do “Who’s On First” you need to take a moment to watch their televised episode “From The Actor’s Home” in 1953, the complete Who’s On First.(I grew up listening to them on the radio in reruns on KNX in the 1980s, and its safe to say that my concept of humor comes more from them than modern TV.)

So when I run into these people who are brand spanking new to the web (yes, they exist), I’m a little annoyed when I find they are totally at a loss at what they actually need to know in order to keep their website up and running. In part this is because the people who build the sites aren’t ‘consultants’ but friends and they just do the needful and move on. Those friends mean well, I’m one of them, but when you make a site for someone else, you have a responsibility to them that they know what the heck they’ve got. Otherwise, you’re not as good a friend as you thought.

But if you’re that newbie, what do you need to know to run your website? Three basic things! Whois! What is! Know is!
- Your Domain Name: Whois On First
- Your Web Host(s): What’s Your Host
- What’s Running Your Website: I Don’t Know Your App
That’s it. Three simple things. But in reality, they’re not that simple. And worse, the person who bought them is, technically speaking, the person who owns them. So if someone else bought your domain name for you, they own it. Not you. They have full, legal, rights to do whatever they want with it. Same goes for your hosting. It’s very important you put close attention to who is paying for your site, because if it’s not you, it should be. Don’t let your friends or consultants or developers buy these things for you, because then, legally, it’s theirs, and no amount of begging to a webhost or registrar will get them to give it to you.

But let’s get into the details.

Your Domain Name: Whois On First

You know this, right? I’m looking at halfelf.org right now. But do you know where it’s registered?

The domain name registrar is the company you paid to ‘reserve’ the domain name. It’s like your phone number. You paid AT&T to buy the number, and you can keep it as long as you want. But unlike the phone company where you pay for the number and the phone service, you may not be paying for both domain name and hosting in one go. In fact, many of us like to separate our host and our domain name, so if the host goes down, we can point the domain somewhere else.

The ownership of the domain name is important, because if you don’t own it, whomever does can point it wherever they want. This happens, from time to time, when domains expire. Someone will snipe the domain (i.e. buy it when you’ve forgotten to renew) and take it. And there is very little (if anything) you can do about it.

How do you find who your registrar is? It’s not that easy. If you use a tool called WHOIS to pull up the information, you’ll find a lot about a domain. For example, here’s what you can find for halfelf.org:
```
Domain ID:D165216955-LROR
Domain Name:HALFELF.ORG
Created On:06-Apr-2012 13:52:55 UTC
Last Updated On:06-Jun-2012 03:50:37 UTC
Expiration Date:06-Apr-2014 13:52:55 UTC
Sponsoring Registrar:eNom, Inc. (R39-LROR)
Status:CLIENT TRANSFER PROHIBITED
```
I removed some of the lines, because my information is WhoisGuard Protected. Normally it shows phone numbers, addresses, and so on. By law, you have to keep that stuff up to date and correct. Most of us forget. But none of that actually tells me what I need to know. See, I know who my registrar is, but all I see is “Sponsoring Registrar:eNom, Inc.” and that actually isn’t it.

Except it is.

My domain registrar is NameCheap, and NameCheap is both an eNom reseller and an ICANN-accredited registrar. I know, that was Greek, but what it means is there’s a list of people who are allowed to sell domain names, and this is the ICANN-accredited registrar and on there you will find both NameCheap and DreamHost, as well as Automattic (aka WordPress.com) and so on. So if they’re listed, why does my WHOIS show as eNom? Because they’re using eNom. Now as a separate example is my domain elftest.net, which shows up as NEW DREAM NETWORK, LLC. And that is, in this case, where I registered it.

If you get eNom as your registrar, don’t worry, you can easily find out who your actual registrar is via their reseller lookup tool. Toss halfelf in there, and you’ll see it’s NameCheap. Whew!

Your Web Host: What’s Your Host

This is the company you pay monthly (most of the time) to host your site. They generally have your email, too, though some people use Google’s Gmail ($5/year, yes, it used to be free). The Web Host is where your website ‘lives.’ All the files, all the pictures, all the email. It’s really easy to see who your host is, thanks to tools like WhoIsHostingThis.com, which can tell you that HalfElf is hosted on LiquidWeb.

If you can’t tell, this is pretty simple to suss out, but also very important to know. And just because you know who your host is does not mean you know the user account or passwords associated with it. If you are the person who pays the bills, you will always be able to get the account back by using your credit card info, but really this is something you should be keeping track of, because if you’re not paying for it, you’ll never ‘get it back.’ It wasn’t actually yours to begin with.

Speaking as a web host, the question I hate to hear the most is “I don’t have my login information for you guys, can you give it to me?” For what I think are pretty obvious reasons, unless you can prove you’re you, no we cannot hand you access. You need to know the login ID, the email address, the physical address/name of the owner, or some credit card into, in order to prove you’re you. You are not Gracie Allen, after all.

What’s Running Your Website: I Don’t Know Your App

This is the ‘what runs my site?’ one, and I am often amused by people who don’t know they’re using WordPress. Why amused? Because it’s at the bottom of every page, it’s on my login page, and … well it’s there. I don’t advocate removing all traces of WordPress from the site, because when you’re trying to figure out ‘what’ runs your site, these are helpful clues.

Even if you don’t use it, you should know what it is. Check if your site has a ‘readme.html’ page like https://halfelf.org/readme.html. Drupal has a README.txt (see http://www.typepad.com/README.txt for example), and MediaWiki just uses README (see http://jorjafox.net/wiki/README for one). So you may need to try multiple variations until you find one.

Of course, complicating that is the possibility of custom code. If your site is just plain HTML, hey, awesome. It’s easy and flexible and you’ll be fine. But the custom stuff, where someone comes up with cool ways to do things and doesn’t document them… this is why I like Web Apps, personally. Someone’s documented, or if not, there are other people who know how to help me.

What else?

What do you consider a ‘must know’ when you’re hosting a site? One thing that’s always interesting to ponder is “Where does my email live?” When I host other people’s sites, I tend to put their email on Google or another email only service, since that makes ‘moving’ way easier. Never assume people will want to have their files with you forever.
19 August, 2013
Code By Any Other Name

While this post is mostly geared to how to better name WordPress themes and plugins, the concepts should be easy to extrapolate for just about any bit of code. One of the hardest things to do, as a developer, is to come up with a name for your plugin or theme. Sometimes it’s really easy, like if you want to make a plugin that shows the phases of the moon as a widget, you’d probably call it ‘Phases of the Moon Widget.’ But is that the best name to give your plugin?

One of the least obvious aspects of plugins is that the name you submit when you fill in the form on the WordPress Add a Plugin Page is the name you get for your plugin. So if you submitted ‘Phases of the Moon Widget’ then you get the url http://wordpress.org/plugins/phases-of-the-moon-widget, and that will also be the name of the folder on someone’s blog: /wp-content/plugins/phases-of-the-moon-widget/. That may not be what you wanted.

When you’re coming up with the name of your plugin, few people give thought to the ‘slug’ you get with your plugin. They try to think of a name that is evocative and descriptive, but often not short and succinct. One might think, in this Twitter/SMS world, we’d be better coming up with short plugin names, but we often get plugins like ‘recently-used-categories-with-alphabetical-or-most-used-ordering’ and then the author gets annoyed with his URL.

In fairness to everyone, this isn’t well understood. And even I have plugin names I regret in the long run. The process is a little mystical and magical to how someone should be submitting a plugin with name and description. After all, you have more than one name and description to consider. You have the name, the slug, the description and the readme. Ouch! How do you do it?

For this example, I’m going to pretend I wrote a plugin that pulls in data from mlb.com and sends an email to people on my blog every time the Cleveland Indians win a game. I plan for this plugin to be used for a BuddyPress community (The Base-Belles), but after I wrote it, I realized I could make this work for any MLB team, and for wins and losses. Thus I now have a plugin that, on my site, is probably called “Indians Game Winner Emails” and has a slug like “indians-winner-emails” or something weird like that. When I write code just for myself, I rarely concern myself with anything fussy with names.

I’ve also made a theme for this site that I want to share, and I’ve called it “Base-Belles” (after the site), but if I release this to the world, I’d want to make it something everyone can use for any team’s fan group, so I will genericize that up.

When you submit a plugin, you’re asked for a name, a description and a zip. So let’s get started. When you submit a theme, you’re uploading the zip directly, and it’s in there you pick your name and slug. So for themes, this is less of a hassle, but the basic principle remains.

The Name

Even themes have two ‘names.’ You have your slug-name and your name-name. As I go to submit my plugin name, I might be tempted to type in “MLB Game Results Emailer by the Base-Belles” and in some ways, that is a great name for a plugin. It’s descriptive after all. But the first thing you need to do is drop any mention of ‘by…’ with your submissions. That’s just not needed, as a theme has a style.css to show who wrote it, and a plugin has the readme. We’ll know.

That means your name is now “MLB Game Results Emailer” which looks great. Or does it. Do I really want the slug mlb-game-results-emailer? What about mlb-results-alerts instead? That’s not much shorter, but as a slug goes, it’s descriptive. Even mlb-results-mail would be better. They’re to the point, and when I read the list of plugins via SSH or SFTP, I’ll know right away which plugin it goes with. This means I will submit my plugin with the name “MLB Results Mail” and I’m happy.

If this was a theme, I’d call it “Base-Belles” after the site, and use the slug base-belles. Boy that would be easy. Except … I generalized it, didn’t I? Now I have “MLB Fansite Theme for BuddyPress” which is a good name, but a bad slug. So for a slug, I’d use mlb-fansite instead. My child theme for my own site will become base-belles and now I’m happy here too! If I was really clever and totally made the theme generic, it would become “Sports Team Fansite” and sports-fansite.

Descriptions

When we ask for a description what we really want is your short description. “This plugin sends an email to your subscribers every time your chosen baseball team wins a game.” Or a theme “This BuddyPress optimized theme is perfect for running fan-sites for baseball teams.” This is all anyone wants to see for a short description. It should fit in a tweet. Short, simple, perfect.

Why don’t we want all the details? Well for one you overwhelm us with too much information at once if you paste in the readme. And for another, themes and plugins gets hundreds of reviews to comb through a day. Keeping it simple and short saves us time, which makes it easier for us to work through high volume. Where we want to see details is in your readme.txt. These are absolutely required for a couple reasons. First (and most important) we want to know that you’re ready to go live. A plugin should only be submitted when it’s ready to be released to the wild, after all, and that means you have a fully finished wordpress.org repository page which is handled by (you guessed it) the readme. If I can’t read your readme and go “Aha, that’s how the plugin is installed and configured and that’s how I use it” then you have done something wrong. The readme.txt is your gateway drug. Love it. Make it sing.

Something I often tell people who have had plugins rejected is that when they resubmit “Put ‘I talked to Ipstenu about XYZ’ in the description so we know you’ve already spoken to one of us. That makes it painless for me to look in our group email box, find the previous conversation, make sure we’re all on the same page, and approve. Also if I both handled the earlier conversation and I see your submission, it’ll trigger my memory and I’ll get through your ticket faster.

ZIPs

As of today, you cannot submit a plugin or theme to the WordPress.org repositories without a zip. not a RAR, not a gzip, but a zip.

I love getting zip files, but many times people submit zips that don’t open on linux, or have another zip in them. What we want in that zip is your complete plugin that I could upload to a test site. A theme will be auto-rejected by their scanner if it doesn’t meet their standards, you’ll have to start over. Plugins we still review everything by hand, so we have to open your zip. Personally, I use TextWrangler, which actually lets me open a zip without having to unzip it, but sometimes people zip things weirdly and I have to open it and drag the folder up.

If you’re using Github, there’s a built in link to a zip, which you can send us. BUT. Keep in mind, the zip will not bring in submodules. Yeah, ain’t that a damn dirty trick? You can use it to update your own code, but anyone who pulls down a zip to test with won’t get it. That really annoys me, and I’m not sure if it’s a bug or something Git did intentionally. Oh, submodules. You’re so complicated.

Do we care what you name your plugin’s zip? No. Do we care that you’re calling that name explicitly in your code? Yes. Use functions to determine directories and save us all a hassle. Do we care about calling wp-config.php and other WordPress core files by name? We sure do, but that’s another topic altogether.

Summary

In summary? Short slugs, descriptive names, simple descriptions, detailed readmes.

Of course, that’s high level stuff and doesn’t explain how to pick a plugin name. I’m highly fond of puns (hence Genericon’d) or I name things based on their original concept (rss2email was plugin’d as post2email). Sometimes the name is just obvious (Rickroll). Do you have tricks for coming up with a good name?

7 August, 2013
What WordCamp SF Means to Me

Andrea Middleton asked me to write something about either my upcoming talk today at WCSF or about the camp in general. I thought about it for a minute and sent her this:

I probably have one of the stranger (but not strangest) associations with WordCamp San Francisco: abject terror and absolute salvation.

In 2012, I went to WCSF for the first time, amidst some of the roughest professional turmoil of my life. At the time, I worked for a bank and was exceptionally unhappy with my work. I really wanted to work doing WordPress, and had spent much of the last 12 months applying to places and just not finding the right fit. Then I decided I should go to WCSF and see if I could make magic happen there, so I bought a ticket and had my car decide that brakes were optional. Short on the money for the trip, I appealed to the community, crowd raised the funds, and the day after I made goal, was asked to speak! I’d never spoken at any WordCamp, but I said yes because I was determined to change my life. Serendipity happened again, and I was contacted by DreamHost about a job. They too were coming to WCSF, so we had an interview and then agreed to meet up after my talk. This meant my talk was also part of my interview, and thus extra terror set in.

Of course, everything worked out perfectly. Now I’m happily employed doing WordPress work, traveling the US talking at WordCamps, and otherwise helping the community at large, being paid to do what I love.

Source: WordCamp SF 2013

Later today I’ll be talking about why you shouldn’t use WordPress Multisite. Spoiler alert: I love WordPress Multisite.

26 July, 2013
My Question is “You Suck”

If you’ve ever watched Survivor, they have a Tribal Council at the end of each episode, where they discuss things and decide who to vote off the island. In the grand finale, however, they instead discuss whom to give the million dollars. Every previously voted off tribe member gets a chance to ask the two (or three) finalists a question. Miss Alli, from the classic days of Television Without Pity, used to love/hate when someone would step up and use their time to shout, insult, or otherwise berate the finalists. She called that “My Question is you suck.”

Whenever you do support, you will invariably run into people who act exactly like that. If I had a dollar for every time someone left a support ticket with “This sucks!” I wouldn’t need to work anymore. And those people are really annoying, because you want to reply “Well thanks, and over here in the constructive world…” but you absolutely cannot engage them. As the Survivor yahoos quickly learned, feeding the fuel for someone who’s ranting is about as useful as keeping the rain off with those little paper umbrellas you get with fruity drinks.

My question is … this code is crap

Something to keep in mind, Tech Support is not “Customer Service” per se. When someone needs tech support, while they totally need someone to be ‘nice’ to them, they really need someone to fix their problem. Customer Service is all about building a relationship with the customer, figuring out their needs and wants, and basically selling them something. On the other hand, tech support is being told “This is my problem, fix it.” While that certainly happens to people who work at hotel desks (“There’s no hot water…”) it’s the meat and milk of life for anyone who writes and/or maintains software.

To this end, you’re really not ‘servicing’ the customer, nor are you taking time to build a great rapport with them, you’re trying to fix what’s wrong. Certainly doing this provides a service to the customer, but making sure the person comes back (or stays) is often secondary. After all, if we can fix the problem, you’ll come back, right?

When someone just says ‘You suck’ or ‘Your code sucks’ there’s very little you can do about it, if they’re not willing to give you a concrete example of these things. I have, on occasion, replied “Patches welcome! I’m always happy to improve my work.” That’s pretty much the best I can do. When the reply is that I, personally, suck, then I hand it over to anyone else. There’s nothing I can do here, so it’s time to ask someone else to help me out.(If you’re the solo dev, it’s time to cut your losses, say that you’re sorry you can’t help them, and walk away.)

My question is …. this plugin gets one star because it doesn’t work

Mark Jaquith Reviews Code. Credit Mark Jaquith

Everyone hates the ‘review that should have been a support question.’ Invariably we’ll get it. The plugin doesn’t work, screw you. And when we go back to look at the person’s post history, we see never once did they, in a place you can find, ask you ‘How do I make this work?’ It’s frustrating. Now you should keep in mind, on the WordPress.org forums, someone can change their star rating, so the best thing to do here is try and win them back. Kill ’em with a little kindness, point out ‘I would have seen this faster had you…’

But in general, this one is not to terrible to win back. Much of the time, someone who is this lost that they can only find the review location and not the right support places is someone who has a pretty easy to fix issue. Solve it and you’ve got a returning user. A smaller percentage of the time, alas, the problem is someone who really, truly, didn’t read what the plugin does. “This plugin for vegan resources sucks because there’s no bacon!” Not much you can do there except point out “This is by design.”

My question is …. you don’t reply fast enough for me

Today we expect, and often get, instant feedback. We have livechats, we have Twitter and Facebook. We reach out to the people who represent a company (or a TV Show), and we assume there will be some prompt reaction. This is no longer customer ‘service’ but ‘experience.’ The customer’s personal experience will color their feelings about both the product and the people behind it. It’s a large part of why I don’t think pure customer service exists any more, if it ever did, in software.

The problem comes in when you take a weekend off, or an afternoon, because you want to actually have, you know, some time with your family, or go to a movie. Maybe you were just asleep for eight consecutive hours. Either way, it was the worst time in the world for someone else, and they’ve left multiple requests for help. If you’ve ever worked in a ‘traditional’ office, these people are like the guy who emails you a long question, and then calls you and swings by your desk, after IMing you, to make sure you got the email.

In short, they hit every single ‘annoyance’ nerve in a person’s body, all at once, and they do it over and over and over. I tend to want to reach through the monitor and take away their caffeine for a couple days. But until someone invents that for me, I have a couple tactics.

For anything ‘free’ (like WordPress plugins) I tell them that this is a free product I write in my free time, and that means waiting a reasonable time for a reply means waiting 3-5 days, not 3-5 seconds. And then I answer their question as best I can. For the paid stuff, I point out that I missed their email because I had gone home for the day (or ‘had the weekend off’). Usually just that gentle reminder of “some people do work ‘normal’ hours still” gets them off their horse enough to work with. On the rare occasion it doesn’t(I’ve had people tell me that I’m too important to not be available 24/7, which is sweet, but no.) I’ve just ignored their unreasonable demands and concentrated on fixing the problem at hand.

My question is … you don’t know what you’re talking about

Finally there’s the you suck hidden in a peculiar phrasing of basically “you aren’t good enough.” This is not the same as the outright “You suck.” because it’s actually a value judgement. It’s not a dismissive “You’re a meanie poopy head!” sort of claim, it’s a “Your code sucks!” And this sort of comment hurts a lot. People calling you names rarely have any basis to do so, and they’re rarely right. People calling into question your work, however, that cuts to the bone and tends to make us over react.

In defense of people who submit bug reports, much of the time this is not what they mean! Sometimes they say “I think you’re wrong because of XYZ” and it comes across as “You idiot, how could you not possibly know this!” I say this a lot, but text is a really lousy medium for communication of intent. Now. One thing the people who report the bugs really need to remember to do is say “Thank you” when the bug is fixed, or even “I appreciate you taking the time to explain to me why you won’t do XYZ.” Instead, most of what we get is someone saying “I told you! I was right and you were wrong!” I gotta tell you, that never really makes me want to work with you again.

But the real reason this one galls me is that it’s generally said to me after someone has specifically asked me for help on something of I’m somewhat of an expert (or talented tweaker). I’ve had people tell me I don’t know jack about WordPress (pretty sure that’s wrong), or pretty much anything else under the sun. That frustrates me, since you came over here asking me, admitedly a total stranger, for help, and when I gave it you snipped that I’m ignorant.

To these, I actually do point out “You know, you asked me for my help/opinion and I gave it. We can agree to disagree, but you don’t have to be mean about it, since that’s not a good way to get help from a free, volunteer, community.”

Unless of course you’ve hired me, at which point I refund most of your money and cancel the contract.

22 July, 2013
To Fork Or Not To Fork

Sometimes the question you have to ask yourself is if you should fork. With a plugin, this is a fairly easy conversation. You want functionality, the original author doesn’t, you fork. But when you look at a theme, you start getting into messier territory.

In many ways, a theme is ‘simpler’ than a plugin. Theme devs, don’t shoot me! What I mean is that a plugin can be or do anything, but a theme is always a theme. While it may change how your site looks in amazing ways (and I am constantly in envy of people who can visualize like that), it really is just a theme. This is why reviewing themes is easier to monitor and manage than plugins. But that’s another conversation. The point here is that when you want to extend a theme, you make a child theme. Done.

What happens when you’re already using a child theme, though? StudioPress, a theme shop I love, makes child themes and sells those. This site is using a child theme, though it’s currently one of my own devising. Previously, it was using a child theme called Streamline, however, and it had a lot of changes.

So when do you make a child theme, and when do you extend it in other ways? It really depends on what you’re doing. While I sat and tried to figure out where my personal breakpoints were, I realized that since the best themes know they are a theme, and not a plugin, it was really easy. A great theme lets you seamlessly use a plugin to add in functionality. They may even tell you what the best ones are. Recently, Coen Jacobs wrote about how good themes never bundle plugins and he’s right. A plugin is a plugin, a theme is a theme. Keep ’em separate, keep ’em safe.

I’ve done it in three different ways for three different sites, and I’ll explain my rational below.

The Simple

One site is simple. Every ounce of functionality I needed, and more, was in the core code of StudioPress, not even a child theme was needed. All I wanted was to change some colors and add in a couple CPTs and shortcodes. That was easily done via Jetpack, which has a CSS editor, and a couple plugins. Actually, 99% was the CSS, once I sat down and looked at it. All the weird stuff was normal plugins.

Sometimes simple is a teeny bit complicated, and when that happens, I may make a custom mu-plugin or two, but in general, not so much needed unless I want a Custom Post Type. And anyway, I never put a CPT in my theme if I can help it.

The Complicated

On the other hand, one site is hella complex. I found a theme I really, really, liked. Almost. And worse, this was a child theme. It was exactly what I was afraid of. There was no way I would get what I wanted out of this theme unless I edited the functions.php file, a lot of the CSS, and a ton of the images. Could I still have done this via CSS and a couple plugins? No. Well, the CSS yes, but not the code. I had need for some crazy functions, a total re-write of comments, and the list went on.

In this case, I forked. I ripped out the small amount I never wanted. I added in the medium amount I did want. I directly edited the theme’s CSS, added in a post template, and changed all the images to my chose color. I even added in a different font. Could I have re-written from scratch? Of course, but the theme had 90% of what I already wanted to do.

There actually is a step before forking, and that would be using plugins. I know I mentioned plugins before, with the simple themes, but actually most theme frameworks are extra special. They often have custom plugins like Simple Hooks, which fundamentally lets me do everything I might do in a functions.php file for that theme. This means most of the time, I don’t fork. But. This theme really was so complex that I needed more than just the simple hooks. Genesis Complex Hooks may have done it, or another plugin to make a transient functions.php (ala CSS editing). And that would have done it except for when I wanted to change a lot of images, add in JS, and then a custom page template …

Well you see how it goes. The point here, however, is that I sat and thought about it, studied my setup, and made a long term decision. Originally I was using the plugin way, but when it stopped being extendable, I decided to do this, and I regret nothing.

The Original

The last option I had was I theme I kind of liked, but it was old. It was pre-HTML5, it didn’t have microformats, but more-over, it wasn’t aging as well as I would have liked. I made a list of what I liked about it, what I didn’t, and what I really wanted. While the list was short, it was also clearly not going to just be CSS. I wanted a custom front page, an extra page template, images, and Genericons built in. In short, I wanted this theme to be something that could carry me onward, regardless of a plugin, even one I wrote.

I have not made my own, 100% from scratch, child-theme in a long while, and this one may not really count since I was designing it to look like something else. This took me an afternoon to bang out the basics, and a couple days of minor fixes here and there to perfect them. Release and iterate, as they say. Certainly, I could have taken someone else’s theme, but it was going to be a surprising amount of work to do that. Instead, I made a list of my needed features and my desired options, and went to town. It’s still a pretty simple child-theme (which speaks well to the inherent extensibility of the parent), but now it’s mine, and it’s easy to extend it and expand it.

The Rest…

What about you? What do you think about when deciding how to handle a theme that needs changing?

17 June, 2013