Author: Ipstenu (Mika Epstein)

Speaking at WordCamp San Francisco – 2013

It’s true! I’ll be speaking at WordCamp San Francisco again this year.

Last year I talked about supporting WordPress and how you can give back. This year, the subject of my talk is “Don’t Use WordPress Multisite.” I wrote a post here about that in 2011, and while quite a lot of it remains true, I still see hundreds of people who think Multisite is the cure to all that ails ’em.

I love it, but it’s not everything and a side of fries. But I’m not going to give away the talk here, and it’s not just going to be a copy of that post. So feel free to read it, offer comments, and meet me where I left my harp: Sam Frank’s Disco.(This is a very bad joke I’ll tell you if you want.)

21 June, 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
DreamPress: We Went There
Not the most flattering picture of me…
One of the projects I’ve been involved with since I started here at DreamHost has been a secret. Actually two of them were, but we released one already. Anyway. The one we pushed today is DreamPress!

What is DreamPress? Here’s marketing:

What is DreamPress? That’s a good question! Think of WordPress. You got it? Cool. Now, think of that WordPress install, but on steroids! Picture it running on a specialized, optimized, virtual private server. Yeah, this is far from your average WordPress hosting package, isn’t it? DreamPress comes pre-configured by our in-house WordPress experts for maximum security and performance under traffic load. This is our call-out to all entrepreneurs, website designers, developers, and bloggers to give it a test-drive today!

And here’s me:

If you did your job really well, one day you woke up to a downed website becuase you swamped it with traffic. I’ve been there, you’ve been there. There’s a point where your host reaches out to you and says “Honey, sweetie pie, you’re too big for shared hosting.” And as horrible as this is, it’s a good thing! You’re popular! Of course you’ll try caching and changing themes and plugins, but there’s just that moment when, damn it, you’ve got to step up and go up to a VPS.

And you know what? A VPS is scary. I started this blog when I got my VPS because I wanted to learn how to manage it. But you see, I’m weird. I know it, you know it, that’s okay. I’m strange and I like me, just the way I are, and this works for me. It doesn’t work for everyone, so when you find yourself faced with something new and different, maybe you don’t want to learn it. Maybe it’s not your thing. So looking at that VPS is a great big bag of nope.

This is where managed hosting steps in. Hosts take on the job of managing your server. We handle upgrades (which yes, we do anyway), but we also optimize and customize the server. All the times you hear me talk about ‘Edit your httpd.conf’ or ‘installing PageSpeed…’ is something we’ve already done for you. Need more memory? We’ll take care of it without bothering you. It’s a VPS without the responsibility. PHP memory, server power, even caching is taken care of. Oh yes, you no longer need any caching plugins, because we’ve got Varnish in front for you.

Of course, this isn’t perfect for everyone. Hard-core code jockeys may want that VPS (or dedicated) to play with the nuts and bolts, install extra add-ones, and just go to town. But if that isn’t for you, come check out DreamPress. I promise we’ll have a magic button to migrate things soon!

Nifty articles on DreamPress:
I know there are a lot of hosts out there. I work for one, I use others, and I think the more of us who get into this supporting the app that needs supporting, the better experience for everyone. Bring it on, baby!
4 June, 2013
Migrating to DreamPress
I should start with the note: You do not need to do this. We’re finishing up the last bells and whistles on a script that will handle all this for you if you have a One-Click-Install, but if you really just can’t wait or had a manual install, here’s what you’ll need to do. Keep in mind, there will be about an hour where your hosting will ‘vanish.’ In the words of Ford Prefect, don’t panic.

Again, you don’t have to do this. We will have a magic button soon enough. That’s why this isn’t going up on the Wiki, it’s really not going to be (long term) useful except to people who love experimentation.

We have a magic button!

But if you still want to do it manually, read on.

So you saw the news about DreamPress and read our bragging post about it? You got super super excited and then bummed, because the magic button isn’t done yet? Well… Okay, you can migrate manually (I did it for this site yesterday), but you need to know shell. You can do all this with FTP, but it’ll take way longer.

If you just want to make a new domain, read DreamHost Wiki: DreamPress, and you’re good to go! Otherwise, pull the hat down snugly, because here we go!

1. Remove Hosting

Yes, I know. It’s scary. By removing hosting you will turn your site to DNS only. This is OKAY. Your files and your DB will remain exactly where they are. The Remove button is right under ‘Fully Hosted / User : elftest‘ so just click that.

See? Now it’s DNS only.

2. Add DreamPress hosting

Go to https://panel.dreamhost.com/index.cgi?tree=domain.wordpress& and add a new site.

You should see a happy green box telling you that it will take 15-30 minutes to provision you the site. Sorry about the wait time, but we’re actually building you the server stuff on the fly. It’s special.

While you’re waiting, let’s get some things done.

3. Export the old DB

Everything is perfectly safe and sound, so just go ahead and do that. Save it locally to your computer.

Go to https://panel.dreamhost.com/index.cgi?tree=goodies.mysql& and log in to your SQL database. The directions are the same as our normal Backup MySQL ones, so just go and do that.

If you’re Command Line savvy, you can do this via WP-CLI.
```
ssh oldaccount@oldserver.dreamhost.com
cd example.com
wp db export
```
That will reply with “Success: Exported to example_com.sql”

By the way, you’ll need to have the server name (not your domain name) in order to SSH in, as we’ve already pointed your domain to DreamPress. It’ll be something like ps10000 which makes your SSH ps10000.dreamhost.com. You can leave the SQL file there, we’ll pick it up later on in the show.

As soon as you get that email saying “Yay! DreamPress for you!” we’ll ignore the email’s directions and skip on to…

4. Get the new credentials for both SQL and SFTP.

On the DreamPress page, you’ll see your new site info.

You’ll be able to find the new passwords at the usual locations. In the case of the user account (which will be something like wp_kxezav), you’ll want to set it to something you know. While you’re in there, change the account type to “Shell account – allows SFTP/FTP plus ssh access.” I personally also check to disallow FTP, for security. I also like to rename the account something like ‘ElfTest – DP’ so I know this account is for ElfTest on DreamPress.

By the way, you may wonder “Why can’t I have one ID for all my domains on DreamPress?” and the answer is twofold. First, we’re charging you per site. Yes, site. Secondly, security. If one account gets hacked, the others are safe. This is a good thing!

5. SSH into your new account

It’ll be ssh wp_kxezav@ps1121212.dreamhostps.com or such and this will dump you into not the domain, but the folder above it. This is important! You need to be in the example.com folder in order to do anything. Notice also how the domain is suddenly dreamhostps.com and not just dreamhost.com? Also important.

By the way, if you’re going to be using a lot of SSH, you should set up passwordless SSH access. It’s perfectly safe (in fact, safer than entering a password), and has to be set up per computer but .. how many of us use more than one computer? Hush, geeks.

6. Super power time! Let’s copy everything over!

Actually, let’s delete everything first. Yes, I know what I just said. There are reasons. This is just faster. I’m super lazy, so I first opened up wp-config.php and copied the SQL data for the NEW database.
```
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'example_com');

/** MySQL database username */
define('DB_USER', 'examplecom1');

/** MySQL database password */
define('DB_PASSWORD', 'likeaflaninthecupboard');

/** MySQL hostname */
define('DB_HOST', 'mysql-1.example.com');
```
Obviously changed for my protection. You’d never publicize your passwords. Right? RIGHT? Good. I saved this to a text file on my laptop for the time being. Now let’s delete:
```
ssh newuser@ps1121212.dreamhostps.com
cd example.com
rm -rf *
```
This wipes out everything in my domain’s folder. Make 100% absolute sure you got the right folder! Once you’ve done it, let’s copy things over!
```
scp -r olduser@oldserver.dreamhost.com:example.com/ .
```
SCP is ‘Secure Copy’, and is a fancy pants Unix Command. I’m fond of it. You’ll notice that I said to use ‘oldserver.dreamhost.com’ and not ‘example.com’ and this is because we’ve already pointed your domain to DreamPress. Zoing! When you do this, you’ll be prompted for a password.

Then you’ll get a mile of stuff like this:
```
wp-config.php                                                  100% 3583     3.5KB/s   00:01
xmlrpc.php                                                     100% 2719     2.7KB/s   00:00
readme.html                                                    100% 9177     9.0KB/s   00:00
admin-bar-sprite.png                                           100% 2470     2.4KB/s   00:00
```
This is SCP copying everything over, safe and sound.

7. Change your Database Stuff

There are two parts here. First you want to copy that DB stuff you saved before into the wp-config.php file, replacing the configuration you had there before. Second you want to import that backed up database into the new DB.

You can do this via phpMyAdmin if you want, but if you’re using wp-cli (and you should, it’s awesome), you can do this:
```
wp db import example_com.sql
```
Whaaaaat? How did that work? Remember when you exported on the old setup and then SCP’d the files over? Guess who came with! That’s right, you slipped your DB over nice and fast, and boom goes the dynamite, you’re in.

8. Have a beer!

I always end things with a celebratory something. Your URLs didn’t change, so you’ve got nothing to worry about. Once you’re sure everything’s good, go ahead and delete the old user ID as long as you are 100% certain you’re not still using it!!! Remember, a lot of us use the same IDs for multiple domains.
4 June, 2013
When Your Code Doesn’t Self-Alert…

If you don’t want to read this whole post, there’s a big takeaway for anyone who releases code: Please make sure you have an easy way for people to be notified to a new release.

The Story…

I use WordPress a lot. It’s made me lazy on a lot of things, like version control. It’s also made me incredibly complacent when it comes to updates. You see, WordPress has a massive API system and servers which allow you to get in-app alerts to any needed updates. Click to upgrade and done. It’s second only to Chrome, which just updates.

Now there are pros and cons about automated updates, and some things, like my server software? Hellz no, son, I don’t auto-upgrade that! Yes, I auto-upgrade cPanel and other server tools that I added on, but PHP and Apache and MySQL? No, those are things I have to stop and make damned sure I know what I’m doing. Why? Because they’re not ‘add on’ software, they’re the core functionality of my entire webserver, and if I mess them up, I am up shit-creek.

If you’d asked me last year ‘Should WordPress auto update itself like Chrome?’ I would have shouted no, very loudly. And now here I am, doing it. Personally I’ve been using Gary’s Automatic Updater on all my sites for months now, because I know my WordPress setup is tight. I love the Chrome and Firefox auto updates, because I don’t customize those things ever. While I do customize the hell out of WordPress, I do it smart and I do it right. My code is doing_it_right() and the plugins or themes I add on to my sites are all well vetted and Elf Approved. The same can’t be said for everyone, but after a lot of thinking, I think if WordPress auto-updated, people would have an initial clamor of pain with all the shitty code out there that broke, and then the bad code would Darwin itself right on out of use.

But that’s not the point of this. In my head there’s a difference between ‘core software’ like PHP, and ‘app software’ like WordPress. The lines are clear, they should never be crossed. Auto-Updating works for apps, not for core. And what happens when your app doesn’t even auto-alert for updates? How do you handle updates?

I’ve already mastered using git as a ‘deployment’ tool, and svn has been old hat for me. That means I know how to quickly update my code, but I need to know when to do this.

The Solutions…

There is a light at the end of the tunnel. There are some easy ways you can keep track and, conversely to the devs, make it easy to keep people up to date, and it all starts with the code’s website. You do have a website for your code, right?

Check the website

If there’s a blog, there’s probably an RSS feed. This is really easy, since most (if not all) blog and CMS tools use RSS.

No RSS? No blog? Maybe there’s a mailing list. This is actually my favorite option. I hate email, but I love getting emails for software updates like that. If that’s not your thing, see if the mailing list has an RSS feed. I know people use Google Groups for a cheap mailing list, and if you visit the Groups page and click on the about link (see the image, not the dropdown, the link), you get a whole mess of RSS options!

This only works for public groups, but why would a private group be an announcement list for your app releases anyway? If it’s private, get used to email.

Speaking of mailing lists, MailMan, my list of choice, does not have RSS feeds. It’s the old spavined mule of lists, I know, but for people who love it, check out MailMan-to-RSS.(The irony I feel in writing that, which is the opposite of how I handle things with my post2email plugin, is deep and unfathomable.)

But what about those other guys? You know who I mean, the guys who use GitHub as not just a version control tool but their code host? After all, Github Pages are pretty cool, and free, so why not? Time for a practical example.

My amazing friend Mel made a site for Dashicons. They’re like Genericons for your WP Dashboard, and if you’re using MP6, you’re looking at them now. (Mel pointed out to me she did not make all the icons, only some, but the site is hers, so her I pick on.) The site is awesome. It’s fantastic that people can make sites like that, and you can even put a custom domain on it.

But look at it! No feeds!

Thankfully, Github pages are built on Jekyll, and you can set up feeds. But let’s be frank, if it’s not automatically set up for people, they’re not going to do it. And most people don’t do the ‘blog’ part of their Github page sites either. Now what?

Well thankfully, for anything on GitHub, since most people push releases with tags (note to self…), you can use this for rss: https://github.com/user/project/tags.atom — Sadly, I couldn’t find one for branches.

The Real Answer…

Look, at the end of the day, if you’re releasing public code, it’s incumbent upon you to make a way for your users to be able to find out, easily, when you’ve updated. Expecting them to come to your site and check is not going to work. Making an automated way to push your code, your changelog, and your update notices to people, will put it all in one go for you and make it easy. If, like me, you’re afraid people will end up getting too many alerts, make it a blog post and only do it when you know you’re ready.

Making it easier to get alerts for needed upgrades is going to make everything safer, in the long run. Think of all the security patches people are missing, just because we don’t get notified of them!

Now if you’ll excuse me, I need to sort out how to better use branches and tags.

28 May, 2013
Not RSS 2 Email
Back in 2011, I made an RSS powered email list using rss2email. The last new version was released that year, and while the last two years have worked perfectly well, there’s one small problem. The developer appears to be done with it. This happens, and the beauty of open source is that people can pick up the code, fork it, and carry on. The annoyance is that sometimes the new coders do things that break it all for you. In this case, the running fork of rss2email uses Python 3.2 or higher.

If you’re using Python 3.2+, grab rss2email the new version and off you go! But if, like me, you’re on a server that doesn’t come with that version of Python, you can start swearing. This is not something you can just upgrade, either as Daniel Eriksson explains how to do this on CentOS 6 (my flavor). Many different flavors of Linux use the old 2.x branch of Python, and there are no plans I’ve seen to upgrade any time soon.

Now I’m faced with a dilema. Do I mess around and upgrade on my own, or do I find another answer. You know I went with option B, right?

I sat and thought really hard about what I, personally, needed this to do. This is a key component to any code you’re going to write. Make sure you know what you need. Let’s break things down:

Needs
- Email to be sent to a specific address automatically when there’s a new post.
- No email sent on pages or CPTs
- Post ‘excerpt’ is message content
Wants
- Change ‘to’ email on the fly.
- Select full post or post excerpt in email
- Customize ‘from’ email address
Dream Future
- Ability to say “no, not this post”
- Customize email message
- Allow options for different post types to get emailed
That’s pretty simple, isn’t it? It’s clear cut what I need, what I want, and what I’d like to have if I have time. Not every project is this simple, but today it is.

I actually knew how to do my ‘needs’ already, but as soon as I tested it I found I had to expand on what I meant by ‘when there’s a new post.’ If I hooked into the publish_post action, the email got sent every time a post was updated too. This lead me down to Notifly, which emails a list of people for every post and comment, but not post updates. That gave me the magic of transition_post_status, which solved that first problem.

At this point, the question became “Why not just use Notifly?” The first problem I had was that it sent out emails for comments too, with no easy way to turn that off. I could have forked, and I started looking into that when I ran into problem two, which was I couldn’t change the ‘from’ email. This was something that became a bigger issue later, when I realized I needed to be able to change the from email to work better with restrictions on certain hosts and with certain mailing lists. I could still edit the plugin, but I looked at what that plugin did and what I needed and wanted. Editing Notifly to do what I wanted would mean overcomplicating it and adding a lot more options. I could fork it, but I’d be stripping everything out and rewriting if I did that, so I decided to carry forward with my own thing. I would say the plugins are similar, cousins, but approach the goal in different ways. Semantics, I know.

Once I mastered only emailing on post publish, I had to tell it not to email on non-posts. No emails being sent on CPTs and pages was easy and I could have used is_post_type() and checked for posts, but I decided to use get_page(), because that let me expand on some other features later. This was new to me, but since I wanted to use the post excerpt, this was going to be, bar none, the fastest way to pull that in.

While I love being able to read whole posts in my RSS reader, I lose a lot with it, in regards to formatting. For the site I desired to run this on, the layout is a huge thing. On top of that, thanks to some idiots, I had to turn on hotlink protection, lest they crash my server again. Also I use a lot of embedded media (HTML5 video, twitter, etc). That means the ‘whole’ post generally looks like crap. So for every single post, I custom craft an excerpt. And this is why get_page() was awesome, because I could use that to pull the excerpt.

The default WordPress emails are sent from ‘wordpress@yourdomain.com’ with the name ‘WordPress’ and while that’s great, I wanted mine to be sent from ‘Blogname’ (the email address was fine, I’ll just add it to the email list as a moderator). That changed my ‘want’ of being able to customize the from info into a ‘need’ but it was also pretty easy to do.

If I was only going to use this code on one site forever and ever, I’d probably leave it at this. But … I know I’ll want to use this around other places. I started by looking at my ‘wants’ and put those in as well.

So what did I end up with?

Post2Email

This is a simple WordPress plugin that lets you set a to email, a from email, and a from ‘name’. It uses the RSS settings to determine if your email body is the full text or the excerpt. It only emails on posts, not pages or CPTs, and not for private posts. You can only set one email because of reasons, first being I only need to send to one address, but second is that I really hate when people send me emails I don’t want or need. Limiting the number of emails you can send to will help that. It also helps you not piss off your webhost by spamming people. Seriously. You use my plugin to spam people, I will hurt you.

What about my dream features? Handling the different post types means using get_post_types(), which isn’t horrible. In theory it’s just a check ‘If the option for that post type isn’t checked, fail out.’ It’s not something I need, and I really don’t feel like auto-emails for everything is a good idea (pages and CPTs are not posts!), so I’m going to wait and see if this is a need for people.

Flagging per post I have no idea how to do, since I don’t yet know how to put a custom post option like that per-post and check it on publish. Yet. Since public posts are public, I think that it’s fine having it email on all public posts. Opting out like that is not for me, but if enough folks come up with it, I’ll consider it because it’s a good excuse to learn something new.

Customizing the message is easy and when I went back in to fiddle with internationalization and proper content serialization, I added it in. I also went and used wp_parse_args to remove setting the defaults in the database, and make it easier for me to add more options in later.
22 May, 2013