Author: Ipstenu (Mika Epstein)

Give Back Or Die

One of the things I hate in the world is people who don’t give back.

I call myself a software socialist because I strongly believe in giving back to the things that make me successful.(This is, in no way, a blanket approval of everything Socalist. Snarky political comments may be deleted.) This is why I give back to WordPress, spend so much time on it, and so on and so forth. Thus, it’s logical (or at least internally consistant) when I say that the part about WordPress that I hate is people who take and never reciprocate. More than this just being a pet peeve, though, people who do this with Open Source code are biting the hands that feed them, and it’s terribly frustrating to watch.

Look. You get this totally awesome software for free. People volunteer (sometimes we’re compensated, sometimes not) to make it better, safer, more secure. And we give these updates, again for free, back to you to make a living from. That gives all of us ownership in the software and a responsibility that I see a lot of people dropping the ball on.

So let me state this for the record: If you use a product that is free that enables you to make your living, and you do not give back in some way, you annoy me.

I’m going to use Mediawiki as an example here. I cut my teeth on it, which is something few of you know. I’ve been using it longer than WordPress, as a self-hosted Wiki install. I learned about caching tools not because of WP, but from Mediawiki. I learned about config files and extensions, and why you never edit core files, and theming all from Mediawiki. It’s safe to say that had it not been for my foray into that world, I’d never ever have been the WordPress Guru I am today.

At the same time, I have never once given a single line of code back to Mediawiki. I’ve probably reported no more than 5 bugs in my lifetime, and it’s not because they don’t exist. I actually do know how to do more than just theme in Mediawiki, I know how to trace a bug and fix it, but given my use-case of it it’s been pretty rare that I’ve even had to report it, because every time I’ve found it already handled in the next release.

By the way, the whole reason I mastered Git? Mediawiki. I needed an easy way to upgrade and keep up with a trunk release that fixed a critical bug for me.

But if I don’t give back code, do I annoy myself? Nope! Much like WordPress has a WordPress Foundation, Mediawiki has a Wikimedia Foundation. And yes, I donate money.

And this is my point. We’ve already proven that sponsored software can work. At the time I wrote this, Aaron Jorbin’s charge to raise money so he could work on Post Formats was a couple hundred from goal. I’m confident that by the time this is posted, it’ll be met. (I’m also confident the Indians will sweep the White Sox, so Aaron, you can do your ten support tickets for Post Formats if you want. If they lose, I’ll patch something for your plugin.)

The point is simple. Giving back is not just code. I talked about this at WordCamp Portland, and I talk about it all the time. You don’t have to code, or file bug reports, all you have to do is be here and do something for the community at large. Heck, if you want to help clean up after a meetup? You gave back!

So please, don’t be greedy. Give back to open source. Don’t just take and take and then complain it’s not everything and more. Do something, anything, that helps someone else. Even if you’re doing it altruistically, you’re not living in a vacuum.

26 September, 2013
Separate Users Are Good

When you create a new domain on DreamHost, you can chose to make a ‘new’ user to ‘own’ the site, or use an existing one. There are pros and cons to both, but for anyone who comes from the cPanel world (where separate accounts are de rigueur), it’s pretty normal to expect your separate site to have a separate login name and password.

Explaining how all this works on DreamHost is a little different, because we have users and then we have users and … well let me explain.

There’s more than one kind of user

The first type of ‘user’ you have at DreamHost is your panel user. This user is the one you make when you sign up, and it’s usually your email. Don’t share this password with anyone, okay?

Next we have your ‘users’ which you can find in your panel. Those users are the ones who have access to things like ‘shell’ and ‘sftp’ and so on.

Then there are also those ‘other’ users you think of, like the login accounts on your blog, or your email, or maybe even the billing account for DreamHost.

When I talk about separate users, I’m only talking about the ones who have access to shell and stuff.

Users own sites

Those user accounts own sites. That means I have a specific user who ‘owns’ the folder on the server where all my web code lives. And you can see it’s that user because there it is, in the path: /home/USERID/domain.com/

Only one user can own, and access, a domain. However a user can own multiple domains.

So here’s what this looks likes. One user owning multiple domains:

And only one user can access the domain, user two cannot:

This is cool because if there’s a domain under User 2, and it gets hacked, there’s no way for User 1 to get hacked, even if both users are you!(Unless there’s a server wide security flaw, which yes, can happen, but we spend a lot of time trying to prevent that.)

Logical User/Domain Groups

If you own 50 domains (and I’ve seen users with 200!), having them all owned by one user sure seems easier, but it means if that user gets hacked, they’re all vulnerable, and you’ll probably end up having to de-hack 50 domains at the same time. Instead, it’s wiser to group your domains ‘logically.’ For example, my elftest.net domains have subdomains, all of which are owned by the same user. However my other top-level domains are each owned by their own user. But that doesn’t work for everyone.

Recently I was helping a customer with a hacked site, and he complained that the sites he hosted for his clients were being hacked, and his clients were pissed off. I took a look and saw that all his client sites were under one user ID. I asked him if the clients had more than one domain, or if they all had their own, and he replied that each client had 4 or 5 of the domains. After cleaning up the hack, together we made new user accounts, one for each client, and moved the domains to those accounts. If possible, I always clean before moving, but in one case the customer had 75+ hacked sites, so we moved and then cleaned each one, prioritizing the accounts on the way. It took a very long time.

The extra benefit to this is the clients can now have FTP access to their domains and do wild and crazy stuff! But we don’t want them to have FTP.

Moving The Domain

Obviously first you need to setup users. When I set up a new user, the first thing I do is make it secure. That means I turn off FTP, forcing SFTP only, and if needed, give them Shell access. Personally? I love shell access, so I always leave it available. If you’re using DreamPress, we have Shell turned off by default, but you can activate it.

There is a downside, which is that the WebFTP app won’t work. Personally? I find 99.999% of WebFTP apps to be total drek. They’re messy, kludgy, and there are some great free apps like Cyberduck which even let you connect with DreamObjects!

Now that you have the user, we want to move the domain. This is so easy, anyone can do it. Go into Panel, click on domains, click on edit for the domain. Go to “Users, Files, and Paths” and change the user in “Run this domain under the user:”

Really, it is that simple.

24 September, 2013
Changing How We Develop

Traditionally in open source land, we come up with an idea for something, we sit in a room and talk about it (it’s kind of like flirting), we make some code, and we test it. Many, many, times we do this in isolation, and we do it in our free time, hoping one day to have the time to make it awesome.

What if we didn’t? What if, instead, we looked at history and remembered that some of our greatest works were brought about by patronage.

“Artists from Michelangelo to Shakespeare all received support to create the works of art that we know today.”

Now, finding a patron isn’t easy. It’s harder and harder to find fancy philanthropists who want to fund you for a while to write something awesome. And worse, trying to ‘schedule’ inspiration is hard. But in reality, we do this all the time. The inspiration is there for many of us, we just need the time not doing the other things.

Aaron Jorbin’s giving this a stab by crowd-raising the money to improve WordPress Post Forking.

WordPress Post Forking allows users to “fork” or create an alternate version of content to foster a more collaborative approach to WordPress content curation.

That sounded weird the first time I read it, but let me explain it differently. Have you ever written a post, published it, and then wanted to edit it and have someone else check it before you post the changes? WordPress can’t do that. Once a post is live, you can’t save a change without making that change live too. But what if you could? What if someone could ‘fork’ your post, make edits, and you could review those edits and pull them in? It would be like tracking changes on a Word Doc, only cooler.

I hope that other developers, who have great ideas, follow this patronage model going forward. After all, I never have a problem with paying for great code. I just have a problem paying for crapy code.

ETA: It seems fitting I should repost this pic here:

Aaron Jorbin – Haters Gonna Hate (by Helen)

24 September, 2013
Adding Per Site Multisite Options
johnc- said in IRC the other day, regarding the use of get_option API for WordPress “our standard practice is to use get_option to enable site specific features, if the feature needs to be unavailable for other sites then it gets broken into a separate plugin for clarity”

So to explain this for those who blinked a little we need some examples, and really this depends what you’re writing.

We got to this point in the conversation while folks were watching my “Don’t Use WordPress Multisite” presentation from WordCamp SF. During the presentation, I mentioned that generally, when I want to write a function for a specific site on Multisite, I wrap it around a ‘If site 1, then …’ and put it in it’s own plugin file in mu-plugins. That leaves me with files like halfelf-functions.php so if I ever split the site out (see? I’m always thinking ahead) I know what file to copy.

But that’s not the only way about it. Another way is to put all the functions in a file, and then wrap the actual filters and actions around a get_option call. Why would I want to do this instead of a separate function file? The question of portability comes up primarily. Exporting site options is not the easiest thing in the world on a Multisite, but there are cases, like my Capital H Dangit! function, where this would make sense. In general, I always want DreamHost to have a capital H, so since 99% of my sites have that on, I could, instead, use an option, since if I ever moved the one site that doesn’t use it, I just won’t bring the function over!

Currently have wrapped that function around an ‘if site 2, then don’t run’ check, which works fine. But if I wanted to move that to options, it would go like this:
```
// Add the default option of capital h to yes, and autoload
add_option( 'helf_capital_H_dangit', 'yes', '', 'yes');

if ( get_option( 'helf_capital_H_dangit' ) == 'yes' ) {
    foreach ( array( 'the_content', 'the_title', 'comment_text' ) as $filter )
        add_filter( $filter, 'capital_H_dangit', 11 );
}

function capital_H_dangit( $text ) { 
    [... code here ...]
}
```
This is pretty basic. It adds an option called helf_capital_H_dangit, auto-loads, and defaults to on for everyone. That was the easy part. The hard part is determining how to control it.

One option is an interface where I can check a box on, say, General Settings > Writing > Formatting (right under the smilies check box would be perfect), but since I knew this was something I was going to want to control as the super-admin (that is, I don’t want the other people on my network to turn it off), I went in to the back end of my site at /wp-admin/network/site-info.php?id=2 (since this is site #2) and searched for ‘Helf’

I edited it to ‘no’ and saved. Boom. I can use DreamHost and Dreamhost here.

Now this isn’t something I’d do for everything. In fact, my actual halfelf-functions.php file looks like this:
```
global $blog_id;

if ( $blog_id == 2 ) {

	remove_filter( 'the_content', 'capital_P_dangit', 11 );
	remove_filter( 'the_content', 'capital_H_dangit', 11 );

	// I Make Plugins Filters
}
```
All the per-site filters are right there turned off as I want them. It’s not a lot of effort that way, and it’s still easy to pick up a site and drop it somewhere else.

Which is better? I don’t know. The real test would be to do some hardcore speed checks and see if checking for the blog ID is faster than checking for an option. I think the speed benefit gains would come from only calling this when needed, but for the limited world in which this is used, it should be fine. Also, keep in mind what both johnc- and I are saying, but in different ways: remember the 80/20 rule.

In my opinion, if you’re making a feature that will be used by 80%+ of the sites on your Network, get_option is probably the easiest bet. If you’re making a feature that’s going to be used by 20%- of the sites, then a separate plugin (with a site_id check) is the way to go. Of course, you could do an option and default it to ‘no’ as well, but that brings up an interesting level of things to remember if you ever move a site.

If you’ve got a more efficient way of doing the same thing, or even just a different way, speak up! More options are always better.

Oh and no, we’re not going to sneakily install this on DreamPress, but if I did, it would also capitalize DreamPress, DreamCompute, and everything else out there. But I won’t.
23 September, 2013
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
Why We Don’t Auto-Update Plugins

Since the push of DreamPress (which I’m totally digging), the ‘One Click Install’ feature of DreamHost has become a little more obvious to people, and it’s benefits and disadvantages.

What’s this auto-upgrade thing?

To make this simple, if you use DreamPress or our One-Click installer, we automatically upgrade WordPress for you! It doesn’t happen the very second WP has a new version, mind you, we spread it out to not destroy our servers, but you will get upgraded unless the upgrade feature was disabled (of course, you would never disable them, right?). Any time you want to see if you have automatic upgrades enabled, or want to run your own, head over to the DreamHost Panel.

Why not plugins and themes?

So why do we only do this for core WordPress? Because plugins and themes are messy.

The safest upgrade in the world is the minor upgrade (like WP 3.6 to 3.6.1), as it’s exceptionally rare that it breaks anything. It’s not perfect, of course, sometimes we find out that a plugin or theme was doing something in a very non-optimal way before (if you hear ‘doing_it_wrong()’ please keep in mind that is not a value judgement, just a code comment, we all do it wrong in the beginning). But rarely will this kind of upgrade break your site.

Similarly, the major releases (3.5 to 3.6) are perhaps surprisingly stable. They’re tested, a lot. At DreamHost there are two people (me and Shredder) on the core contributor list, and we’re heavily involved in WordPress development every single day, at work and at home. We keep up with WP changes, test them on DreamHost, and work with the core team to resolve issues before they even release a beta! We’re on the job!

“But hang on!” I hear you say. “I upgraded to 3.6 and it broke my theme!”

And THAT is why we don’t upgrade themes.

I know, I know, it sounded counter-intuitive. You have to look at it a different way. Your theme stopped working with WordPress 3.6. That means something in the theme is not compatible with the best practices in WordPress core. Translation: WP didn’t break, your theme had a bug.

It sounds like semantics, or hair-splitting, and I totally get that. It also sounds like we’re passing the buck. We’re not! And we’re not trying to imply the theme (or plugin) developer who now has a broken product is a bad coder, or doesn’t pay attention to WordPress. What we mean is that themes and plugins, as they are used by much smaller segments of the WordPress community (everyone uses core, but maybe only 1000 use that theme), it just can’t be tested as robustly. This is especially true of the solo-developers. Speaking as one, I used to develop WP only in my free time, so any time WP had a new release coming up, I had to take days to test all my plugins, and pray I got everything. Invariably I missed stuff. It happens. We’re humans.

Breaking isn’t the only reason, though. Sometimes an upgrade is messy and complicated. Take, for example, NextGEN Gallery. When version 2.0 came out, it inadvertently broke a lot of installs. There was chaos, drama, and finally an open letter. How did this happen? It happened because NextGEN is hella complex, and it’s used in myriad different ways. It happened because plugins and themes can do anything with WordPress.

Blindly updating core is safe. It’s tested and easy to roll back. Blindly updating themes and plugins are not always easy to roll back, they’re not always easy to upgrade (some require a massive upgrade script to run), and they may require you to make other changes in your theme. For that, we just don’t.

If DreamPress is MANAGED Hosting, like WordPress.com, how come THEY do it?

You mean why do the plugins on WordPress.com get auto-updated? Because you can’t install any plugins on Wordpress.com! That’s all. They control everything, and simply activate various plugins depending on what package you buy. It’s not really the same thing at all, but I get why people think it is.

I don’t care! Can I auto-upgrade anyway?

Are you sure? Okay, then! Install the plugin Automatic Updater (by Gary P.) and set it to upgrade your themes and plugins. I personally use it on all my sites, but I’ve also personally vetted each and every plugin on my sites.

12 September, 2013