Tag: development

Stupid Easy

You have made yet-another stupidly easy plugin. I love it!

My buddy James said that after testing a plugin I wrote for WordPress that has no settings.

Frankly those are my favorite plugins, the ones where you install them and walk away because they do one thing, they do it well, and you’re done.

A plugin without options means it does the one thing, I don’t have to decide how I want it to work, and it just goes. Now, at the same time, a black box plugin with no information can be complicated and tricky, which means you have to sit and make the decisions thoughtfully at the beginning.

The first question I ask is “Who is it for?”

I love W3TC, but dear god is it complicated. It’s doing a lot of things and while it does them all very well, it’s hard to understand what all the settings mean and how they all need to work together. When I set about adopting a Varnish plugin, it was picked by my coworkers specifically because it was simple and it worked the majority of the time. Can you break it with other plugins and themes? Sure. That’s the nature of WordPress interoperability. But at the same time, it works without user interaction.

That was the key, we felt. A plugin that just runs, no user interface needed, just let it go. This was simple, this was easy, and this was direct.

Since then, I’ve added in two ‘options.’ One is the ability to define your true IP address. This is for people who are behind proxy services like CloudFlare. The way a Varnish purge works, is it sends a command to the domain name. If your domain is handled by CloudFlare’s servers, then it gets messy. The second was a ‘purge all’ button on the toolbar, which let you manually flush the entire site.

Those two settings are hard and easy to access. The defining the IP can only be done via editing your wp-config.php or via command line. Why? The majority of people don’t need it. It’s actually often a latency issue when you cache a cache with a proxy, so it’s not really the best idea in the first place. The purge button is limited only to the admins of a site, because they’re the only ones who should be flushing the cache for an entire site anyway.

Does this work for ‘everyone’? No. No it doesn’t. Of the 6000 people who like it just fine, there are about a dozen who want things differently. They want a settings page, where they can allow more people to flush cache and define the IP. They want a per-page flush button. They want better error reporting.

I’m with them on the last one but the others… well it’s interesting. Adding more complications will certainly expand the usability of the plugin, but is that the goal of this plugin? No. In many ways, it would be much better to make a second, different, plugin. Maybe an add-on. Call it “Varnish Advanced” for those people who need more power.

But the majority need the simple because I knew my target audience were the people who didn’t know or want to know the technical stuff. I handed them a plugin that works in the majority of use cases. I made sure it handled the majority of situations. And I made it so they could just install and walk away.

I do agree that it needs a little better error reporting, but even that has to be handled carefully. You can’t just hand an end-user an error without simultaneously giving them a direct way to correct it. And no ‘Talk to your host.’ is not a fix. A fix means the user can do something (hopefully simple) to correct a problem. Now, my ‘edit the wp-config file’ fix is not super simple for everyone, but at the same time it serves an important purpose. It makes someone think about how big a change is and what it means.

Knowing my users means I know they need that stop to think, and it means I know they will think.

23 September, 2015
Cookie Free Domains and CDNs
After I dropped Cloudflare I went back looking at other ways to speed up my site and what could I optimize things. As I mentioned in Static Content Subdomain, one of the benefits of that mess was to allow me to have a cookie free domain and, in having a cookie free domain, I basically made a domain that could be used as a CDN for my (mostly) static files.

It was noted then that, if you’re a non-www person, you have to actually use a separate domain. I do. I hate www in URLs. So I picked up a free domain for the site where I’m doing all this: ex-static.com. I probably could have gotten it even shorter if I’d tried sitecdn.net but that was short enough for me.

Since I already had everything over at /home/user/public_html/static I created an add-on domain in cPanel and told it to use that as its home.

Then I ran a search/replace on WordPress:
wp search-replace static.example.com/wordpress ex-static.com/wp-content/uploads wp option set upload_path /home/example/public_html/static/wp-content/uploads

Since I’d already changed my media settings, that was all I needed to really run a replace. It changed my media settings too! Since I was planning to move my static content, not just images, I changed the path too, so I had to go back and change upload_path as well, but wp-cli is my friend.

Next up, because of the static content move, I copied my wp-content folder over and added this to my wp-config.php:
```
define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/static/wp-content');
define('WP_CONTENT_URL', 'http://ex-static.com/wp-content');
```
Boom. Everything’s where I want it.

Sadly, it got messy for MediaWiki and ZenPhoto. The later doesn’t allow you to move your themes folder at all so I made a symlink to /home/example/public_html/static/themes/themename/ and called that a day. MediaWiki was a damn dirty lie.

Supposedly you can set this:
```
$wgStylePath        = "http://ex-static.com/wiki/skins";
$wgStyleDirectory   = "/home/example/public_html/static/wiki/skins";
```
As soon as I did that, I got errors all over the place and had to change the directory path back:
```
$wgStyleDirectory   = "$IP/skins";
```
Weirdly named, $IP is set as follows:
```
$IP = "/home/example/public_html/wiki";
```
I did the same thing as with ZenPhoto and made a symlink then I could change the style directory.

Lastly (and this was last for a reason) I changed my .htaccess rule:
```
# CDN
<If "%{HTTP_HOST} == 'example.com' ">
        RedirectMatch ^/static/(.*)$ http://ex-static.com/$1
</If>
```
This was last so that I could not break things mid-flight. And I added in this:
```
# CDN
<If "%{HTTP_HOST} == 'static.example.com' ">
        RedirectMatch ^(.*)$ http://ex-static.com/$1
</If>
```
Everything works as expected. And? I have cookie free domains and I’m ready to move all my data off to a CDN whenever I’m ready for that step. The CDN would only have to cover the ex-static.com domain, to boot!
16 September, 2015
CloudFlare Experiment Ends Weirdly

I ended up turning it all off for one reason only.

I keep getting a 522 error on cloudflare.com.

Now. I have a working theory that it happens when I’m hitting my own site a lot (be it for development or as recently, a lot of traffic I need to reply to), but what would happen is I got an error 522 on my sites. So I’d go to cloudflare.com to whitelist my IP, since their explanation of “This means your site is down” was wrong (site was up, I was ssh’d in at the time), and I’d get a 522 on cloudflare.com.

Let me roll back to August 1st.

That night I went to make some changes on my site to the CSS and, instead of turning on Dev Mode in CloudFlare, I did my thing with Git, pushed my changes, dumped the cache of that CSS file, and was prepared to smile at my glory. Nope! I got a 522. This was odd, since I was currently on the server via SSH and the load on the box was 0.3. Naturally I went to support.cloudflare.com to try and see if I’d missed some directions only to get a 522 there as well.

Track that for a second. I got a 522 on CloudFlare’s domain.

The possible answers I could come up with, since I couldn’t read any of their documentation, as either my IP was blocked or the cache server I was proxying through was down. Since I could log into the dashboard for my accounts, I went in and tried to guess how to whitelist my IP. I couldn’t find that, so I opened a support request:

I can’t access support.cloudflare.com because of 522s. My IP is 172.249.156.169 – Is there any way I can get whitelisted?

I got reply that it was the wrong place to ask, which I don’t think was correct. One of the solutions (per a Google cache of the support page I couldn’t access, hello) said that you could whitelist your IP to see if that helped. Cool. Except I couldn’t get the part of the page to load that told me where and how that was set.

So I asked for support with the dashboard via the dashboard support panel. Instead I got someone telling me I had to open a new ticket. And he was incapable of transferring my ticket or saying “Hey, you can’t access the right support place, let me make a ticket for you! Sorry about that.” It was akin to telling me to email them to tell them my email was down.

I fumed. And then I kept clicking until I found the place to enter my IP. I did and magically CloudFlare started working for me! I quickly went and opened a ticket to complain that I couldn’t have a ticket transferred (or made for me), and suggested this:

If someone’s logged in via the dashboard and they’re getting a 522 on ALL Cloudflare sites, it’s a logical assumption that something blocked them. But if I can log in, the odds are I’m really me, so that should get an auto-whitelist. If that isn’t possible, can it be detected and alerted? “Hey, we noticed your IP is blocked. Would you like to white list it, since you’ve logged in we can be reasonably sure you’re not an asshat?”

They replied with a standard ‘A 522 means…’ and told me to whitelist their servers on my server firewall. For some reason the email didn’t get to me, so I made a new ticket.

In this ticket, I had to wait until I got another 522 (end of August) and when I sent in my error ID and a screenshot, I was told this:

This was a timeout between our cache server and the origin server that hosts support.cloudflare.com.

I think he actually meant “Our cache server was down.” because at that time I couldn’t get to any CF hosted site until I rebooted my router and got a new IP.

I don’t really buy this, though, and I think their IP block is too aggressive. I would run into it all the time when I was at a hotel. I’d be reading comments on my own sites and get blocked. And every single time I got blocked, it was from all of my domains and cloudflare.com. Sketchy as hell to me.

When I added in the problem that ‘always up’ actually meant if your site was down they’d put up a CloudFlare page to apologize for the site being down, I decided to turn it off. It clearly wasn’t helping me as much as I’d hoped.

This isn’t to say CloudFlare is terrible and you should never use it, just that it proved to be too frustrating for me to want to use.

14 September, 2015
Encrypt My Site, Please!

By now everyone running a website has heard about how Google gives sites running SSL a bit of a bump with search rankings. It’s been a year since they started doing that. The bump is not significant enough to impact most people, but making all the things HTTPS is still a good idea.

It’s really all about security. I personally use HTTPS for the backend of my WordPress sites. Logins and wp-admin are all secure. The same is true for my MediaWiki site and my ZenPhoto gallery. I access things securely because the data I transmit could be important. Sure, it’s just passwords and such, but then you look at my site where I sell eBooks.

That site is on the same server, the same account, and the same WordPress install as this one. You bet your ass I’m making it all secure. But this comes at a cost.

The invention of SPDY aside, HTTPS is rarely as fast as HTTP. It can be difficult to set up caching or implement terminations like via Pound or Nginx in order to cover for the fact that Varnish doesn’t cache SSL. These things aren’t impossible to do. They’re just harder. And they’re generally going to be slower than plain old HTTP.

The question has never been if they can or cannot be done, but if they can by entry-level people. Certainly we can say “If they’re not using SSL for all the things, they’re not ready for a great volume of business” and use it as a demarcation for things. And when we’re communicating our private lives, we should certainly consider this. But then, this site, where only I log in?

Do you need SSL? Would it make you feel better or more secure? All you can do is comment. Do you need the feel-good? Do I need the extra security? If I decide yes, then I have to consider the weight this puts on my site. I have to consider how best to cache the content.

I also have to think about how to get a certificate and SSL certs can be the biggest Internet scam out there.

It’s how much for a multi-domain, including subdomain, SSL cert a year? A few hundred? It’s a bigger hassle than the EU Vat drama. It’s expensive, it’s a hassle to get set up, and install. Now thankfully, next month we’re expecting Let’s Encrypt to show up and they’ll make the cost less prohibitive. It doesn’t make the drama of installing the certs any better, but it’ll lower the bar for people who are trying to make things secure.

Yes, you can get StartSSL for free, but it’s not as simple as all that. When all you need is one certificate, it’s only about $10 a year and that’s fine. When you start getting into the need to secure all the things, it’s a mess.

What has to happen next, though, is for sever software to step up. Apache and nginx are both far faster now than they have been, but they’re our ultimate breakpoint. PHP has to push itself to handle things better and faster, lest we run over to HHVM. We are getting better of course, but if we want everyone to be on HTTPS, we have to make it easy.

Not easier.

Easy.

The bar is still too high for the majority of people, and that’s a problem. Either we start offering hosting services to handle this or we start making the software easier. But we can’t just say “Oh, it’s simple to make your site HTTPS and fast.” because it’s not.

12 August, 2015
Don’t Publish Bad Code

I thought it was self evident, but two of my more respected programer friends missed the point or, rather, took notice with one aspect.

So let me rephrase what I meant when I said it was okay to write bad code.

Write all the bad code you can. Learn from it. Make it better. But the code you publish should be the goddamned best damn code you’re capable of writing at that moment in time.

The point I was trying to make was not to let the fear of ‘This code is shit’ stop you from learning and improving. That’s like saying if you can’t play a piece of music the first time out, you should quit. That’s stupid! Few people can do that! The rest of us have to practice and learn and keep going.

And yes. That means sometimes when we give a public performance we screw up. That doesn’t mean we shouldn’t perform. That doesn’t mean we shouldn’t fail.

You’re going to fail, okay? Just give up on that wish. Everyone fails. We fail more times than we succeed, and that failure hurts more than the success feels good.

When you do a thing, do it to the best of your abilities and no less. If you’ve left a comment of “Come back and fix this.” then you damn well go fix it before you release the code. Writing bad code is no excuse to slack off, it’s an acceptance that not everyone gets it right from the start and you’re going to have to learn from it.

So learn.

3 August, 2015
It’s Okay To Write Bad Code

We all write Bad Code.

We all write insecure code.

We all can learn.

When I posted about bad code, a reader remarked he’d done those things when he was new. So did I! So does everyone. We learn by copy/paste and seeing “Oh! Hello World actually worked!” Those are wonderful moments where we high-five ourselves and feel like we’re learning something cool.

Everyone makes mistakes. Everyone writes bad code. Everyone misses something. These are all parts of the learning process. So

Bad Code Educates Us

When we write bad code, and someone calls us out on it, we learn something. Negative reinforcement is a terrible thing, but those lessons tend to stick with us better than the best positive ones. We remember the feeling and we do anything we can to avoid it again.

Bad Code Humbles Us

We’re not perfect. You’d think we don’t need a reminder, but our egos can get the better of us. We start to think we’re awesome and know everything and are always right. We’re not perfect. We’ll never be perfect. Don’t use this as an excuse to write sloppy code, but be aware of your inherent imperfections.

Bad Code Inspires Us

When I see bad code, it reminds me to be better and do better. It goes back to the education thing, but really it’s the desire not to be shitty that inspires us to do better. The positive feedback loop being what it is, we really want to be better and have that feeling.

Bad Code Entertains Us

I have a site where all that exists is code that ‘breaks’ your site. It’s funny in a way, to learn how to do things by doing it wrong. When I see how far off I was and how bad it was, I laugh. Because in being educated and humbled and inspired, I find the delight in the universe again and laugh.

What Do You Learn?

What do you learn from bad code?

27 July, 2015