Author: Ipstenu (Mika Epstein)

Failure Is Always An Option

No matter how hard you try, how well you test, and how smart you are, you are going to screw up. I could probably just close this post saying that, but for some reason, people don’t like to accept failure as an option. We don’t want to do anything but succeed and think that we can get everything right, the first time, and every time.

“Well … you can’t!” as Mal told Jayne. You can’t get it right every time, and you’re probably never going to get it right the first time, mostly because it is the first time. Failure is an important aspect of progress, which we all know, and we’ve all heard, so I won’t delve into that. What I do what to do is remind you how to move from failure. What are your takeaways and what do you do next?

When software fails, the first thing you do is look at the error. I like to describe things in the plainest English possible: I entered in my email, clicked ‘submit’ and my webpage turned into a blank white page.

From experience, I know that a blank white page is often a PHP error, but by presenting it to myself in straightforward terms, I now know what to search for if I didn’t know that already. Search engines have come a long way in a short time, and if I search for ‘wordpress blank white page’ I get a lot of hits about the ‘White Screen of Death.’ Now I’ve learned a new term and I’ll file that away for later searches. Awesome to know. Now that I’ve found what the problem is (PHP) I can look into debugging. I can read the PHP error logs, or in the case of WordPress, turn on debugging to see if anything gets output.

The point to this is that finding an error is the first step in learning. I take what the error is, what the failure is, and I go forward. Failing isn’t a stop, it’s a pause in the process. Too many people take failure as a sign to stop everything, and while yes, failing does mean you’re doing_it_wrong() somewhere in there (or perhaps you’re not doing it as well as the next guy), and sometimes it does result in scrapping everything and starting over, it remains a sign to look at what you’re doing, not to stop entirely. When you don’t know the software well, or the tools, or anything at all, that initial failure of ‘It’s broken’ can be hard to overcome. The fear of failure keeps you from just taking the next step of ‘What do I do?’

Once you’ve sort out what your problem is, learn from your failure and pass it on to the next guy. The reason a lot of people hate forums is that someone asks a question and either never replies, or leaves a ‘fixed’ message with no explanation. That makes it impossible to learn from the fail for the next guy, and you force them to reinvent the wheel.

I’m all for learning by doing, but progress happens because we share the answers. Pretty much all school is for a lot of people is memorizing the answers, which has it’s place. The rest of us learn the theory from seeing the path. We see the start, the fail, the middle, and the win, and it’s that journey that teaches us where to go next and invent new things.

23 October, 2012

WordPress Cancel Post Button

Someone asked about this in the forums. I can see why folks would find it useful, so here’s a simple addition to add a ‘Cancel Post’ button to your publishing metabox.

This plugin checks what post-type you’re on and redirects you correctly for pages and CPTs.

To Install

Make a file called cancel-button.php and put it in your mu-plugins folder (if you don’t have one, just make it in /wp-content/). In that file, paste the following (yes there’s no ending PHP tag, it’s okay, you don’t need it):

<?php

/* 
Plugin Name: Cancel
Plugin URI: https://halfelf.org/
Description: Adds a 'cancel' button to posts, next to Publish.
Version: 1.0
Author: Ipstenu
License: GPL2

*/

add_action( 'post_submitbox_misc_actions', 'author_in_publish' );

function author_in_publish() {
    $screen = get_current_screen();
    $cancel = get_admin_url();
    if ( $screen->id == 'post') {$cancel = "edit.php"; }
    else { $cancel = "edit.php?post_type=$screen->id";}
    
    echo "<div class=\"misc-pub-section\"><a class=\"button\" href=\"".$cancel."\" id=\"post-preview\">".__('Cancel Post')."</a><input type=\"hidden\" name=\"wp-cancelpost\" id=\"wp-cancelpost\" value=\"\"></div>";
}

This will add the button for all your sites on a network, if you happen to use Multisite.

19 October, 2012

Auto Multisite Registration
There are plugins for this, and I’m rather fond of them. If you just want all new users to be added to some (or all) sites, then I suggest you use Multisite User Management. It’s a great plugin, and lets you pick and chose. But similar to how sometimes you want users to register per site, you may have a situation where you want users to be added to any and all sites when they visit.

So how do we do this? It’s really not that painful, just make a add-users.php file in your mu-plugins folder with this:
```
<?php

/*
Plugin Name: Add Users
Description: Add users to blogs when they visit.
*/

function helf_add_users( ) {
    global $current_user, $blog_id;

    if(!is_user_logged_in())
    return false;
 
    if( !is_user_member_of_blog() ) {
        add_user_to_blog($blog_id, $current_user->ID, "subscriber");
    }
}

add_action( 'wp' , 'helf_add_users' , 10);
```
This code will automatically detect “John Doe is logged in.” and “John is not a member of this site.” If both of those are true, then it says “We will add him as a subscriber.” You can change subscriber as you see fit.

Would it be more efficient to just do this check on registration? Sure. But there are moments you don’t want this. If you wanted to get extra sneaky, you could set this to only run on a specific page, and make that page password protected.

If we want to add in a couple extra layers, that’s also not terrible. Let’s say we want people to press a button ‘Join This Site’? I have to admit, this actually took me longer to hash out than I wanted it to, mostly because I decided if I was going to do this, I should do it all the way.

That’s why I came up with Join My Multisite, which is a handy plugin to give you some more options. It’s per-site configurable, so your site-admins will get to decide if they want everyone logged in user to be added to their site, or if they want a widget, or if they want nothing at all. I put some time into thinking about if it would be a good idea to have the network admin be able to pick, but when I got down to brass tacks, I realized there was no way to easily force a widget (i.e. the button to join the site) for all sites and make it always look good. If you need that, you should fork the plugin and hard-code in the widget.

In a way, this is an extension of the old ‘Add Users Sidebar’ plugin, which drifted off into the wayward lands of not-supported. I never looked at that code, though, and instead wrote all this from scratch.

In addition to all that, Join My Multisite gives each site the ability, if registration is open, to easily make a per-site registration page. That one was Mason James’ suggestion.
17 October, 2012
Cloudy With a Chance of Upgrades

We’re all being seduced by the cloud. Amazon’s AWS has become so popular and so, seemingly, inexpensive, that people are looking at it to run a website, instead of traditional hosting. Understanding the cloud actually was the first post on this site, and while two years ago I struggled to comprehend it, today I find myself at a loss many times when asked ‘Do I need the Cloud?’

I don’t need the cloud for webhosting, and you probably don’t either.

Yes, I have a semi-cloudlike host on LiquidWeb right now, for seven of the ten domains I manage (the other three are all on their own hosts, one of which being my me Elf Dreams, where I talk about DreamHost stuff). I don’t plan on moving the other seven simply because it’s a massive effort. It’s easier to move yourself across country than it would be to move all my sites, re-build the server as I need it, get the code for the new OS (CentOS vs whatever I move to). Heck, I’m dreading upgrading to CentOS6 because of how annoying that is.

The point is that I do know and understand what the cloud is and does. It’s very cool, if you’re big enough to need it. Most indie sites are not.

How the cloud works, in general, is based on the shared resources principal. Everyone shares all the resources in the cloud at all times. If you think back to shared hosting, everyone shares all the resources on that server. The difference between the cloud and the shared is that the cloud has infinite expandability (kind of, but you get the idea), where as a shared host is limited to what it is physically. But when we were back on shared hosting, we used to have a problem with bad neighbors. You know, the other guy on your server who got tweeted by Felicia Day or Wil Wheaton, and suddenly all the sites on your server went down like a bad quiche.

That can happen on the cloud too.

It’s not exactly the same, but when you’re on a cloud, you’re on a server with a lot of virtual machines (VM). A VM is a “completely isolated guest operating system installation within a normal host operating system” which is a confusing concept. The reason they’re good is that a VM isolates your hardware in a funky way, making reboots faster, while letting your VM instances share a bunch of hardware and become faster. The flip side to this is that you’re still on a real server. Instead of everyone sharing the same CPU/RAM, you get partitions so I can only use X amount and you can only use Y, and thus we don’t kill each other, until we start slaughtering input/output.

Disk I/O (input/output) can be best explained if you’re an older computer user. Remember when we used to play “Where in the World is Carmen San Diego?” and we’d press a button to ‘travel’ and that old floppy drive would grind like a cheap espresso brewer? That’s I/O. The disk is being read and the data is being input from the disk and output to your Apple IIe. The basic concept of this still exists, and it makes sense when you remember we have to read the data off somewhere. So if you happen to be on a box that is getting a lot of traffic, and using a lot of disk I/O, then you’re going to be slow.

There are ways to mitigate this, of course, but that isn’t the problem. The problem is that you don’t always know that you need to, or how you should. And even if you do know, it’s not always very easy to do it, so the little guy, who doesn’t have the resources to do it themselves, or the money to hire someone, are left hoping that they’re okay, and often end up paying more than they need to.

And this is why you and I don’t need the cloud yet. The cloud is something I might need, but for now, there are no benefits I don’t already have with a well optimized server and a well built site. If I was a bigger site, or a company, I’d be looking at it as my next upgrade, and studying my past growth. It took me almost 10 years to grow to need a VPS, and it will likely take me at least 5 more before I need to seriously consider cloud. By then, something new will be the big thing, so the best thing I can do is study nginx and keep a finger on the pulse of web technology.

Of coures, the one major advantage to the cloud, and the reason I still see it as being around for a while, is the ability to scale up and down. A webhost provider can cannily utilize that to provide scalable shared hosting, so if you have a bad neighbor, they can be scaled up with less impact to you. But so far as I know, we’re only there with VPS demi-cloud providers right now. Give it time, and the cloud as we know it today will be tomorrow’s low-end hosting.

11 October, 2012
Subdomains Back Where They Belong
In my last post, I talked about how I did something dumb with my subdomains.

How did I install subdomains?

Stupidly. Or rather, stupid for DreamHost. See, many other hosts, when you make a subdomain, come up with this structure for your files:
```
/home/ipstenu/public_html/
                         /subdomain1
                         /subdomain2
                         /addon.com
```
So when I made my subs, I made them similar to that. What DreamHost does is this:
```
/home/elftest/elftest.net/
             /db.elftest.net/
             /addon.com
```
I suggest you do the default! If you didn’t, however, there is a way to fix it. It’s a two step process.

1) Move the files.

I found it easier to do this in Unix $ mv elftest.net/trunk trunk.elftest.net (this moves and renames all in one). If you wanted to do it via FTP, just drag and drop, then rename.

2) Change the location in Panel.

Go into your panel, edit the domain, and change elftest.net/trunk:

To trunk.elftest.net:

Give it 5 to 10 minutes, and you’re done!

tl;dr to the whole thing is this: Trust the tool! (Sharon, that was for you!)
11 October, 2012
Is It My Server or My Theme?

This could go on any of my sites, but since the conversation started on the DreamHost forums, I thought I’d tackle it here.

When your site is running slow, it’s easy to pick on the webhost or the server you’re on, saying that’s the problem, and demanding someone else fix it. The truth is that speed involves a lot more variables than just the webhost. Sure, if your host is slow (or down), you’re stuck waiting on us, but there are a couple really easy ways to determine where the slowness is, and you might be surprised.

If you’re using a CMS like WordPress or Drupal, take a look at how long a page takes to load the first time, and then again on a refresh. When you look at these pages, they’re in PHP and take a little time to process. The more complex your code, the longer it can take to display. This won’t really impact a refresh, but it’s a good idea to see if your browser is caching anything. If the site is really slow, go look at a static HTML or TXT page. On WordPress, look at http://yourdomain.com/readme.html and see how fast that loads. If that’s slow, hey! It is your server! Open up a ticket with us and tell us that the site is slow to load static pages. It’s really important that you tell us what you’ve done, so we don’t have to waste time re-doing it all for you.

But most of the time you’ll see the html loads really fast. Why is that? It’s that pesky PHP taking a while to render. Now I know this brings up the obvious question of why would we use PHP if it takes longer to load, and the answer is complicated. There are a lot of benefits to using PHP (like being able to use those cool CMS’s to make publishing your site easier), and I’m not going to go into them. Just know that if you choose to use a modern CMS, then you’re likely going to be using PHP to render your site.

That means we have to consider how to make our PHP run faster. If you’re on shared hosting, the server side work should have been done for you, and if things are still slow then you have to consider the painful option that you did this to yourself. Don’t worry! That’s not a terrible thing, you probably just picked a theme, or a plugin, that is totally perfect for you, but a little slow. This is why people say ‘too many plugins/extensions slow your site.’ It’s not true, but the idea is that the wrong one will slow you down. And that is certainly true.

Go to Google PageSpeed Insights and check your site out. It should give you a hint as to what’s lacking. Don’t take this as the holy grail, though. Sometimes Google has really dumb advice, like ‘You should compress the code you’re using from google.com!’ Really? So why don’t you compress it, or tell me ‘Use this code instead from us! It’s already compressed!’ In theory, all of Google’s jquery code has a compressed version, but that’s not what most people see, so telling us to use it but not how is pretty idiotic, in my opinion.

I always tell people to look into minifying their output. That means you use a tool to make your HTML all mashed up together when someone looks at your source code. This simple step has amazing results for most sites. It took my Google Speed score from 71 to 81. Any score above 75 is a ‘good’ score from my experience (Microsoft gets a 77, after all, and while Google gets a 99, their main page is pretty minimalistic).

The point to all this is that your pagespeed is dependent on more than just how fast DreamHost is running. If you tell me that your site is slow, the first thing I do is look at a static page (I may even make one for you if I can’t find one). From there, maybe I’ll poke at the server, but most of the time it’s been your site’s configuration. I say this from a place of over 15 years of self-hosting: I’m nearly always the cause of my own problems.

Of course, if it’s your WordPress site being a slug, start with caching plugins and feel free to ask us for advice. If you have a wild and wooly, never been seen before, WP problem, don’t be surprised to see me showing up in your ticket.

5 October, 2012