Author: Ipstenu (Mika Epstein)

I’ll be in Tybee!

There’s an upcoming WordPress Community Summit, and I’ll be attending! I was invited before I was employed here at DreamHost (who is providing lunch, yay!), so now I’m serving two purposes! The first is as a community support leader, and in that auspice, I plan to represent the common user. The second is as DreamHosts’s WordPress Support Manager, and there I will represent the support my company provides you DH users.

Do you have any topics you’d like to see me address at the meetup? Any annoying WordPress/DreamHost issues taht you’re not sure is WP or DH? Leave a comment and I’ll do my best!

24 October, 2012
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

Author: Ipstenu (Mika Epstein)

I’ll be in Tybee!

Failure Is Always An Option

WordPress Cancel Post Button

Auto Multisite Registration

Cloudy With a Chance of Upgrades

Subdomains Back Where They Belong