Tag: coding

“This Needs Support” vs “This Needs Patching”
Writing code is rarely an act of support.

Most of the time when someone needs support (i.e. help with a problem) what they need is to understand what they’re doing, where they’re coming from, and what they want. Once they have that, they can apply their knowledge and define their goals and achieve them. I know, I know, that sounds all new age of me, but that’s really what’s going on.

Patching is ‘This code is broken, I should fix it.’ However patching is not support! This sounds weird to the unfamiliar, but there is a big difference between fixing the broken and helping people.

The conflict comes up when someone using software has a problem. When a user has a problem, most of the time they feel it’s a bug. Trying to explain the difference between a bug and a missing feature is complicated, but to boil it down I say ‘If it’s a bug, it’s supposed to work an it doesn’t. If it’s a missing feature, it’s documented as working differently.’ (We often say ‘it’s not a bug unless it’s documented, but that’s used to mean that if someone didn’t report the error, it’s not real. Schrodinger’s bug reports, as it were.) When it’s a missing feature you have a ‘feature request’ or an ‘enhancement.’

Thus I’m not surprised at all when someone makes a complaint ‘This enhancement is a bug, fix it now!’ and then ‘Why can’t I get support on this?’

Your’e asking the wrong people. Support doesn’t go out and fix everything. Support sits down with you, sorts out what really happened, how to fix it, how to work around it, and is trained to think. A good support person makes a note every time a weird error pops up, who has it, how they fixed it, and when there’s a pattern, reports it up the chain. “You’re right, sir, that’s a problem.” If they know it’s a problem, they give you a ticket number to follow, or some way for you to know what the over all status is.

So if the support people are being good and reporting things as they should, why don’t the bugs get fixed right away? Well, if they were that easy, they wouldn’t be bugs in the first place. Okay, that’s not true all the time. Sometimes it’s just that it’s a small bug and no one cares enough to fix it. Other times it’s waiting on other fixes, and finally the devs may just have more important things to do.

The thing you don’t do in these situations is say “I don’t know how to code, but this must be simple!”

That Dilbert will send the developers into a frothing fit of ‘You idiot…’

I’ve said it before, and I’ll say it again. It’s okay not to know something. Look, I barely know SQL. I don’t know AJAX at all. But what I do know is how to think and how to ask for help. And I know how not to ask for help too. The point is, I know my abilities and I know how to network and research. And I know when I don’t know something. Do not for the love of anything ask me to help you with Excel and pivot tables.

The point of that is if you start a sentence with “I know nothing about code but…” you better be very, very thoughtful about things. I recently suggested to someone “I don’t know this code, but here’s what I did on this other one… Would it be possible to leverage X to do something similar?” I don’t presume that I’m right, but having some related experience, I shared what we did in the hopes it will help or inspire someone.

And inspiration is the magic that fixes code.

Code is part art. You are creating something that has never been seen before, never conceived of, and never written. If that’s not art, I don’t know what it. And art, like all creative things, requires inspiration. We do not just pluck ideas out of the air, that were left there by the idea fairy. We see something in a puddle that makes us think ‘What if uploading images was as easy as a droplet of water…’ We have to invent, create and imagine. We have to dream. (Sidebar, this is exactly why my office’s draconian laws upset me. They stifle our creativeness and we make worse products.)

When you tell someone that something is ‘wrong’ there’s a reason you may get push-back like ‘Well what would you like it to do?’ or even ‘Why do you want to do that?’ It’s clear you have had that moment of clairvoyance where you can see a perfect future, and we want to see it too! That will help us either follow your vision and make it happen, or tell you that’s not going to happen right now. Your ‘bug report’ helps create better things.

At the same end, we have to remember that just because something isn’t working right, doesn’t mean it’s broken.

‘Right’ is surprisingly suggestive, and has a lot to do with use-cases. No two people use a product the same way. I open Skype when I want to talk to someone, my friends keep it open all day. I keep a word processing app open all day, others don’t. And consider email applications. My coworker has his open on schedule every 2 hours, and never alerts him to new email. I have a metric ton of filters that alert me when important emails are in, or when I haven’t checked in 90 minutes. We all push tools to fit our use.

Why, then, is it surprising that when something doesn’t work the way I want it to, this might be because of me, and not the tool? I’ve been telling people a lot that using WP Optimize (a very cool DB optimization tool) on a large site (or a Multisite Network) is akin to using a hammer to drive in a screw. You know you should use a screwdriver, but the hammer’s right there. Now, the plugin has some features that are annoying to have to roll on your own (removing post revisions and auto-drafts, and some scheduling), but the reality is that when a site is large, you’re using an inefficient tool for the job. PhpMyAdmin is a far better tool, though it’s more complicated and requires more knowledge, so people use this plugin. For a time, that’s fine, but when you grow and change, you have to learn and adapt.

Is it the plugins fault that it can run out of memory while working on a large DB? Of course not. It’s not even a bug, and the plugin isn’t broken. What the plugin is, is limited. And limitations aren’t bad. You have to limit software (otherwise it runs forever, and that, children, is what we call an endless loop), you have to give it an end point. Marking these and saying ‘Yes, today that’s a limitation’ doesn’t mean it’ll never get fixed, but just that today you can’t do everything.

Some takeaways for you.
- Make thoughtful suggestions and recommendations.
- Remember your needs may not be the same as everyone else’s.
- Reflect on if you’re using the right tool for the job.
- Try to understand the problem from as many angles as possible.
- Never, ever, ever say ‘This is easy code to fix!’ unless you’ve written it, and it was.
- Remember that genius is born of innovation and perspiration.
What do you think helps keep that balance between support and new code?
13 February, 2012
Yourls
For a long time I’ve wanted short URLs for one of my sites. Finally I figured out a short URL, picked up the domain, and said “It would be great if I could redirect posts with this! But how?”

As it turned out, I was making a mental mountain out of a miniature molehill. I do that sometimes, get all caught up in a non-meaningful detail. This was easy, it wasn’t super complicated, and it was fast. On the scale of things where WordPress is the easiest (1) and MediaWiki is the hardest (8), this landed next to Zenphoto (4) and was about the same (3 or 4, depending on your skills). It requires more RTFM than WordPress, and I had to do some things manually.

Setting Up Your Domain

First buy the domain. This part is obvious, I hope. Since I’m on cPanel, I added my new domain as an addon domain to the master. This let me have the short domain (do4.us let’s say) hosted off the main domain.com site, without making a separate account. If I’d wanted to map a domain, I would have parked instead of addon-ing.

To add an addon domain in cPanel:
1. Enter the domain for the new addon domain into the New Domain Name field.
2. Enter the main FTP username for the addon domain in the Subdomain/Ftp Username field. You can use the one you use for the mani account if you want.
3. In the Document Root field, enter the directory that will contain the addon domain’s files.
4. Enter the password for the addon domain into the Password field.
  - Make sure you use a secure password.
  - You can have cPanel generate a secure pasword for you using the Generate Password feature.
5. Confirm the password in the Password (Again) field.
6. Click Add Domain
7. To add files to the addon domain’s home directory, click the File Manager link, or use FTP/SSH like normal people.
Once I did that, and DNS propagated, I was ready to go.

Installing the App

I decided to use Yourls for this, since my friends use it, and I know (in that internet way) the guys behind it. Hi, Ozh.

That said, their install doc was screwed up. For 1.5, it says to edit a file that apparently isn’t included in the build. That’s okay, since I just used SVN anyway. The directions are very much geeky. This is not a simple WordPress install.

What I did was first make a database domain_yourls and added my DB user account to it (I never use my domain FTP account). Then I ran an SVN checkout from googlecode to grab the files into the root of my add-on domain: svn checkout http://yourls.googlecode.com/svn/trunk/ .

After that, it’s the manual editing of the config file (the sample of which is not included in the 1.5 zip) and then I went to myurls.com/admin/ to finish setup. I had to grab the .htaccess file sample, since mine didn’t copy down (my own fault there).

Configuring the App

Install the YOURLS: WordPress to Twitter plugin. Even if you don’t plan on using the auto-tweet function, this is the easiest way to get your URLs made. The “hard part” here is setting up a Twitter ‘app’ for the first time. If you’ve done it before, it’s not terribly hard, but with all new things, it’s scary. Ozh’s directions are painless, thankfully, and then … you’re done. And you have your own Short URLS!

What’s Missing?

Two things, and neither are YOURLS fault!

1) Twitter doesn’t know that three different URLs (domain.com/postname, domain.com/?p=2 and do4.us/2 for example) are all the same URL. That means if you use those Twitter Rewteet buttons on posts, it doesn’t show up the same way, and the ‘count’ is off.

2) There isn’t an easy way to tell Jetpack to use my short URLs instead of my site’s full one. Edited to add: By this I mean only in the ShareDaddy links. Like the ‘tweet/email/facebook’ ones. Actual shortlinks work perfectly.

I suppose a third is ‘Damn it, Twitter, stop shortening a short URL!’ but that’s a different rant.

Should you do this?

I think so, but then again, I’m weird.

Read Also…

Otto – Using YOURLS with WordPress

Rev. Voodoo – How I Set up Vudu.me URL Shortener With Yourls
9 January, 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
Community Driven Design

WordPress 3.3 is on the horizon, and already there’s a minor kerfluffle over the flyout menus. Regardless of if you agree with the change or not (I do, Otto does not, for example), it brings to mind the reality that every time there’s a new change to the Admin UI, someone demands to know ‘Who’ requested the change. One time, the answer was ‘Matt.’

While WP is open source, and that means it’s community driven, that’s only to a degree. Remember, at the end of the day the folks with commit access are the ones who decide what they want to support and have in their app. Theirs. WordPress isn’t a Democracy, it’s at best a parlimented monarchy, but really more of a benevolent dictatorship. This is neither good nor bad, when you put it in perspective, and I’m afraid that with products, especially free and/or open-source products, we as a user base consistently lack that perspective.

The company I work for recently switched to Office 2007. Yes, I want you all to take a moment to reflect on the fact that we didn’t move to Office 2007 until it was 2010 (and didn’t finish until summer 2011), it’s important. The reason we didn’t switch sooner wasn’t for anything technical. In fact, we really wanted to switch so we could upgrade SharePoint and have functional integration. No, there were no app conflicts or weird database issues preventing the upgrade. It ran on our operating systems without issues. But why didn’t we upgrade? Because some of the people in “very important positions” had trouble with it, and we were concerned that the UI change, which was rather dramatic, would overwhelm our help desk.

To put this in perspective even more, there are about 20k employees at my company (give or take, I’m not counting consultants here, or non-computer-using people). Of those, about an eighth are what I’d call techies. That is, maybe 2500 of us are really nerdy people who use foam swords or even know who Stallman is. Another 2500 of us are technically inclined, and capable of trouble shooting the basics. Another 2500 are smart enough to know how to explain their problem to the techs. That means over half the company are ‘real users,’ you know, the ones we make fun of for deleting DLLs that are taking up space, or who reboot their monitor. Every time we make a change to software used across the entire company, we have to put that 50% clear in our minds. How will this affect them? What training to we need to provide? We’ve pretty much accepted that no change will be universally accepted, and at a certain point we have to agree that this is ‘good enough’ for people, and deal with the fall out.

Coming back to Open Source, when a project like WordPress or Drupal makes a major change someone’s going to hate it. This is just the way of the world, and even if you love the change, you need to work to make sure your replies to these people aren’t ‘haters gonna hate!’ or ‘you suck!’ Neither of these are productive. Part of the problem here is that people get passionate and sulky, like a nine year old who viscerally dislikes something, but lacks the language to fully explain it. This is not to say people are incapable of explaining themselves, but that part of their problem is the ephemeral ‘feeling.’ The other major part of the problem is that no two people hold a hammer the exact same way. And of course that people who are complaining at the ‘beta’ stage of the product are in too late.

Understanding how these designs get made goes a long way into making people accept changes they don’t agree with. It doesn’t make them like the changes, but understanding how and why they happened can get you to the ‘agree to disagree’ point. John O’Nolan (who currently is living on the road by choice) wrote an amazingly informative post about how he got involved in WordPress UI back in the 3.0 days. He lays out how you can get involved more, if you’re inclined. There’s a great Make WordPress UI P2 blog, and of course WordPress Development blog that you can follow along to see what’s going on and there’s always looking at the tickets in Trac flagged for Needs User Experience/UI Feedback, but I’ve found the first way you should get involved is to start using WordPress trunk: the live latest and greatest, but not ready for prime time players, version.

That seems like a departure from theme, but it’s not. We all start out as basic WordPress users. We use the product, we know how to add/edit/remove posts, we move on to using plugins, and eventually we hit a wall. Either we start to adapt and become power users, who understand how to tweak things in wp-config.php, play with SSH/FTP, and make a quick child theme, or we resign ourselves to using WordPress as it is presented. Neither use-case is better or worse than the other. If you’re a ‘hard core’ WordPress user, though, you will find yourself wishing for small fixes, and you’ll make a plugin for yourself. Then you share it, and then you start to suggest things in the forums, or report bugs in trac. Now we’re cooking with fire, and it’s not long before you start tossing out code or css ideas for trac.

The point of this is that if you start ‘testing’ the new versions of WordPress at the beta or release candidate iteration, you are too late in the game to make a UI comment. The Beta and RC releases aren’t for making drastic changes, but for making the changes that are in there work correctly. Like how the ‘close’ button on the admin bar pointed isn’t working on IE 7 or 8. That’s a bug. But not liking the admin sidebar menu flyout and disagreeing with it entirely isn’t a bug. Did you know the head of the UI team didn’t like the Admin Bar back when it came about?

You don’t have to like everything about a product to use it, and sometimes changes mean you need to rethink how you use it. Also, WordPress has a policy similar to Apple and Amazon: Release, then iterate. That’s why in the last three releases of WordPress, we’ve had one major change and two noticeable tweaks to the whole admin UI. The 3.0 release was a huge overhaul, and in both 3.1 and 3.2 (and now 3.3) we’ve had significant variations on a theme. They feel big, but compare it to the 2.9 to 3.0 jump and it’s really pretty small.

If you want to guide WordPress’s UI, get in on it earlier than beta. If you want to iron out bugs, join at Beta, but take the time to learn the difference between ‘I don’t like…’ and ‘this is broken….’ If you want to get new features early, join at RC. If you want to wait till we’re ready to go, wait for the final release. If you just use WordPress and trust that most everything will work, use the final releases. If you’re annoyed that little bugs get missed, use RC. If you know you’re using a fringe case, or setup that uses normal WordPress but on an obscure server or configuration, RC or Beta is where we need you. Remember, not everything can be tested, but you can help test more. However. If WordPress is your life, if you live and die by WordPress and support people who use it or need to be testing it in your corporate environment, then you need to step up and start using SVN. Make a second install and set up a job to update every few hours, pay attention to release dates, and don’t treat this like ‘traditional’ software and wait for a release to be notified as to what’s going on.

But that is another post all together.

Perhaps the best thing about a cooperative design, like in an open source app, is that if you don’t like the changes, most of the time you can find someone else who doesn’t, and who wrote a plugin/extension to change it. When you compare that to, say, Microsoft Word, and remember that you, as a user, have very little say in things unless you luck into their market studies or beta tests, and even then, the locked down systems don’t always permit changes, well, you’ve actually got a lot of freedom. And if you’re not a techie, well, make friends with one or hire one. I hear a lot of them like beer.

26 October, 2011
New Plugin – WP Grins SSL

WP Grins SSL is in development. So there’s that.

21 September, 2011
Manually Customizing the WordPress Admin Bar
FYI – In WordPress 3.3 the Admin Bar was renamed the Toolbar, replacing the header entirely, and now has more hooks to edit it. Please read http://wpdevel.wordpress.com/2011/12/07/admin-bar-api-changes-in-3-3/ for more information.

Since WordPress 3.1, the Admin Bar has been around and been somewhat controversial. Some people love it, some hate it, and some couldn’t care. A lot of the time in the WP Support Forums I had to remind people that you can turn this off for yourself in your profile.

My standard replies to people was pretty much this:
If it’s throwing your theme out of whack, make sure you have a call to wp_footer() in your theme’s footer. The next cause for that is your theme’s css having a conflict. If it’s your avatar size, again, that’s CSS. Wanna turn the admin menu ON for EVERYONE? Use the Always Show Admin Bar Function. Like the bar but not the search? Hide Admin Bar Search Plugin is there. Want to minimise it? Admin Bar Minimiser Plugin. Want to disable it selectively? Admin Bar Disabler Plugin can do that.

Finally if you MUST turn it off… you can add one of these to your functions.php
```
add_filter( 'show_admin_bar', '__return_false' );
show_admin_bar(false);
show_admin_bar(0);
```
OR use the Disable Admin Bar plugin.

FYI, if you put the plugin in a folder called mu-plugins (yes, you can do this on Single Site as well as MultiSite) then your users won’t be able to un-install it unless they go in via FTP. Just put the mu-plugins folder in the same level as themes and plugins (wp-content/mu-plugins) and copy the FILE (not the folder) for the plugin into there. Done.
Now me? I like having it on. I used to have it turned one for all users, all visitors, everyone all the time. Recently, when I re-designed some sites, I removed that functionality because it was showing too much info to people who were suffering from information overload. Once I pulled the admin bar off for non-logged in users, I realized I wanted to change the way it worked.

The normal admin bar is actually pretty straight forward. The pretty icon of your user ID with a drop down menu rocks. The problem I had was my site was built to keep people off the backend. I already use the rocking WP Hide Dashboard plugin, and BuddyPress is installed, so I wanted to redirect people from places like ‘My Profile’ on the unbranded WP backend to the pretty BuddyPress front end. And yes, I think all ‘user interface’ plugins should have a front-end version.

I could have used something like WP Custom Admin Bar, but I knew I was going to want some pretty weird, granular level, control over the layout and the submenus. In order to make this look how I wanted, I had to remove menus I didn’t want (or need) and add in new ones. I did it all in a file called adminbar.php, which I tossed in the mu-plugins folder (so on a multisite it can never be turned off):
```
function ipstenu_admin_bar_remove() {
        global $wp_admin_bar;

        /* Remove their stuff */
        $wp_admin_bar->remove_menu('my-blogs');
        $wp_admin_bar->remove_menu('my-account-with-avatar');
        $wp_admin_bar->remove_menu('appearance');
}

add_action('wp_before_admin_bar_render', 'ipstenu_admin_bar_remove', 0);
```
The values like my-blogs and so on are the IDs of the menus you want to yank:
- my-account-with-avatar / my-account: Links to your account. The ID depends upon if you have avatars enabled or not.
- my-blogs: My Sites menu. For networks (aka MultiSite) only
- edit: Post/Page edit link
- new-content: Add New Content menu
- comments: Comments link
- appearance: Appearance menu
- updates: Updates link
- get-shortlink: Shortlink to a page
While some of these menus only show up for the admins, I figured I may as well remove the ones I don’t need right there anyway. I’m also of the (unproven) opinion that the fewer calls I make in that admin menu, the faster my site will be. The only reason I yanked my-account-with-avatar was because I wanted to remove some of the submenus and add in my own. I found it was easier to recreate it on my own, so I did this:
```
function ipstenu_admin_bar_add() {
        global $wp_admin_bar, $user_identity;
        $user_id = get_current_user_id();

        /* Add my stuff */
        if ( 0 != $user_id ) {
                $avatar = get_avatar( get_current_user_id(), 16 );
                $id = ( ! empty( $avatar ) ) ? 'ipstenu-account-with-avatar' : 'ipstenu-account';
                $wp_admin_bar->add_menu( array( 'id' => $id, 'title' => $avatar . $user_identity,  'href' => 'https://ipstenu.org/members/'. $user_identity .'/profile/' ) );
                $wp_admin_bar->add_menu( array( 'parent' => $id, 'title' => __( 'Edit My Profile' ), 'href' => 'https://ipstenu.org/members/'. $user_identity .'/profile/edit/' ) );
                if ( current_user_can('manage_options') ) {
                        $wp_admin_bar->add_menu( array( 'parent' => $id, 'title' => __( 'Dashboard' ), 'href' => 'https://ipstenu.org/wp-admin/' ) );
                        $wp_admin_bar->add_menu( array( 'parent' => $id, 'title' => __( 'Network Admin' ), 'href' => 'https://ipstenu.org/wp-admin/network' ) );
                }
                $wp_admin_bar->add_menu( array( 'parent' => $id, 'title' => __( '<strong>Log Out</strong>' ), 'href' => wp_logout_url() ) );
        }
}

add_action( 'admin_bar_menu', 'ipstenu_admin_bar_add', 10 );
```
But wait! If you just tried that, you found out the CSS looks like a monkey puked on your site. The avatar icon’s goobered, that pretty sprite that shows the arrow is missing. Well, that’s easily fixed with some CSS.

In the same adminbar.php file, I put this:

function link_to_stylesheet() {
if ( is_user_logged_in() ) {
?>

wp_head you still get the fugly on the admin side. That’s easilly fixed with a second action call: add_action('admin_head', 'link_to_stylesheet');

Now you can make your admin bar have the menus (or submenus) you want to your heart’s content too!

While you can take my work for your starting point, here are the links I found helpful when I was kicking all this around:

• SumTips: Customize WordPress Admin Bar by Adding/Removing Links
• WP Engineer: Add Menus to the Admin Bar of WordPress
• Digging Into WordPress: Admin Bar Tricks
23 June, 2011

Tag: coding

“This Needs Support” vs “This Needs Patching”

Yourls

Why You Shouldn’t Use Plugins

Community Driven Design

New Plugin – WP Grins SSL

Manually Customizing the WordPress Admin Bar