Tag: administration

Yum!
I’ve touched on it a couple times, and it’s related to why I love things like Homebrew, but I like package installers. While I can, and have many times, installed and packaged from source, it scares me and I don’t like it. When I talked about Homebrew, I mentioned in passing that I use yum to manage packages on my servers, and someone asked me “What’s that?”

When I started this blog in 2009, the very first post was about understanding how to mess with my VPS and tweak it to work well with WordPress and everything else. In the five years since, I’ve learned a great deal about servers, tweaks, how to break things, but also how to upgrade them smartly. I’ve had struggles with SVN and GIT, but I understand that managing versions and revisions is a sane way to handle upgrades. But at the same time, not compiling code means I have more free time to mess with the stuff I like.

This brings us to Yum.

Yum is a software package manager manager, which means it checks various RPM Package Managers, sees if there is software you have that has an update, and updates it. An RPM Package Manager (or an RPM, yes, it’s a recursive acronym, just like PHP) stores packaged versions of code… I have a feeling someone’s looking at me like I spoke a new language.

Let’s step back further. Your server is a computer and runs software. Most people have the experience of installing software via packaged installers (I used to make them for a living). When you download an app onto your phone, the phone downloads the package and runs the installer. This is similar to WordPress, right? You download the zip, unpack it, and run an installer. But your server, well, for a very long time people didn’t have installer packages, they had source code. The source code was downloaded, unzipped (hush, you know what I mean), compiled, and then installed.

Credit: xkcd comic “Compiling”

Yes, compiling code takes a long time. That joke is less funny than it is accurate to some of us. It’s not something most of us do any more, though, because code now tends to come pre-compiled, and that’s where package managers come into play. You see, someone realized that they could pre-compile code for all servers. It’s not the same code for all the servers, though, because there are so many flavors of servers, it’s mind boggling.

But that said, if you know your flavor of server, you can use an RPM that matches to install software. So the RPM is like a massive server that has all the available installs for your server. When you add in yum, which installs the packages, you can then enter a world of automation where every night your server checks for new packages and installs them!

Yum has a meaning. “Yellowdog Updater, Modified.” I didn’t say it was a good meaning. Yum has a bunch of obvious commands like “yum install NAME” and “yum update” which you can use to install extra add-ons like Memcached and so on. There are also yum utilities (yum-utils, which let you further customize automation by scripting commands.

Just to touch on one at random, today I got an email from my server saying that it had run /usr/bin/yum -c /etc/yum.conf -y update for me. This is normal, I configured it to do that at midnight every day.

There are unfinished transactions remaining. You might consider running yum-complete-transaction first to finish them.

Now it did run the rest of the installs, so I did what any smart person does. I went and looked up this new command, only to find a string of bug reports from 2007-2009. It’s 2014, so I went and ran it once. It cleaned up one package and said I had another 244 left. Interesting. I ran it again. 243. I saw my day flash before my eyes and then decided to run the safer version:
```
yum-complete-transaction --cleanup-only
```
Safer and faster. Everything was cleaned, and update runs great now.

Is there a risk with this automation? Of course! Which is why I take a backup every night, right before the update happens. I’m not crazy after all.
18 June, 2014
Bad Replies to Bad Reviews

My plugin brother, Pippin, wrote an awesome post about How to leave a good bad review. In it, he mentions a pretty common kind of email/review:

Your crappy plugin doesn’t work. Waste of a download..

Hmm.. I should buy pro!

Fairly often, people get those as a review in the WordPress.org forums, and ask me (either as a plugin mod or a forum mod) to remove it. Most of the time, I don’t, and tell them that much.

You see, the issue is not that you got a bad review. We all get them. The issue is how you handle the review. If you get a one-star review slamming your code, and you reply with a reasonable response, then you’ve taken care of the matter in a mature, adult, responsible way. If, instead, you call them names or email them, well then, we’re into the other world.

If you’re demanding people remove a, single, one star review, in general I think you’re being childish. There are exceptions, where people are bitter and mean and everything falls into a hate-fest with slurs and pejoratives being slung around, and personal attacks galore, then you bet I’ll delete the thread. But you’ll probably get flagged for moderation too.

There’s a good way and a bad way to handle a bad review. The bad way comes in two main types: over reactions and under reactions. The unders, thats what you see from people like AT&T or Comcast, who pretty much ignore the complaints and use their power to delete them or shut them down. The overs are people who take their “Oh my god, this customer sucks!” to twitter and everything else, and generally make fools of themselves.

When you’re asking me to delete a forum post that says “This plugin sucks, the author won’t refund me!” and you’ve made no attempt to handle the situation, I nearly always tell you to try first. “Hey, I’m sorry you’re upset. The no-refund policy was clearly stated on the order page, and I did attempt to work with you to resolve this, but you were asking for a major modification to the code that I didn’t feel comfortable with.” The rest of what I said, though, is gleaned from the paragraph long rant about how a three sentence review was hurting his ratings and no one was downloading his plugin anymore. Clearly because of one, erroneous, one star review.

Go back to Pippin’s post. At the end, he shares an exchange with a very good ‘negative’ review, and a very good response. For the most part, that’s not what I see developers and the like doing. What I see is that knee-jerk reaction to an angry post, where hate feeds hate and suddenly you’re getting a bunch of bad reviews because you’ve been feeding the anger, and it’s a circle that ends with no one wanting to use your code because you’re mean.

Recently, a developer who fell into that cycle got ‘busted’ making dupe accounts. Sock puppets, if you will. He used them to try and push his plugins, even though his main accounts were all closed. So we emailed him. We reached out and said “Hey, you know we know this is you. What’s really going on here, man?” And we started talking! He explained his side, we pointed out that the whole thing boiled down to how he’d been mistreating users, and if he could stop that, we were willing to re-enable his account and everything.

The one thing we did not do was delete his old posts, where he’d kind of lost his mind. Those bad events in the past made him who he was, for better of worse, and whitewashing the past did not change it. There was one way to change it, and that was for him to stop acting like that and to move forward, being a better person.

For that same reason, I probably won’t delete that bad review. How it changes your product is not in the deletion but in the handling. If you take the task at hand, rise up and approach it fairly and maturely, it says more about you than anything else. If you are reasonable, thoughtful, and fair, you will have a better result in your reviews than anything else I could do with that deleted. You see, I would sooner trust a product that has bad reviews and good responses, than a plugin that has no bad reviews at all. One is understandable, the other is unrealistic.

And personally? I’d hand over that refund.

9 June, 2014
Category or Tag?
Everyone in WordPress has probably heard the advice of Lorelle VanFossen on the subject of Categories or Tags. I’m sure her 2005 post will remain, forever, one of her most popular posts, much like mine about why you shouldn’t use Multisite will be one of mine. And why is that? Well it’s simple.

She’s right.

She gives information in a clear, direct, concise way, and she’s right. She will always be right. No, sorry, if you disagree, you’re just wrong. Category abuse is like menu abuse in that it confuses your readers. If you’re organizing things in too many directions at once, the sense of location is lost and no one cares anymore.

But still, people ask which do you use and where and why? For me it’s really simple.
- Categories are organized
- Tags are free form
To me that means I need to organize my posts on a site to major topics. This is a tech blog, so I’m probably going to talk about how things are and how they do it, and how you do it. That means I really don’t need much more than three categories. I ended up with five, since I decided a CPT for presentations and another for videos wasn’t really needed. Categories categorize, though. It’s simple and straight forward. A category is a room in my house.

The tags are the items in my house and they can go in any room. They’re the minor topics of my site. Like my iPad can come into my bedroom or bathroom (we all do it), the post about plugins could be philosophical or explanatory. The little things versus the big things, as it were. The tags are all those little things scattered around the site.

But what good are they to anyone? They’re both aspects of organization, and they’re both somewhat useful to find old posts, but do your readers ever use them? It’s funny when you think about how much time we spend trying to make all these aspects of our site ‘perfect’ and how few people actually use them. Like I did a study on this site for related posts. I measured, using my analytics, how many people used them to click through and came out with a resounding “Less than a dozen.”

Same general test on another site? Over a hundred. And on that site, no one clicked on tags. They don’t really here either, but since I use categories to organize ‘sections’ of the site, those get used a lot everywhere. And if you can’t tell, this is all a lot of work. You’ve got to work hard to make the site flow right for your users and visitors. For your product, you have to consider what you’re sharing and selling, and how people logically get around. You need to study, watch, and experiment.

The real answer to category or tag is, of course, what works for you. But when you’re starting out, listen to Auntie Lorelle.
24 March, 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
On Beyond Shared Hosting

This comes up at almost every WordCamp or Meetup I go to. “How do I know when I’ve outgrown Shared Hosting?” In general, my reply is “When you’re really unhappy with your site performance, and you know that you’ve done everything right.”

For the vast majority of users out there, Shared Hosting is just fine. Even when they don’t really understand what Shared Hosting is (and if not please read Entry Level Hosting), they know this much: The site runs. And you know… that’s pretty much all most people care about. There’s absolutely nothing wrong with that. However you know that you may have outgrown shared when your site starts performing badly.

When I tell people this, they generally get pretty shirty with me. They tell me it’s the host, because this doesn’t happen on another host/localhost. In absolute fairness, sure, it could possibly be the webhost, however that’s like say your car is the only reason you get poor gas mileage. You have to consider the way you drive, the traffic you drive through (city vs freeway), the weather, and of course, the gas you put in. Where people are throwing these arguments are usually because they actually haven’t done everything right.

We’ve all done it wrong.

I’ve written code wrong before. Functional, yes, but really bad. I’ve given bad advice before. It happens. The point is that you never do things 100% correctly every time, which means the odds are against you having done absolutely everything right for the situation you’re in at that moment. And there’s the rub, isn’t it? What’s the situation? Did you study it correctly? Did you understand it right? Did you test your theories? Most of all, did you remember your server’s a special snowflake?

Accepting the fact that the cause for our sites being slow is us being wrong is not easy. But the truth is this: Your choice of hosts, plugins, themes, and features is why your site runs the way it does. And if that all adds up to ‘slow’ then you’ve made some miss-steps. Once you’re okay with that, you can make progress. Let’s do it right! This very basic step starts with being tough on yourself. Get rid of plugins you’re not using, or don’t really need. Make sure your theme hasn’t bloated itself with a million options you never use. Heck, see if anyone’s done a review on your plugins and themes. Try alternative plugins and themes. It’s always a possibility that the synergy of plugins you’re using are causing weird slowness issues that are only evident when they’re used together.

On general rule I have about shared hosting is that if I have to bump my memory for PHP over 128M, I’ve got a problem. A decent, clean, site be it WordPress or anything else, doesn’t need that much memory. If my plugins and/or themes make me use that much memory, then they’re a bad combination. The other thing to keep in mind is they may be a bad combination for how your site works. Like caching plugins, for example. I actually crashed my sever using one, because I was getting so much traffic and almost everyone left a comment, so the cache was flushing pages at a crazy fast rate. Turning off caching made it run slower, but more stable, and eventually lead to why I ended up on a VPS.

What’s a VPS anyway?

A VPS is a Virtual Private Server. It’s a weird concept, I know. A shared server is an apartment building, and a VPS is a condo. Where with shared hosting, you pay for room on a server that shares all its resources. That’s why you can have problems with noisy neighbors. If someone’s using too much power, it can blackout the building. A VPS is not just space on the server, it’s also an isolated mini ‘server’ inside the real server. So you can reboot without affecting anyone else, or install new resources and apps without sharing them. Your stuff is more separate from theirs. We call these ‘slices’ and a VPS is your own private slice.

Back in the day, I switched to a VPS because after doing the math, I realized I would spend the same amount hosting 4 sites on shared hosting as I would on one VPS. After six months, I found out how smart a move this was, as I could upgrade PHP without having to wait for everyone on my box to be ‘ready’ for it. The box was all me! I also got more memory for use, and since I wasn’t sharing it with anyone else, if I used too much and crashed things, the only person who got hurt was me!

A VPS was power, freedom, and yes more money, but it was easy to set up server-level backups. Also it was easy to add in extra caching on the server, like x-cache, or memcached, which then lets me use not a flat-file cache but a dynamic cache like Batcache. There are, of course, reasons you may want a file-cache like WP Super Cache provides, and don’t think that plugin isn’t awesome. But when a static cache isn’t quite right, this is a great idea. You can read up on Sivel’s review of various caching plugins for WordPress.

The point here is that a VPS gave me more options! I could even install Varnish on my server to use that instead. It’s also easier to add more RAM to a VPS, and allocate disk space. For most of us, disk space is not an issue anymore, but the RAM is important.

How do I KNOW I need a VPS?

Honestly, there isn’t a magic formula. I can tell you this, with regards to all types of CMSs: The more you do, the more you need. It’s really obvious, but it’s often missed. The more successful your site gets, the more people visit it, the more people comment (and you know these are all things you want), the more memory and CPU your site needs, so a-VPS-ing we shall go. It’s really like ‘How do I know I need new pants’ isn’t it? My pants don’t fit! They pinch me here or there. They’re slipping if I don’t wear a belt, and I hate belts.

Maybe you should think of the traffic on your website like eating. If you overeat once, say Thanksgiving, the pants are tight, but a couple days later it’s nothing at all. If you’re eating a larger amount for another reason (working out, growing taller, whatever), you’re going to have to get new pants after a while, because you just look silly when your pants end 3 inches above your ankles. Unlike the Hulk, you’re not coming back down to person size any time soon.

There is something good in this, though. Most sites have a pretty easy, painless way for you to move from shared to a VPS. They’ve got scripts and tools and click-magic buttons that toss your site up, change the DNS settings, and carry on.

Downsides?

You know the more power means more responsibility line? The expectation is that I’m going to manage it. If I can’t do that, then maybe I should look at Managed Hosting… but that’s another post. The managing of a VPS is a hassle. I’ve been in tears rebuilding things at 2am more than once, because I get in over my head.

So… that’s it?

Of course not. But as with all things, nothing is an absolute here. When you get beyond Shared Hosting and into what’s next, you open a door for a wide range of possibilities. And with more possibilities you have a Seussian range of options. Go on beyond Zebra and find what fits right for you.

23 December, 2013

Dashicon My CPTs on the Dashboard

To extend on what I said about how my custom post types are in mu-plugins, and knowing that I like MP6 a lot, I thought I should share how I style my icons for CPTs!

First off, the code to add tables has changed totally so I made this simple look to go through my CPTs (ebooks and plugins) and for each one, make a new item, and add that to dashboard_glance_items:

    // Adding to Right Now
    	add_action( 'dashboard_glance_items', 'halfelf_right_now' );
     
    	function halfelf_right_now() {
        	foreach ( array( 'ebooks', 'plugins' ) as $post_type ) {
        		$num_posts = wp_count_posts( $post_type );
        		if ( $num_posts &amp;&amp; $num_posts->publish ) {
        			if ( 'ebooks' == $post_type ) {
        				$text = _n( '%s eBook', '%s eBooks', $num_posts->publish );
        			} 
        			if ( 'plugins' == $post_type ) {
        				$text = _n( '%s Plugin', '%s Plugins', $num_posts->publish );
        			}
        			$text = sprintf( $text, number_format_i18n( $num_posts->publish ) );
        			printf( '<li class="%1$s-count"><a href="edit.php?post_type=%1$s">%2$s</a></li>', $post_type, $text );
        		}
        	}
    	}

Next I added in an extra function to the bottom of my CPT page for the styling:

    function helf_cpts_css() {
       echo "<style type='text/css'>
               #adminmenu #menu-posts-ebooks div.wp-menu-image:before, #dashboard_right_now li.ebooks-count a:before {
                    content: '\\f311';
                    margin-left: -1px;
                }
               #adminmenu #menu-posts-plugins div.wp-menu-image:before, #dashboard_right_now li.plugins-count a:before {
                    content: '\\f237';
                    margin-left: -1px;
                }
             </style>";
    }
    
    add_action('admin_head', 'helf_cpts_css');

No, really, that’s it. The content info is grabbed from Dashicons and I’m done. Oh and since there’s no book icon, I used dashicons-welcome-learn-more instead. This works for anything I chose to put in Right Now or my menu, so I have consistency.

20 December, 2013

Tag: administration

Yum!

Bad Replies to Bad Reviews

Category or Tag?

Forget 100%

On Beyond Shared Hosting

Dashicon My CPTs on the Dashboard