Tag: administration

Jetpack Menu Stats

If you run a Multisite, you have a list of all your sites in the ‘My Sites’ menu. Adding your own custom menus to that isn’t all that complicated. Here’s a quick, practical, bit of code:

<?php
/*
Plugin Name: Jetpack Menu Stats
Plugin URI: https://halfelf.org/hacks/jetpack-menu-stats/
Description: Show 'stats' in the per-site menu bar.
Version: 2
Author: Mika 'Ipstenu' Epstein
Author URI: https://ipstenu.org/
*/

function jetpack_stats_my_sites( $wp_admin_bar ) {
        global $wpdb;

        foreach ( (array) $wp_admin_bar->user->blogs as $blog ) {

                $menu_id  = 'blog-' . $blog->userblog_id;
                $args = array(
                   'parent' => $menu_id,
                   'id'     => $menu_id . '-stats',
                   'title'  => __( 'Site Stats', 'jetpack' ),
                   'href'   => get_admin_url( $blog->userblog_id ).'admin.php?page=stats',
                );
                $wp_admin_bar->add_node($args);
        }
}

add_action( 'admin_bar_menu', 'jetpack_stats_my_sites', 90 );

?>

You can tweak this to anything you want, obvious. If you change the numerical value in the add_action() call, you can move it up or down the menu. A value of 10 will put it at the top. You could probably toss in a check if the plugin was activated per-site as well (I didn’t bother for Jetpack, since I know how to tell if Jetpack’s active via is_plugin_active(), but not a sub-plugin).

As with all my code, is licensed GPL2. Use, abuse, tweak and customize. Don’t expect support, though.

Edited to fix i8n and use add_node, thanks to Thomas and kessiemeijer!

15 April, 2012

Once GITten, Twice SVN
I’ve been putting off learning git. I’m lazy, svn works fine what what I need, and … oh. Look. MediaWiki switched to git. This is a problem for me, because I upgrade my MediaWiki install via svn. When it comes time for a new version, I just run something like svn sw http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_18_1/phase3/ ~/www/wiki/ and I’m off to the races. But now I have to git off my ass and learn it.

Before someone asks, I use svn to update my code because I like it better than wget-ting files, unzipping, and copying over. I can certainly do that, but I prefer svn. It runs fast, it lets me see what changed, and it’s easy for me to back out, just by switching back to the previous version. It never touches my personal files, and I’m happy. The more I looked at git, and how it works, I started to wonder if this was a practical idea for upkeep anymore.

Now, I actually like git for development when you’re working with a team. It’s great. So any posts about how I’m stupid for wanting to do this weird thing will just be deleted. Constructive or GTFO. The rest of this post details the journey of going from ‘This is what I do in svn, how do I replace it with git?’ The tl;dr of it is that I can’t.

What I want to do

I want to check out a specific branch (or tag) of code and upload it to a folder called ~/www/wiki/

That’s it.

The road…

First up, I have to install git on my server. Unlike SVN, which has been bog-standard on servers for a hog’s age, git is the new kid in town, and the odds are it’s not on your server. Thankfully, my host had note perfect directions on installing git on CentOS 5.(I’ll probably upgrade to CentOS 6 this summer, when my sites are less busy.)

Second I have to ‘install’ the git repository. This was weird. See, I’m used to svn, where you check out code, use ‘svn up’ to upgrade it, or ‘svn sw URL’ to switch to a new branch/tag. The official directions for gitting MediaWiki were: git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git

That doesn’t tell me what version I’m getting, and I only want the latest stable release. It was unclear at this point what this cloning did, but I was told over an over that I had to clone to get the version I wanted. Thankfully, git knows a lot of us are in the WTF world, and have a nice crash course for SVN users. Most important to me was this:

So git clone URL is svn co URL and that’s how I first installed MediaWiki. But… I know MediaWiki is working on a million versions and I’m not specifying one here. The git doc goes on to say that for git, you don’t need to know the version, you use the URL and it’ll pull the version named ‘master’ or ‘default.’ That basically means I’m checking out ‘trunk,’ to use an svn term. This is exactly what I do not want. I have no need for trunk, I want this special version.

After more reading I found git checkout --track -b branch origin/branch which they say is the same as svn switch url which is excellent. I can also use git checkout branch to check out the specific version I want!

I’m very used to SVN, where I can browse and poke around to see the tags, branches, and so on. When I go to https://gerrit.wikimedia.org however, all I see are the latest revisions. The directions said I should get the file /r/p/mediawiki/core.git which makes me presume that’s what tells git the version I’m checking out, but I can’t see that. I don’t like obfuscation when I’m checking out code. After some digging, I found the URL I wanted was https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git and that shows me the files, and their tags.

The tags were important for the command I wanted to run: git checkout tags/NAME where NAME is the tag. I want version 1.18.2, which is the latest stable, so I want to do is git clone -b tags/1.18.2 https://gerrit.wikimedia.org/r/p/mediawiki/core.git

I tried it with pulling a copy of 1.18.1, and it ended up pulling about 89 megs and put it in a subfolder called ‘core’. Oh and it told me it couldn’t fine tags/1.18.2 and used ‘HEAD’ instead, which put me on bleeding edge. It took a while to find something that looked a little better:
```
cd ~/www/wiki/
git init
git remote add -t REL1_18 -f origin https://gerrit.wikimedia.org/r/p/mediawiki/core.git
git checkout REL1_18
```
In theory, that would get me the latest and greatest of release 1.18, be that 1.18.1 or 1.18.2 and then, when 1.19 was released, I could switch over to that by doing this: git checkout REL1_19

It was time to test it! I pulled REL1_17 and … ran out of memory. Twice. fatal: Out of memory? mmap failed: Cannot allocate memory happened right after resolving deltas. Everyone said ‘You need more swap memory’ but when I looked, it was fine (not even using half). So that was when I said ‘screw it, I’ll go back to tarballs.’

Just as I hit that wall, some Twitter peeps stepped in to explain that, no matter what, I have to clone the whole archive first. I’m not really happy about it. I like SVN, since even when I switch, it’ll only update my changed files. I wanted to be able to do that in git without needing to pull down the whole repo, since I only use it to update, and not develop.

And that there is my one and only issue with git. It’s entirely for developers. Sometimes, some of us just want to pull down the latest version to play with, and not the bleeding edge. With git, I have to clone the repository, then export the version I want to play with. That’s not optimal for what I want to do. On the other hand, I totally get why it’s done that way. It’s akin to the basic svn check out, where I get all the branches and tags, only much much cleaner. And that’s cool! Smaller and leaner is fantastic.

And yet I’m not a developer in this instance. I don’t need, or want, the whole release, just a specific stable release. So now my workflow would be…

Install

On Git:(Of note, every time I try to run checkout I get “fatal: Out of memory, malloc failed (tried to allocate 1426604 bytes)” and I get the same thing when I try to archive. If I use the tool to change memory allocation, it also fails … out of memory. I’m taking this as a sign.)
```
mkdir ~/mediawiki/
cd mediawiki
git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git .
git checkout 1.18.1 -f
cp -R ./mediawiki /home/user/public_html/wiki/
```
On svn:
```
mkdir ~/www/wiki/
svn co http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_18_1/phase3/ ~/www/wiki/
```
Upgrading
On Git:
```
git pull /home/user/mediawiki/
git checkout 1.18.2 -f
cp -R ./mediawiki /home/user/public_html/wiki/
```
On svn:
```
svn sw http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_18_2/phase3/ ~/www/wiki/
```
You see how that’s much easier on svn?

Now, someone wanted to know why I like this. Pretend you’re trying to test the install. You often need to test a specific install version, say version 1.17.1, against some code to see how far back something was broken. Being able to quickly pull that, without coding any extra steps, is crucial to fast testing and deploying. The tool we use at my office required me to reverse engineer and script a way to do that with an ant script, and certainly I could script all that here. It’s not even that hard. But what’s one line in svn is three in git, on it’s best day, and you’re always pulling the latest and reverting back to the one you want, which seems a little silly.

Now, someone pointed out I could use this: git checkout-index -a --prefix=/home/user/public_html/wiki/ When I read the man page, it doesn’t say you can pick a tag/branch to push, though. If you have some advice on how to fix that, I’ll give it a shot, but I suspect my memory issues will block me.

I will be using git for a lot of things, but a fast way to update, spawn versions, and test will not be one. For development, however, I totally adore it.
23 March, 2012
Why You Shouldn’t Use Plugins
These are words I never like hearing: “I want to change WordPress functionality, without a plugin.”

At first, when I started using WordPress, I would say that myself sometimes. WordPress should have everything! Why do I have to use a plugin to use footnotes? Why do I need a plugin for fighting spam!? Why can’t I have everything I want and need all in one!

Flash forward many years and my answer is “Because the world’s largest Swiss Army Knife is unusable.”

85 options and when I look at it, I can’t fathom how I’d use it to do the things I need a Swiss Army Knife for. I do own one (two actually) and they’re both the perfect, simple, classic models. Heck, the one I pulled a picture of here has more gizmos! Mine has two knife blades, two screwdrivers, a toothpick and tweezers. That’s it. No extra bells and whistles, and I don’t need them. That little tool is 100% what I need for the moments I need a Swiss Army Knife, and has gotten me into locked buildings, fixed a car, pulled a thorn from my dog’s paw, and a hundred other little things.

So when I hear people say “I want to do XYZ without a plugin…” I can’t help but think they’re looking at the whole process wrong, and I ask them “Why?” People have some pretty amazing excuses for why they can’t use a plugin, but I stick with my beliefs that no tool is all-in-one, and the more I hard code customizations, the harder it will be for me to upgrade them later.

A plugin isn’t ‘core’ so it’s less reliable.

People have this odd idea that ‘core’ makes something better. It’s actually not true. A good part of the design in WordPress was done so people could hook and action into it, making changes and tweaking things. So if you trust that core is ‘reliable’ then you trust those hooks are as well. And if you’re trusting the hook, you’re trusting the plugin. I think what the real fear is, is this:

A plugin author might vanish.

There are a lot of WordPress devs who vanish. Some even work on core. But yes, a plugin author could take a walk and you’d never see them again. This is ‘dangerous’ if you think of WordPress plugins like you think of, say, software vendors. You shouldn’t. Let’s look at HP’s tablets. No one has any idea what’s going to happen with them, if there will be more software, hardware or any support at all in the future. But HP is a proven, reliable company! And what about the Zune? Every vendor makes mistakes with products, and a freelance plugin dev is no better or worse than a major company at the end of the day. A real company might close it’s doors without warning, too! Maybe what people are saying is this:

There’s no one to sue.

Why this is a sticking point… The non corporate version of this is actually “For my protection!” But much like the point above, having someone to sue isn’t a magic solution. It’s not a promise that your vendor won’t wander off into Chapter 11, and leave you hanging. Go ask around, everyone’s had that problem with a pay-for program, and worse, one that left you with no one to sue. People are too sue-happy in my opinion, but I can’t fight that one. I do ask why they think they’d need to sue, and I get told this:

A plugin is less secure.

I’d like to know when the last time was you did a security audit on WordPress. Look, I’m not saying plugins don’t have the potential to be insecure, but if you’re performing your own due-diligence, and security is your bugaboo, then you should be testing WordPress core, your theme and all plugins with equal scrutiny! We perform audits on all vended software. Every year we have ‘hack it day!’ where we actively try to break into our products (in a non-live environment) to verify it’s as secure as we can make it.

So if you have a plugin you really want, you should be reviewing the source code. And that’s where open-source code takes the prize. I can open up a plugin, and if I see base64(), or get() calls to things I don’t recognize, I know the plugin’s possibly insecure. I may even email plugins@wordpress.org and let them know about the bad behavior (base64() isn’t allowed at all). But none of that gives me a feeling, like so many other people, of this:

A plugin is less reliable.

Than… what? Seriously, I’ve heard this a hundred times. You’re saying “Someone else’s code isn’t as reliable!” but I’ve never had anyone explain how the code total strangers wrote in core is more or less reliable than the code in a plugin. And what about the plugins written by core devs? Are they incapable of problems? Tell that to the bugs that slipped into Jetpack. Nothing is perfect.

Now, there are checks and balances on core that don’t exist on a plugin. Core changes are tested by hundreds of people (you’re testing it right now, visiting this site, which runs on the latest bleeding edge). With all those testers, it’s still possible for major bugs to slip through (like json conflicts, sorry, Nacin). Which is probably why people say things like this:

If I edit my site myself, the code will be there forever.

That one amuses me a lot, actually. A friend of mine blogged about this recently and pointed out that life ‘without a plugin’ is dangerous. If you edit your site yourself, you have two places to do this.
1. You edit core
2. You edit your functions.php
If you edit core, after you’ve killed a kitten, you’ve locked yourself into manually updating WordPress forever and ever. You can’t use the auto-upgrade, you have to read and re-read every code change to make sure it’s not on your file, and you have to pray nothing else was changed to make your hack invalid. How is that different from a plugin? Even a deprecated function used in a plugin will still work.

As for your functions.php … maybe you don’t know this, but the difference between a functions.php change and a plugin is where you put it. Put it in functions.php and now you’re locked into that theme. Which is actually a problem I have with Custom Post-Types right now. If I want to switch themes, there are things I have to remember to bring with me. Hassle. There are plugins, thankfully, that can cover that for me, and I’m glad for them.

Just use the damn plugin!

Well okay, then. Are there reasons when a plugin’s a bad idea? Sure! Brian nailed it in one:

@Ipstenu I think a plugin is a bad idea when it doesn't solve a problem. Many blogs have needless plugins that distract from blog content.

— Brian Crawford (@briancrawford) January 2, 2012

If the plugin is making it snow on your site, I’d consider it unneeded. But I don’t advocate the use of fewer plugins just to use fewer. I do it because I think everything should have a purpose. If there’s no good reason to use a plugin, don’t use it. If it’s redundant, don’t use it.

What else? Oh, Joey says:

@Ipstenu my own reason *sometimes* is "I'd rather code it myself"

— Joey Kudish 🇺🇦🏳‍🌈 (@jkudish) January 2, 2012

And that’s another excellent reason. If you want to learn to code, you don’t use a plugin. Or if you’re like me, you ‘fix’ it.

Excuses, excuses

What are the best ‘worst’ reasons you’ve heard for why a plugin shouldn’t be used? Here’s what my tweeple said (and my slightly sarcastic replies):

@Ipstenu 'too much extra code – what can i put in functions.php instead?'

— quiltingshed.bsky.social (@andrea_r) January 2, 2012

Clearly they’re unclear on the concept. Functions are great for small, quick changes, but they’re tied to your theme! A plugin is forever.

https://twitter.com/#!/TJList/status/153654497380540416

So will adding the code manually.

https://twitter.com/#!/sabreuse/status/153664752810336256

I couldn’t even dignify that with an answer.

http://twitter.com/sabreuse/status/153664914278453248

If everything was ‘in core’ it would be 600megs and no one would use it.

Let’s hear your best ones!
1 January, 2012
WordPress Upgrades and You

A year ago I wrote this – How the WordPress Update Works – and, the update tool has changed, but the crazy expectations have not.

Before We Begin…

I want to reiterate this, since apparently I can’t say it enough, the auto upgrade tool will never be 100% perfect.

Part of me seriously wonders why people expect things to work perfectly all the time. The other part of me knows that if it wasn’t for WordPress getting it right so often, they wouldn’t have such violent reactions when it wasn’t. Skewered on their own swords, I guess. By making WordPress easier to install, use and upgrade, I do feel we might have lowered the bar too much, or at least beyond the current ability of servers and applications.

I feel there’s a practical limit to how ‘simple’ you can make things. It’s sort of why I hate writing ‘troubleshooting’ documents that consist of ‘If you see this error, do this.’ It stops people from thinking and troubleshooting on their own, and instead ties them to a script. You’ve been there, I’m sure, telling the guy on the phone that you already rebooted your system.

On the other hand, the vast number of people who just don’t do that is why I started writing up the Master TroubleShooting Lists for WordPress releases (this is now my third). Before 3.3 came out, I monitored the Alpha/Beta forums, the email lists, and pinged people I knew were testing the pre-release on Twitter and Google. Then I grabbed the other support geeks on the wp-forums list, asked them for advice and suggestions, and drafted up the post you see up there now. Well, except not. That post has been edited by anyone with moderator access on the forums (something I encourage and support, by the way).

What does all that have to do with how the upgrade works? It’s simple. If you don’t want to take the time to understand how a process works, what it entails, how it’s tested before release, and what goes into installing it for you, I don’t want to help you. Actually, no one does. One of the last things anyone in support wants to hear is ‘You don’t understand…’ (First place goes to anyone who says ‘It doesn’t work.’ and won’t tell you what ‘it’ is, what the error is, or anything useful.)

How Does The Upgrade Work?

Many things are still the same. WordPress downloads the files, replaces them, runs the ‘deprecated file list’ and deletes only those files. What’s new is that, as of WordPress 3.2, we only upgrade the newer files!

Faster Upgrades — The update system now support incremental upgrades so after 3.2 you’ll find upgrading faster than ever

This made the 3.2.1 upgrade really fast for everyone. If you look at the release notes for 3.2.1, you’ll see a list of files at the bottom. Those were the only files that got updated when you ran an automatic upgrade, which is really cool. And when you look at the notes for version 3.3, you don’t see those files. Why not? The first reason is there are a lot more files. In fact, I’m willing to bet most files are touched in an update from 3.2 to 3.3 (those are major releases, by the way). So listing the files would be crazy. The second reason is that a major release isn’t viewed the same way as a minor release. We’re supposed to expect big changes.

I started working my way through the code before I gave up and asked Nacin if the 3.2.1 to 3.3 used the incremental or the full upgrade? My gut feeling was, based on how long it took, it was a full upgrade. Nacin was quick to confirm that, elaborating by saying those are only done for partial releases, though the update was smaller than before, since it omitted the wp-content folder. This isn’t new, by the way.

So basically the upgrade hasn’t changed. Which begs the question…

Is WordPress 3.3 ‘Worse’ Than 3.2?

This goes back to my Master List posts. The whole reason I started them was that 2.9 to 3.0 was insane. It was huge. It was crazy big, with lots of changes, and lots of visceral reactions. “I hate this, I hate that, I hate you.” I’m currently ignoring (most of) the people who are doing that. I get that you’re unhappy things aren’t perfect, but I’m going to put this out there: You’re being irrational.

Now, it’s okay that you’re angry. I mean, your site is ‘broken’ and you’re upset. It’s justified. But from our end of helping you, it’s like trying to negotiate with a truculent five year old. You won’t listen to reason, you just want us to fix it, now, and by the way it’s totally our fault that everything broke. I don’t mollycoddle people when they start loosing their blob like that. I walk away and wait for them to comprehend reality.

No, 3.3 isn’t ‘worse’ than 3.2. And it’s not, generally, WordPress’s fault your site broke. It’s not anyone’s fault, actually.

Just like everyone waiting (or delaying) filing their taxes until the last day, plugin and theme developers also sometimes put off the seemingly minor task of checking their plugin or theme with the new version of WordPress. In fact, a shockingly high number wait for the release candidate. I said this before, if you make your living on WordPress, you damn well better test earlier. Sure, it makes sense that people like me (who actually don’t WordPress for a living) don’t always test in time. On the other hand, if you’re a professional, you’re remiss in your responsibility by not doing that.

And even then, you can still miss something. My best WordPress Friends missed a bug in their plugin. They do this for a living. How did that happen? It happened to be a feature you don’t often go and change. They had tested ‘does this still work when I upgrade?’ and that was hunky dory. But this one thing that only gets used when you’re doing one specific thing, that people only use once, that wasn’t working. Oops. You can see how that got missed. They just didn’t test it. It happens, they worked out a fix, and it’ll be out soon. Those are understandable misses because you can’t test everything. Maybe they’ll make a checklist of things they must test on a major upgrade, but then again, this plugin had survived multiple other major upgrades. It’s hard to say.

But what about when it’s your plugin plus someone else’s theme plus the new version of WordPress? Now it’s harder, because you get an IDIC epidemic(That is possibly my favorite Star Trek novel, by the way.) with WordPress. IDIC is a Star Trek concept. The Vulcans believed in “Infinite Diversity in Infinite Combinations” which I think is a perfect way to explain the problem.

It’s because of both the myriad complications thrown in by the incalculable customized installations that, when people say the upgrade broke them, I have to do the thing I despise and ask them “Did you read the Master List and try everything?” I actually do wince every time I paste that link in. It is with a resigned sigh that I hit enter. I don’t want to have to say that, but when I see people posting ‘It doesn’t work’ or ‘Help! My site is broken!’ without any information as to what they’ve already tried, I look at the volume of posts and assume they did nothing.

I tweeted at one point “I’ll stop posting stock replies when you stop posting it didn’t work.”

It’s a give and take. You have to give a little information if you expect people to help. And not one of us thinks this install is 100% rock solid perfect. 3.3.1 is already on the docket with a couple things, including putting support for people with no DB prefix.

Invariably we’ll all find something new and horrible to add to the master list. Like this time, I had to put ‘flush all your caches’ because, when WP changed the jQuery to 1.7.1, some browsers decided they weren’t going to update the local cache like they’re supposed to. The amount that pissed me off is huge. Also, as Nacin groused, the core devs yet again missed a JSON issue. One bitten, twice WTF? as he put it.

For the most part, the real issues people have with 3.3 aren’t technical issues, they’re user issues. People love/hate the flyout menus, the toolbar (oh dear god the tool bar) and the uploader. They hate that not all their plugins work, they hate hate hate. It’s wearing, you know. And we, the happy Half-Elf volunteers out there want to help you fix things. But if you’re not going to accept that problems are usually bigger than just WordPress, we can’t help you.

Like the Database needing repair, okay? Some people had to repair their DB. Guess what? This isn’t just a WordPress issue. I ran a major upgrade on a webapp for work last month, and the damn thing did the same thing! I had to repair the DB to get it to work. This is because, as I know, I’m making some major changes to a database, and if there’s any sneeze on the sturdy tubes of the Intarwebz, then I may have a weird glitch. This is why, again, I tell people to manually upgrade. These problems are cause by the upgrade, but they aren’t WordPress‘s fault. They just happen. A thousand times you add a post, and one time it causes your database to crash. That’s uncommon, but not impossible, and that is what people fail to grasp.

You’re experiencing uncommon problems.

Don’t Lower Your Expectations, Raise Your Understanding

Sometimes I think people get the wrong idea when I talk about this sort of thing. You think I want you to give support people more of a break, and while I do, it’s for the same reason I want you to give your coffee barrista a break(Best coffee I’ve ever had, no lie, was when I told the overworked barrista “Take your time, if the jerk is in a rush, I’ll wait.” It cost me ten minutes, and they gave me the best coffee ever. One size larger.), or the chasier at the DMV. Treat people like people, because that’s the right thing to do.

Instead, you should learn more. Understand more. Take the time to go “I hate this. Why did they do it?” and then, instead of making that angry shit-distributing, post, learn something. With very little effort, a person can scroll down to the Alpha/Beta forums on WordPress and see if this problem was reported before. A slightly more experienced person knows about the blogs the devs use, and one step up from that, you know trac. Trac’s a little scary when you’re new, and search it is complicated, don’t get me wrong.

But see, the ‘geniuses’ who are helping you at all your problems? We’re just people like you. And we just have an idea of the lingo and what we’re really looking for on Google. And we would really like it if you could treat us like people before you lose your mind.

We’d also like it if you read, and thought, before you said ‘this is broken.’ Mind you, I think that of the guys I teach to solve problems. Listen to what people say, pay attention and try to draw better explanations from them, and solve the real problem. The number of times I’ve watched people just throw a rote answer at the wrong problem drives me nuts. But so do ‘web developers’ who don’t understand what FTP is.

If you’re going to run a website, even though apps make it easy on you, there’s no excuse for not learning what you’re doing. I don’t mean you need to learn how to write code, but just as I feel everyone needs to know how to jumpstart their car and change a tire (or patch one, if you ride a bike), it’s in your best interest to have at least a basic understanding of the magic that is the internet. And if the website is your life (as so many people on the forums short), well, then so is learning that. A chef knows how to use the fridge and sharpen knives because it’s expected of them. While a fashion designer may not be the best at sewing, they know how clothes are put together.

See the theme here? Know what you’re doing. Understand what’s behind your art.

Otherwise? Well, WordPress.com has fantastic hosting options and I send many people to them.

19 December, 2011
WordPress Sidebars as Menus: Part 3
Who knew I’d be making a series of posts!? Part the Third is all about ‘per page sidebars.’ Inspiration struck as I was finally able to visualize how I’d want it to look, and it’s stupid simple.

First and foremost, it’s hidden by default in the Screen Options. This is important, since while I totally agree to use decisions, not options, this is something people need options for, but at the same time it is not something everyone will use. The fact that there aren’t more plugins that do it is paramount in that deduction. I know of two, after all, and one requires you to think. A lot. And while thinking isn’t bad, when you’re new, you want things to be straight forward and make sense. As subjective as that can be.

My idea is that by default, you use the default sidebars. Assuming you’ve defined them as I detailed out in my previous post, let’s play pretend…

Assumptions
1. I’m using the TwentyEleven theme with the following widget areas: Main Sidebar, Footer Area One, Footer Area Two, Footer Area Three, Showcase
2. I’m using a Static Front Page
3. I want a special sidebar only on that static front page
4. My theme uses a reasonable number of sidebars (i.e. 10 or less)
5. I’ve already setup my defined sidebar sets as follows:
  - Primary (for use on Main Sidebar)
  - Showcase
  - Footer left (for use on Footer Area One)
  - Footer middle (for use on Footer Area Two)
  - Footer right (for use on Footer Area Three)
  - Front Page Footer Left (for use on Footer Area One on the static front page only)
What’s that!? Front Page Footer Left? How ever will I define that? Where do I define it? If I only want that sidebar set (Chip, that’s for you) to show up on one page, I could either figure out how to select a page on the Widget/Sidebar editor, or I could do it on the Page Editor. For the purpose of this post, we’re doing it on the page.

Why? Well, it’s a split decision, and without any studies to back it up one way or the other, I suspect that people think ‘You know, I wrote this page, and I want a special sidebar here.’ and not ‘I wrote this special sidebar and want it to show up there on that page.’ My use of this/that and here/there were very purposeful. You think about the sidebars you want while you’re on the page they’re intended for. Therefore, you should define the sidebars on that page. The same argument could be made the other way, I’m aware of this. Just go with me for now.

We go to edit the page and first turn on manage sidebars(You can now see what other options I have going on.):

That gives me a brand new post meta box:

See why I said ‘reasonable number of sidebars’? This could get way out of hand, way fast. You may also note that they all default to … (Default). Well go back to my other idea of having a selection of where to use a sidebar and this makes sense. If you define a sidebar area back there, then that’s the assumed Default sidebar. When you want a specific page to have a totally different sidebar, we should store this information on the page, not in the sidebar/widget like we do today with Widget Logic, etc.

I can use the drop down boxes to show all the available sidebar sets:

Boom. I’m set for this page.

However. This doesn’t solve a big problem: What if I want a special sidebar for specific categories or archives? I’m still doodling on that one, but my first thought is what if certain ‘names’ were reserved. So if I made a sidebar named ‘categories’ it would automagically be used for categories, working on the same concept of the template hierarchy. All things being equal, it defaults to what you picked on the Widgets page.

By the way, these are the original doodles:
8 December, 2011
Too Much Oversight

People who follow me on twitter know my frustration with my day job. It’s not that I hate my job, it’s that I hate when the rules get in the way of things. Over the last three years, we’ve grown from a simple ‘do this please’ directive to a behemoth of monitoring and oversight.

Here’s an example. We run standard installs at 3pm once a week. Tickets must have a start time of 3pm and an end time of 5pm. Thank you auditing. If they don’t, they must have secondary approval to give us the okay to go at a ‘non standard time.’

Now, there is a sane reason for this. We do the install at 3pm, but from 1 to 2pm, we do server maintenance, and from 5 to 9 we do the databases. So really, 3 to 5pm on that one day makes sense, right? We don’t want to run over or the database guys get mad, and we don’t go early cause the server guys get mad. We’ve been doing this on the same day, except Thanksgiving or the random ‘on Thursday’ holiday, year in and out for over 30 years. Yes, 30. Some changes go at 10pm to 2am that night, but the 3pm run for this particular type of change is as normal as anything.

One day I get a ticket with the time ‘3:15pm to 5pm.’ You’d think I could just say ‘Sure, not a problem.’ It’s within the 3-5 time slot, and fifteen minutes is nothing. But no. No, I have to say “I’m sorry, but your ticket requires a start time of 3pm. We are not permitted to make exceptions on this.”

It burns at my very soul to have to tell people something this idiotic. I mean, it’s fifteen minutes and it would still run within the allotted time! Heck, the process this guy wanted takes 5 minutes total! But no, our tool locks things down to the point that I can neither start the process early nor can I accept a non-standard time without triggering alerts that, at the end of the month, slap me into the “Oversight Review Board” meeting, where I have to explain why I did it.

The problem is that the oversight machine gets in the way of our ability to be productive. This mechanism grew from the ‘old days’ when we would submit a request to make a change, and if I didn’t know that the server was being worked on from 1pm to 2pm, I’d just run the ticket whenever. The timeslots were general guidelines, not set in stone. Then we grew, and people realized they needed to coordinate a server change with a code push (my job) with a db upgrade and then with some other totally separate install. And since no one could possibly be expected to memorize every single moving part in the company, we have a new ticket system to manage it for us.

Old Way: I put in a ticket to make a change with the time/date I’d like it to happen and my boss approves it. The people making the change pick up the ticket and do the work.

New Way: I put in a ticket to make a change with the time/date I’d like it to happen and my boss approves it. If this change has any red-flags (like it’ll take more than 24 hours, or it affects XYZ), it goes to the Change Review Board, who looks at it and either approves it or asks me to come in and explain what I’m doing. Furthermore, if I go on certain dates, it goes to another level of review. If I want to do it in less than a week prep time, it gets extra review and my boss’s boss has to approve it.

Conceptually, this is meant to have enough eyes looking at a change that someone says “Wait! Bob, we can’t upgrade the DB severs that day! Joanne’s major install is that day!” However, nowhere in here is the system actually checking for us and saying ‘You’re going to be touching the following servers.’ Nowhere does a computer do the mind-numbingly boring work it’s great at and verify that all the interlocking pieces related to my change are also not changing, or if they are, it’s a related change.

We didn’t make the system work any better, we just became better at covering our asses. Now we know how to write a request with the right buzzwords. Like every request I make requires me to include what I’m changing, why I’m changing it, how I’ll test it, what documentation is there, who will be the ‘point’ person, what follow up we’ll do, and what unexpected problems might there be and how to we plan to fix them?

That last one makes me wince. I often write “We don’t expect any problems, but we’ll follow standard troubleshooting guidelines to fix them.” My boss tends to have to rewrite that for me, because my capacity for handling stupid questions is usually filled by the time I’ve completed the 10 questions on the form.

I know that the purpose of all this is to make sure that every change we make is one we needed to make, and that it’s done with the right amount of forethought and understanding. What it’s done was make everyone annoyed, and annoyed people don’t do work efficiently. Also it’s asking technical people to write explanations to non-techs, something a number of them aren’t good at and that’s okay! We can’t be expected to be Renaissance Geeks, good at all things.

Should the technical people be able to say ‘This change will make our ATMs faster’? Of course. And they do. But when they’re asked to detail out every single step, multiple times, in multiple ways, they get annoyed. Instead of asking the question once, they ask the ‘what are you doing?’ question 10 times, in 10 ways, to try and get you to answer what they want to know. And at the end of the day, they still don’t know.

Of course, the real reason for all this is so that when it goes wrong, the Bobs can point and go “Well, Joanne there screwed up.” and Joanne can point back and say “I said I was rebooting the ATMs at 4am, and you approved it.” and round and round it goes. I made a lot of friends once when I stepped into a M&M(M&M stands for “morbidity and mortality” and is a periodic conference in many medical centers usually held to review cases with poor or avoidable outcomes.) and announced “I can’t see why the system didn’t run as intended, so the logical reason for the outage was that I made a human error and clicked the wrong button.” Of course then they wanted me to code out human error and I decided they were idiots.

We went from pretty much no oversight past a rubber stamp, and relying on the little guy doing to work to raise any red flags, to massive amounts of oversight where we still rely heavily on the little guy doing the work to raise that red flag. The system locks us in, brokering no room for typos without having to restart the whole chain of events over again, so if you accidentally type in 3:01pm, and the little guy doesn’t notice, you both end up being asked why you did something ‘wrong’ on the metrics report at the end of the month.

Sometimes in my other posts I say that my perspective on the machinations of things like WordPress and Drupal oversight is different. This is why. I’ve seen the extremes on both ends, and I respect the need for both oversight and attentive management. I think that Open Source tends to handle it better because they can’t afford the big massive teams who have but one job, and that is to know everything. They know they can’t, so they know how to work together. They’re not afraid to email/IM/Skype each other for help, and if everything breaks, they can fix it and laugh about it over beer.

It’s not that they don’t ‘get it’, it’s that they do get it. Corporate America doesn’t.

5 December, 2011

Tag: administration

Jetpack Menu Stats

Once GITten, Twice SVN

Why You Shouldn’t Use Plugins

WordPress Upgrades and You

WordPress Sidebars as Menus: Part 3

Too Much Oversight