Author: Ipstenu (Mika Epstein)

A Monstrous Regiment of Content
Any similarities to website configurations, current or defunct, is probably somewhat intentional. But I’m not naming names here in this tale of woe.

The situation:

You have your website: domain.com

You have a staging version where you test all your code: stage-domain.com

Your coders edit the theme code, install plugins, configure them, etc. At the same time, your editors edit content, make posts, etc. The code (plugins etc) is managed by Git because you know you should be using versioning. The posts are not because… WordPress.

The Problem:

In order to post content, you have to push code and content up to the production server. This means that if you’re trying to upgrade WordPress, you have to put a hold out on content until the upgrade is done. How do you keep the two in sync, without goobering your content?

An Answer:

Decouple content and code.

First let’s version control the php files. This means your themes and plugins will all be edited on staging, and when you’re done, you check the code in and then check it out on production.

Next we attack the DB. Have a job that, when you check out files in production, it copies up only following tables:
```
_options
_users
_usermeta
```
This means that all your code (plugin settings, theme settings, etc) gets pushed live, and all your content remains isolated. If you have extra tables, you may need to make allowances for them (like, say _podpress or _badbehavior), but you can find them quickly looking at the current DB. You’ll want to add these as necessary, or not. I’d count _podpress as ‘content’ and leave it out (we’ll get to what to do with it in a second), and _badbehavior as transient data.

On production, you have your content makers be Editors. They edit the content live (because you trust them). If you want to be extra secure, lock down the server via IP rules. At the end of every day, run a reverse sync, where the staging DB’s posts and content are replaced by the live site’s, thus ensuring everyone has the ‘live’ data. Obviously you’d want to script in a serialization safe search/replace after every sync (and have an auto-backup taken before any messing about starts).

It’s in the copy back that we decide what to do with the other files. Either make an exclude list or an include list, whichever makes you feel safer.

Includes would be:
```
_commentmeta
_comments
_postmeta
_posts
_terms
_term_relationships
_term_taxonomy
```
And then anything else you want like _podpress (see? I told you I’d get back to this).

Excludes would be anything I have in my push script from before, so _options etc. To this I’d also add _badbehavior or anything transient. I don’t really need it.

Pitfalls:

Content isn’t just posts and pages. What if your ‘editors’ need to edit widgets?

What if they don’t? StudioPress’s Genesis Framework has a totally awesome widget called “Featured Page” which lets you pick a page, check options, and off you go. What if you had a page called ‘Header Widget’ and in your widget area for Header, put that widget, pointed it to that page, and checked ‘Show Page Content’? Now your editors just need to edit that page!

What if they still do? Grab a plugin like Members and make a special role for “Super Editors” to let them make widget changes. Of course, now you have to uncouple _options and you’ve lost some of the magic here. This is a bad idea. You want to decouple content and code. Using Widgets for this is a cool idea, but what if you did it another way entirely. What if instead you used custom post types, and just had it show the most recent in the ‘spot’ for that header? Say you wanted an ad to show at the top of the page. Make your CPT for ‘header ads’ and write a post. Then schedule another for Wednesday at 3pm. Boom, your ad gets replaced! This also makes it easy to go a step further, make a Role for Marketing or Advertising, and now only they (and admins) can mess with ads. Downside there is you may end up with a lot of CPTs.

What about when WordPress updates? Well, that’s something to be careful over. If you update staging to (say) 3.5.1, but production is on 3.5, the tables will get updated. Thankfully, WordPress rarely messes with posts and comment tables. The ones that normally get poked with an update is _options, and we’re syncing that anyway. Still, you should set aside some time to test in staging before you go ahead and push this. Since we’re only posting content on production, this will have no impact on your editors.

Alternatives:

Put the content tables on another database. While WP doesn’t make it as easy as it does for custom user and meta tables, certainly you should be able to fiddle with that. Then just sync the rest of the tables. Code like hyberDB already lets you split the DB for load balancing, so you could fork that.

Or … Sync the whole database. But that defeats the purpose.
12 February, 2014
Forget 100%

Can I tell you a secret?

I hate the five nines. The Six Sigma Stigma has me wishing that everyone who tells me they’re a ‘black belt’ please die in a fire. It’s not that I don’t think that the process can work for some people, or that it’s useless as a whole, but that I think too many people treat it like an MBA. “I did this thing for a few months, I am now an expert.” I had a bunch of coworkers who did that. I hated them. I got to the point that if you said “We need five-nine reliability” I had a Pavlovian reaction that involved me rolling me eyes and tuning out.

Now this doesn’t mean than I don’t think 100% ‘uptime’ in anything is a nice goal, but I see it as a lofty goal. Look, you know this stuff already. I will not walk down the stairs successfully 100% of the time. I will not have the next key I strike on my keyboard function as I expect 100% of the time.

So moving this off and saying “I don’t need 100% uptime, I need 99.999% uptime.” doesn’t actually change anything. In fact, I’m willing to bet that a lot of people look at the five 9s and think that it’s so close to 100% that they should never see or notice an outage. Thanks, Six-Sigma people, you just made 99.999% synonymous with 100%.

That wasn’t the secret, though.

My secret is that I don’t care about 100% uptime in anything.

I worked for too long in deployment to understand that there is no such thing as 100% uptime for anything. There are ways to minimize and mitigate downtime, and there are ways to make sure it causes as little impact as humanly possible, but there’s no way to avoid it. Ever reboot your computer? Of course! Ever upgrade WordPress? You have then experienced downtime. It’s a nature of life. I expect it, I don’t sweat it.

So if I don’t care about 100% uptime, what do I care about?

Reliability, accountability, responsibility, and timeliness.

I was reaching for the words that end in “ibl”, but really the root ofable is my concern above all else. Are they able to handle it when things go pear shaped? Are they able to fix problems quickly, correctly, and efficiently? Are they able to prevent the exact same error from happening again? Are they able to own up to their mistakes?

I don’t expect anyone to do all that 100% of the time, but I expect them to care about the things that are important to them as an entity. My webhost should care about the severs not being on fire and serving up webpages. My bank should care that my money is safe and available. My government should care that it’s … Too soon? Anyway, the point is that you should care about what you do, and provide the best service you can. Now, if 50% uptime is your best, maybe I’ll look for someone else. I am reasonable about these things. If email goes down, how fast did you get it back up? But to me 50% isn’t reliable unless I’m looking for something that, intentionally, only works half the time.

All this said, I don’t actually look at the uptime numbers all that much, unless I feel that the reliability is sub-par. The actual numbers, the metrics, the absolute “This service is up 100% of the time or your money back” is not really what I count on. My friend Pippin said it wisely the other day:

I have far more faith in a company that encounters occasional problems but responds incredibly promptly than one that has fewer issues but doesn’t respond half as well

He happened to be talking about a brief (like 10 minute) outage on his site when all databases were inaccessible.

Don’t bank on the percentage, bank on the ability to react and come back.

10 February, 2014
Just Ask

Someone asked me why I spoke at some events and not others. Or why I was on some podcasts and not others. For WordPress, I do generally apply to speak if I’m going (for what I consider obvious reasons, I’m good at it and I actually enjoy it, shut up Jenifer, you were right) but I also like going to WordCamps just to learn and be social in a businessy sort of way. This is my job, after all.

So why did I talk on WPWatercooler or MeetWP or The Matt Report? Why did I do the interview with Code Poet? It’s so simple you’ll laugh.

They asked.

I very rarely say no. The two days I tend to are Fridays and Saturdays. I’m not online Saturday, and Friday is usually pretty busy for me. Okay, and I admit Sundays I’m usually out at the archery range or solar (it’s an arts and crafts thing), but still, with enough warning I can make some time. The point being, I’m totally fine with people asking me “Hey, can you be on our thing?” Unless you’re totally hate filled, anti-everything, jerks (which is … surprisingly hard to find in the WP world), I’ll likely say yes if I have the time.

Mind you, I don’t listen to or watch most podcasts or hangouts in real time. I just don’t have that time anymore. I have a backlog saved, and when I’m at work, I play them on my iPad when things are slower.

I am sorry to have had to turn down WordCamp Orlando last year, but I’d just come off of three funerals and 6 events in 8 weeks, and I was burning out emotionally (I’m putting you on my list for 2014!). I’m sorry I had to turn down a same-day request from the Matt Report once, but it was just phenomenally bad timing that day. I didn’t even see the email until it was almost too late. Yeah, that kind of day.

The point to all this is that while I know a lot of people don’t find me super approachable because I like having my personal space respected, and I feel that an unsolicited email is roughly the same as a phone call, my real intent with that viewpoint is to make you think. Think about what you’re asking. Think about what you’re giving to people and what they’re giving you. Don’t take brutal advantage of their good nature, and always respect them as humans with lives and agendas that may not be 100% the same as yours.

See that’s not hard? Give and take is what makes WordPress great.

7 February, 2014
SSL for One Domain on Multisite
To start with, I made a mistake and assumed, bad me, that the Terms of Service that let me collect donations for my ebooks would similarly be okay with collecting payments for said ebooks. Alas, no. “Digital goods including digital currency” are not permitted, and that was my bad. It resulted in me losing my entire account and having to fight to get my customers their money back.

Meanwhile I decided to get started on making an easy way for people to pay and stay on my site (like Stripe), and this, no matter what, means I need to have SSL.

Normally that’s not too much of a problem, but my store happens to be a subdomain of a mapped domain on a multisite. My WordPress install is at ipstenu.org. This site is actually tech.ipstenu.org, and my store (store.halfelf.org) is actually hshop.ipstenu.org (stands for HalfElf Shop…). I used domain mapping to point halfelf.org to tech.ipstenu.org, and store.halfelf.org to hshop.ipstenu.org. While I could just edit the site and home URL in the ‘Edit Site’ page, domain mapping is needed for in order to tell WordPress that the domain is really a thing.

Setting all that up was the easy stuff, though. The SSL part was something I’ve poked at before and given up, since multiple domains and one SSL cert is a pain in the ass. But today, if you go to the Half-Elf Warehouse, you’ll see it’s all SSL! (NB: It was. It’s now only SSL on pages that need SSL, to allow for better caching.)

You will need….
- An SSL Certificate
- An add-on domain
- wp-config.php edits
- .htaccess edits
- WordPress HTTPS Plugin
SSL Certs

This is the easy part. You need an SSL certificate for the domain you need to protect. If this is the only domain you want to add this on to, it’s relatively easy. If you need to add SSL on to multiple domains, check with your webhost.

I actually have multiple SSL certs. The problem with multiple SSL certs is that a wildcard one for subdomains costs around $300 (this is on Comodo), and I have three domains I need to protect on one server… Oh. Wait, wasn’t this a problem before? As it happens, I’ve got SNI on my Apache instance now, so that was fixed. I picked up a cert for store.halfelf.org and set it up, done. Except…

Add-on Domain

Why this? Well it’s funny. I used to always tell people ‘Use Parked Domains, it’s way easier’ and this is still true, it just has a caveat of ‘unless you’re trying to use SSL.’ Now that I am, I hit a sticking point where a parked domain cannot have it’s own SSL cert, but an add-on domain can. This was a simple fix. I deleted the parked domain and flipped it to an add-on domain. Then I added the certificate in for my site and now I have https on ipstenu.org and store.halfelf.org but not halfelf.org. Why? Because halfelf.org and store.halfelf.org are separate add-on domains. Had I bought a wildcard cert for halfelf.org, I could have made halfelf an addon, and store.halfelf a parked domain on top of halfelf, but this works too.

The other option, of course, is a multi-domain cert, which is too much money for my tastes, and I don’t need it all the time. I have SNI, which makes this so super easy for me, it’s silly. Just add the cert for the domain and have a party.

WP-Config

But today I only want to force one of my mapped domains to be SSL:
```
if ( $_SERVER["HTTP_HOST"] == "store.halfelf.org" ) {
    define('FORCE_SSL_ADMIN', true);
    define('FORCE_SSL_LOGIN', true);
}
```
No that was it. If it’s two domains, it’s this:
```
if ( $_SERVER["HTTP_HOST"] == "store.halfelf.org" ) { ...}

if ( $_SERVER["HTTP_HOST"] == "ipstenu.org" ) { ...}
```
and so on and so forth. Why not using an OR check? Because it failed miserably when I did that. I suspect it’s due to ipstenu.org being my main domain, but I was tired and stopped here.

.htaccess

Okay, now I want my domain to default to SSL when people visit too!
```
RewriteCond %{HTTP_HOST} ^store\.halfelf\.org
RewriteCond %{SERVER_PORT} !443
RewriteRule ^(.*)$ https://store.halfelf.org/$1 [R,L]
```
That was easy.

WordPress SSL

What about making everything on my page load SSLish? Install and activate? That was it? Oh. Okay.

Verify!

Hey! Looks good! Actually I’d had a problem when I first ran this.

Yeah, that little yellow triangle. What the heck did it mean? I trotted off to Why No Padlock? and got an error:

SSL verification issue (Possibly mis-matched URL or bad intermediate cert.). Details:
ERROR: no certificate subject alternative name matches

That didn’t help me at all, so I viewed page source and looked for http://store and didn’t find anything. Then I looked at the console and saw that it had an error on some JS:

//Moral? Always read the ToS.
5 February, 2014
Why Not Multisite?

My most popular post ever has been Don’t Use WordPress Multisite, which I wrote in 2011. It’s 2014 so it was time for a revisit of this concept.

The point I made in 2011, and again at WordCamp San Francisco in 2013, was that while Multisite is amazing and awesome and wonderful, it’s got limitations. I love it, I think it’s perfect for me, but I always keep those limitations in mind and try to educate people as to what they are. I think I have a pretty good grasp on them by now, and so does Nacin:

@jbenton @Krogsgard Basically read everything @Ipstenu has written (including when she suggests to not use it).

— Andrew Nacin (@nacin) December 20, 2013

This may make you wonder what I could possibly say that hasn’t been said before? The questions remain the same, but the answers change a little as time goes by. I want to stress that for every single reason I’m going to list as a case for not using Multisite, I probably have broken. Rules aren’t meant to never be broken, their meant to make sure we understand what and why we’re doing what we’re doing.

The absolute number one aspect about Multisite that you cannot forget is this: Multisite is for running multiple WordPress blogs (aka sites) on one install (aka a network), with separate content but a shared base for code and users.

If I was to make it a rule it would be this: Don’t use Multisite unless you want to run multiple WordPress sites, each with their own admin section.

But …

You know how I made that list of reasons? Like you don’t need it to categorize posts and make a site that’s all the same (or even all different), and I still firmly think that no one has any reason in the world to have a site that duplicates content 100%. Sometimes you do need Multisite for this stuff. Or rather, sometimes you can use Multisite, and it’s not the wrong choice!

You don’t need Multisite

WordPress comes with categories so just use that. Want to remove the word ‘/category/’ from your permalinks? WordPress SEO (by Yoast) can do that, as can No Category Base. Need to limit an author to a category? Use Author Category! In addition, there are Custom Post Types, which you can create for each ‘category’ and then limit authors using Custom Post Type Privacy.

WordPress comes with categories and Custom Post Types which let you keep your site looking exactly the same from page to page to page, which is awesome. This is, in an essence, what WordPress was made for. If you don’t want your ‘sections’ to look the same, hey theme templates will let you customize the look and feel of each category (or CPT) as you want. WordPress is crazy flexible, and plugins are phenomenally wonderful to let you customize WordPress to the nth degree. Like categories as subdomains, which means it’s theoretically possible to do the same for a CPT. I know you can map CPTs to domains already.

Before someone gets all snippy about how too many plugins make your site slow, I have to point out that too many poorly written plugins do this. It’s not the number, it’s the quality. A bad theme can slow your site down too, and I see that every single day.

You could use Multisite

So why would I use Multisite for those situations?

What if your ‘sections’ aren’t just meant to segregate content? Like you’re selling eBooks and you want to run a whole special ecommerce tool for tracking and payment. Or maybe you’ve got a membership tool and want to set up a news site where people can register and write, but keep them off the ‘main’ site where you’ll be linking featured content back. What about a site that will exist for a year to represent an event like a WordCamp, and then be ‘retired?’ Suddenly we’re talking categories in a different light, and maybe, just maybe, Multisite would work for this.

It’s easier in Multisite to totally re-skin a section because it’s using its own theme. You can quickly spin up a child theme just for one site, or use a plugin like the CSS Editor that comes with Jetpack to allow each site it’s own custom CSS.

Because each site is separate, I can limit plugins and prevent load creep per site. Not every ‘section’ needs the same plugins, after all. And at the same time, the ones that do can be network activated. Also a growing number of plugins are taking Multisite into consideration, like W3 Total Cache now lets the network admin configure a large amount of caching settings for the network as a whole! This number grows every day.

Which Should I Use

There isn’t one perfect answer here, but that’s true of all things WordPress. I think my cardinal rules of Multisite are mutable and all colored with a great deal of “It depends.” For every single reason I wouldn’t use Multisite, I also would (and probably have) used it. You have to take into consideration supportability most of all, though. Multisite’s worst flaw is that it leads to cases where your eyes are bigger than your stomach, and your network becomes huge and unwieldily before you’re ready to cope.

The one rule I’ve yet to break, and one I strongly feel no one should, is this: Never use Multisite if your users cannot know about other sites.

Other than that? Hey, the world is your oyster!

Multisite is big. It’s daunting. It’s complicated. It’s still, and probably will always be, harder than running a single blog, which makes sense. You’re no longer running a site, you’re running a network.

3 February, 2014
Giving Back Anew
One of the things that makes WordPress special is that people give back. Even people who make their living off WordPress via their plugins or themes give back in some way, be it testing new versions, submitting patches, or even making suggestions and asking questions. I got my start by giving back and answering low-tech questions in the forums.

Thus it’s natural that, while testing Easy Digital Download’s new version, I reported problems upstream:

And perhaps more natural that I made my first attempt at a patch on Github for it as well:

My code patch is a total of three lines. Four if you count the one I deleted. That’s all it takes to help contribute. You could even fix a typo.

What does this have to do with ebooks? The patch I submitted was for the display of the [downloads] shortcode, which will allow you to more easily display a flexible column list of your downloads. If you’ve seen my Catalog page, the books are listed with multiple items per line. But I’m not using any columns. With my code patch, you’ll be able to do this:

[downloads columns="0" thumbnails="true" orderby="title" order="ASC" buy_button="no" category="wp" price="no"]

Which outputs no columns and no breakpoints at all. Then you just need some CSS.
```
.edd_download_inner {
	float: left;
	width: 290px;
	margin-top: 10px;
	margin-bottom: 20px;
	margin-right: 15px;
	position: relative;
	height: 300px;
	padding-top: 10px;
	background: #F7F7F7;
	border: 1px solid #ddd;
	text-align: center;
}

.edd_downloads_list.edd_download_columns_0 {
	width: inherit;
}
```
Voila! Flexible columns!
31 January, 2014