Author: Ipstenu (Mika Epstein)

Retina Favicons

Way back in 2009 I said that every site should have a favicon. It was not the first time I’d expressed such an opinion, and I still remember back when IE 5 rolled out and I saw them on my bookmarks for the first time. Actually, I remember when a coworker asked me to help her make them show again, and I had no idea what she was talking about. As soon as I saw them, I knew this tiny feature would be useful.

Back in those days, of course, we didn’t have ‘tabbed’ browsers. So you knew what site you were on because that was your window. Now, with somewhere between 10 and 20 active tabs on a browser (depending on if you’re me or someone like Andrea or Nacin – I like the fewer) the favicon is a fantastic way to go “Aha! That’s where the tab for Google went…”

Speaking of Google, the other day I was browsing on my iPad and realized that not only does Google show you different favicons depending on which page you’re on, but they also show you them in retina format.

Hold the phone.

Retina. Ready. Favicons.

Well. Clearly I needed to upgrade mine! Of course there are problems with this. The old favicon standard was a 16×16 pixel square that you had to make memorable and identifiable. This is not simple. I picked a hat for ipstenu.org and on a retina display, this still looks okay, even though it’s pixelated. It gives off an 8-bit vibe to things, and that’s pretty me, in that retro-cool way, so I don’t mind. It’s not fuzzy, after all. The same cannot be said of my Spock-eye here, however. I didn’t want to lose the geekiness of the eyebrow, so I sat and pondered my options.

Since my original favicon (see right) was 16×16 and an ICO, I had no choice but to deal with being fuzzy, upgrade or make a whole new favicon. I wanted to keep Spock, so I grabbed a screen-shot of Spock from what is everyone’s favorite Spock episode, “Amok Time.”

I spent a lot of time cropping and tweaking, and finally I remembered that one of the things I am terrible at is images. Sorry, Spock. I still love you. But I resigned myself to my lack of ability in this, and figured that since I had recently redesigned Half-Elf, I may as well get a new icon. Something that wasn’t just geeky, but also more modern. Normally when I do this, I end up over at IconFactory, who were my go-to standards for desktop icons on my Mac. They used to have a pretty amazing Freeware section, but it hasn’t been updated since 2012, and that tells me they’re done with it.

The real problem with icons is, of course, simplicity. The more complex you make one, the harder is it for anyone to know what it is. And it’s just plain hard to do this when you want higher resolutions. Conundrums. After messing around for more time, I remembered I had some old Nintendo retro icons saved from the last time I was doing this, and boiled it down to three:

Fire Flower

Mario

Mushroom

I’m not a huge Mario fan, so I kicked him out, and tried the Mushroom. Cute. Iconic. Identifiable to some. And it had a reminder to me of a childhood book. It was also ‘bright’ and stood out on my toolbar. So I did that.

Now you can’t always get away with this. Sometimes you have to bite the bullet and make a new favicon, or convert the perfect PNG to a favicon. Remember, IE doesn’t accept PNGs for favicons. For that I actually use X-Icon Editor, which lets me tweak each size on it’s own. That means you have make a super complicated 64×64, for retinas, and a simple 16×16 for everyone else. But remember: KISS.

Keep all this simple.

Oh. And the mushroom is an extra joke. See, if you hit it in Super Mario Bros., it took you from Small Mario to Normal Mario. Now it takes me from small favicon to large favicon. And yes, it was on purpose.

6 September, 2013
MP6uccess – Tips and Tricks
Notice: Since WordPress 3.8 came out, you DO NOT need to install MP6 for anything to work. Promise. If you want the extra color schemes, use Admin Color Schemes, but everything else works in core WP.

I like MP6. It’s far, far, far easier for me to read the back end of WordPress with it. It has legible fonts, larger fonts, and best of all, it’s mobile friendly.

The biggest complaint has been that it’s too dark. And I get that, I really do. I personally have trouble seeing white on black (computers only), and white on green (yes, road signs). So for me, the black sidebar was a little heavy, but something I could live with. Then version 2.0 came out and behold, color schemes!

I immediately ran this update, zipped to my profile page (where I knew it had to be), and saw this:

The other options right now are Blue (looks like the old blue), Seaweed, Pixel, and Ectoplasm. Seaweed is my favorite, but I decided to make each site a little different and distinct, so I have Ectoplasm running right now on one site and Seaweed on the other. I can tell right away which is which. My only wish is the toolbar was colorized on both ends.

Tips & Tricks

Okay, okay, I’ll stop selling the plugin, and instead tell you what’s cool to do with it.

Styling Menu Items

The items on your menu sidebar default to some pretty boring icons. Bleah. For years we’ve always uploaded our own images to change things in our plugin and custom post types. Here’s an example for my own code for an old Custom Post Type, because I wanted a custom video icon to show up on my sidebar:
```
function cptname_post_type_css() {
   echo "<style type='text/css' media='screen'>
           #menu-posts-CPTNAME .wp-menu-image {
                background: url(/path/to/CPTNAME.png) no-repeat 6px -17px !important;
        }
           #menu-posts-CPTNAME:hover .wp-menu-image, #menu-posts-CPTNAME.wp-has-current-submenu .wp-menu-image {
                 background-position: 6px 7px!important;
        }
    </style>"
}
add_action( 'admin_head', 'cptname_post_type_css' );
```
Now that I’m using MP6, I have access to Dashicons, which already has a video icon included, so I can use this:
```
function cptname_post_type_css() {
   echo "<style type='text/css' media='screen'>
           .mp6 #adminmenu #menu-posts-CPTNAME .wp-menu-image:before {
                content: '\\f126';
            }
         </style>";
}
add_action('admin_head', 'cptname_post_type_css');
```
No need for a hover image, because this is a font and not an image, so the hover is automagically taken care of. The result is exactly what I wanted. It looked just like it was built into WordPress from day one, and my co-authors know right where they’re supposed to go to make a new video post.

There are a lot of options to nab from, and there’s a double edged sword to having some ‘standards’ built in. While it’s super easy for me to make a plugin or CPT use what I want, the same goes for other people. I imagine a lot of shopping cart plugins will want to use '\f174' (the shopping cart) if they don’t have their own. Also it means that to ‘match’ you’ll have to use Font Icons yourself, and they’re not super easy to make. Not that everyone worries about matching.

Force a Choice

Okay, what if you want to force a choice for everyone?
```
add_filter('get_user_option_admin_color', 'change_admin_color');
function change_admin_color($result) {
    return 'ectoplasm';
}
```
This is the same as it’s always been, actually. But now everyone gets to use purple and green, yay! Keep in mind, this is a hard force. Everyone uses this. There’s no changing. I have this on one site, since the ecotplasm color actually matched the theme. I set it, went away for the weekend, and found the users laughing and loving the perfect match.

Also check out…

I’m sure I’m not the first person do dig out these tricks for MP6. At WordCamp Chicago I remarked that a cool plugin would be “MP6SS” – it would let you pick four colors (similar to the blocks the current MP6 plugin offers), and you could make your own colors on the fly. A little dangerous, but the next option up from that would be a fork of the CSS plugin in Jetpack, which lets you totally customize your MP6 CSS 100%.

Here’s some links I’ve found to more MP6 fun:
Do you have any tricks? Post links to your code!
3 September, 2013
Breaking Up Multisite
This is by no means the be-all and end-all of how to break up a Multisite. These are, however, methods I’ve used to move Multisites around into brand new places. As always, if you have another method, feel free to explain in the comments, and link back to your own tutorials!

You see, Multisite is great at some things, but breaking up is crazy hard to do. If you want to just disable multisite, it’s not too bad, four steps, and the hardest is to delete the right tables. And if you want to move a whole multisite, it’s not terrible either.

But. What happens when you want to move only one site on the network?

Usually I see this happen when someone is developing a site for someone else, and thinks it’ll be ‘easier’ to do it on their Multisite. After all, the site will be ‘visible’ but clearly a development site, and remote clients can take a look all they want. The minority of people I see doing this for just themselves, knowing the site won’t ever need to be on a Multisite, but taking the ‘easy’ way out. And to them I suggest developing locally, as domain.dev, and then a blanket search/replace on ‘domain.dev’ for ‘domain.com’ when you’re ready to move. Then there is a small group of people who have a multisite installed on localhost for development, which … no. Don’t. It’s localhost. Spin up a new instance of WordPress.

And still, while I lament the shortsighted nature of these things, there are clear-cut use-cases for this that people just can’t predict. Like the day you wake up and realize that Ennis and Jack can stay on brokebackblog.com, but maybe you should move the Hulk.(Ang Lee directed both movies.) Now you have a dilemma. Do you rebrand brokebackblog.com as angleefilms.com? Maybe you just domain map brokebackblog.com/hulk to hulksmashblog.com or maybe, maybe, you don’t want to run the Hulk blogs at all, but your friend Eric does. Certainly there are always options to splitting up a Multisite, yet for the sake of this post, you have decided that Eric (who has bought hulksmashblog.com) should have the whole site, all the posts and users, and you don’t want it on your server at all!

Now what?

Uber Easy: Export and Import

This is straightforward. Install your new stand-alone WordPress instance, export the posts from brokebackblog.com/hulk, import them into hulksmashblog.com, customize the theme and plugins, done. If you don’t have a lot of users, this is the best bet. Yes, you’ll lose a lot of time resetting all the plugins and theme configs, but you probably had to do some of this anyway. All your comments come with, all your images too, so it’s going to be straightforward.

A couple more things to keep in mind. User passwords will need to be reset, which is trivial in my experience, and a good idea anyway if you want to enforce good passwords. Many new themes are getting great at allowing you to export theme settings, so that may ease the pain as well. The plugin settings really are the biggest hassle to me, but in the long run, I’ve found that having to reset them isn’t horrible since the new home usually is a little different from the old one.

Finally, you’ll probably need to search/replace your posts to compensate for the new image location. I prefer Velvet Blues Update URLs, but sometimes I use .htaccess to redirect instead. If you’re moving from an older Multisite, your images will all point to /files/, but newer ones are in /wp-content/uploads/sites/#/ instead. Of course, wp-cli make it even easier, and I use it all the time when moving people at work.
```
$ wp search-replace brokebackblog.com/hulk hulksmashblog.com
```
That’s right now my favorite command. It updated everything, with serialization handled safely, and I was done. If I can’t use that, I’ll grab the interconnectit search/replace tool (not just for WordPress) and run that instead, but for me, I install WP-CLI pretty much everywhere now. It’s just so easy!

Ugly Complex: Database Dancing

When you’ve got a more complex situation, like a heavily customized and themed site, with lots of users and content, then you may have to do this the hard way. As before, make your new stand-alone instance of WordPress. Copy down all the plugins and the theme from your multisite, same as before. Instead of importing the content via an XML file, though, we’re going to import the following database tables as well as all the media images. Remember, no import, no media import, so you must SFTP them all over.

Then the DB Tables you need are as follows:
```
wp_x_*
wp_user
wp_usermeta
```
This means you need to know your site number (not too hard, you know how to make them show up, right?), but don’t think it stops here! Now you have to rename tables. There are two directions to go. One is to rename all the wp_x_ tables to wp_, and the other is to rename the other two tables to wp_x_user and wp_x_usermeta instead.

Either way you get to fuss even more. And don’t forget what I talked about in Recovering Your Cape: If your tables are named wp_x_ then you MUST have a field called wp_x_user_roles in wp_x_options, or no one will have any permissions at all. This almost makes it easier to think “Well I should just add in _x right?” You’d think, but then you’re stuck with this funny prefix you have to account for in your wp-config.php file, and you also have to consider what if hulksmashblog.com later wants to make itself a multisite. Be nice to the next guy. I would rename the tables, and then run a search/replace for wp_x_ and wp_ using wp-cli or that script.

Now you’re still not done though. You actually moved over all of your users. That means you have a bunch that don’t have any posts. Go to the /users.php screen and sort by number of posts. Nuke everyone who doesn’t have any posts. Of course… what if they had comments and you want to keep that? Sadly that’s not listed. The comments table isn’t tied in to the users table in a easy to calculate way. But remember, deleting a user won’t delete the comment.

Finally, remember you changed the domain name? Do that again, like you did with an import export.

To The Pain: Moving Your Main Site

Ow. Ow. Okay, Jake, here’s where we get messy. There are just too many options to consider, so let’s look at them briefly.

First, if you want to keep the main site at its current location (domain etc), then you want to actually move all the other sites and then disable multisite.

However, if you want to keep the domain as a multisite and give the main site it’s own, new, home, you’ll want to switch out the main site for a subsite (detailed in WordPress Multisite 110 – around page 80), and then move it per one of the other ways… except remember the site number stays as ‘1’ which is to say ‘none’ so you’ll be moving wp_* and only the ones for the site, not the network (which you can’t delete unless you feel like breaking everything).

Finally, and this one boggles my mind, you want to keep the multisite, and all the sites, but separately. You can see there’s no quick fix for this. Move ’em all manually, and have a beer when you’re done, cause it ain’t fast.

Worse….

There’s more? Just a little bit. Keep in mind that any network settings won’t copy over, so W3TC and WordPress SEO, just to name two popular plugins, have network wide settings. Those don’t magically come with, you’ll have to re-build all of that. With W3TC, you should be able to export the settings, but maybe not. Other plugins too may prove problematic. What about BuddyPress? That would pretty much have to be a table-copy over. At least bbPress should be easier, as it’s all CPTs.

Obviously the more layers you get into with this, the messier it gets. Me? I try to do the age old export/import whenever possible.
27 August, 2013
WordPress Media Library: Show ID
While this is considerably less of an issue with the new Media Uploader, and how it inserts your gallery code, this used to be a hassle. The old [gallery] code would just be that, a short tag, and if included all images attached to a post. So if you wanted it to exclude some images, you had to figure out their IDs, or remove them from the post.

I used to have to show people how to do this all the time. Hover over the image, note the URL, bleh bleah bleaaaaaaaaah.

So what if the images showed the IDs? Hey! You can do that with this function!
```
function column_id($columns) {
    $columns['colID'] = __('ID');
    return $columns;
}
add_filter( 'manage_media_columns', 'column_id' );
function column_id_row($columnName, $columnID){
    if($columnName == 'colID'){
       echo $columnID;
    }
}
add_filter( 'manage_media_custom_column', 'column_id_row', 10, 2 );
```
And there you go. I don’t actually use this anymore, but it was sitting in my scrapbook of functions.

If you’re wondering about the right way to handle galleries today, the gallery editor lets you configure what images are and aren’t in it through a GUI, so you don’t need to mess with this. Just click on the gallery to edit it, remove the images you don’t want, add the new ones, and off you go. About the only thing it doesn’t do is let me select how I want the images to like (URL, file, or none), and I still don’t have the option to link to an external URL. Ah well.
26 August, 2013
Whois On First
Sometimes when I’m helping people out with their website, I feel like I’ve walked into an old Vaudeville act and we’re trying to figure out the answer to a question they don’t understand. The Internet gets newcomers every day and my conversations feel like this:

Ipstenu: Strange as it may seem, they give computer terms nowadays very peculiar names.

Costello: Funny names?

Ipstenu: Code names, geek names. Now, to figure out everything about your site, we start with whois on first, What’s Your Host is second, I Don’t Know your app is third —

For those of you who have never listened to Abbot and Costello do “Who’s On First” you need to take a moment to watch their televised episode “From The Actor’s Home” in 1953, the complete Who’s On First.(I grew up listening to them on the radio in reruns on KNX in the 1980s, and its safe to say that my concept of humor comes more from them than modern TV.)

So when I run into these people who are brand spanking new to the web (yes, they exist), I’m a little annoyed when I find they are totally at a loss at what they actually need to know in order to keep their website up and running. In part this is because the people who build the sites aren’t ‘consultants’ but friends and they just do the needful and move on. Those friends mean well, I’m one of them, but when you make a site for someone else, you have a responsibility to them that they know what the heck they’ve got. Otherwise, you’re not as good a friend as you thought.

But if you’re that newbie, what do you need to know to run your website? Three basic things! Whois! What is! Know is!
- Your Domain Name: Whois On First
- Your Web Host(s): What’s Your Host
- What’s Running Your Website: I Don’t Know Your App
That’s it. Three simple things. But in reality, they’re not that simple. And worse, the person who bought them is, technically speaking, the person who owns them. So if someone else bought your domain name for you, they own it. Not you. They have full, legal, rights to do whatever they want with it. Same goes for your hosting. It’s very important you put close attention to who is paying for your site, because if it’s not you, it should be. Don’t let your friends or consultants or developers buy these things for you, because then, legally, it’s theirs, and no amount of begging to a webhost or registrar will get them to give it to you.

But let’s get into the details.

Your Domain Name: Whois On First

You know this, right? I’m looking at halfelf.org right now. But do you know where it’s registered?

The domain name registrar is the company you paid to ‘reserve’ the domain name. It’s like your phone number. You paid AT&T to buy the number, and you can keep it as long as you want. But unlike the phone company where you pay for the number and the phone service, you may not be paying for both domain name and hosting in one go. In fact, many of us like to separate our host and our domain name, so if the host goes down, we can point the domain somewhere else.

The ownership of the domain name is important, because if you don’t own it, whomever does can point it wherever they want. This happens, from time to time, when domains expire. Someone will snipe the domain (i.e. buy it when you’ve forgotten to renew) and take it. And there is very little (if anything) you can do about it.

How do you find who your registrar is? It’s not that easy. If you use a tool called WHOIS to pull up the information, you’ll find a lot about a domain. For example, here’s what you can find for halfelf.org:
```
Domain ID:D165216955-LROR
Domain Name:HALFELF.ORG
Created On:06-Apr-2012 13:52:55 UTC
Last Updated On:06-Jun-2012 03:50:37 UTC
Expiration Date:06-Apr-2014 13:52:55 UTC
Sponsoring Registrar:eNom, Inc. (R39-LROR)
Status:CLIENT TRANSFER PROHIBITED
```
I removed some of the lines, because my information is WhoisGuard Protected. Normally it shows phone numbers, addresses, and so on. By law, you have to keep that stuff up to date and correct. Most of us forget. But none of that actually tells me what I need to know. See, I know who my registrar is, but all I see is “Sponsoring Registrar:eNom, Inc.” and that actually isn’t it.

Except it is.

My domain registrar is NameCheap, and NameCheap is both an eNom reseller and an ICANN-accredited registrar. I know, that was Greek, but what it means is there’s a list of people who are allowed to sell domain names, and this is the ICANN-accredited registrar and on there you will find both NameCheap and DreamHost, as well as Automattic (aka WordPress.com) and so on. So if they’re listed, why does my WHOIS show as eNom? Because they’re using eNom. Now as a separate example is my domain elftest.net, which shows up as NEW DREAM NETWORK, LLC. And that is, in this case, where I registered it.

If you get eNom as your registrar, don’t worry, you can easily find out who your actual registrar is via their reseller lookup tool. Toss halfelf in there, and you’ll see it’s NameCheap. Whew!

Your Web Host: What’s Your Host

This is the company you pay monthly (most of the time) to host your site. They generally have your email, too, though some people use Google’s Gmail ($5/year, yes, it used to be free). The Web Host is where your website ‘lives.’ All the files, all the pictures, all the email. It’s really easy to see who your host is, thanks to tools like WhoIsHostingThis.com, which can tell you that HalfElf is hosted on LiquidWeb.

If you can’t tell, this is pretty simple to suss out, but also very important to know. And just because you know who your host is does not mean you know the user account or passwords associated with it. If you are the person who pays the bills, you will always be able to get the account back by using your credit card info, but really this is something you should be keeping track of, because if you’re not paying for it, you’ll never ‘get it back.’ It wasn’t actually yours to begin with.

Speaking as a web host, the question I hate to hear the most is “I don’t have my login information for you guys, can you give it to me?” For what I think are pretty obvious reasons, unless you can prove you’re you, no we cannot hand you access. You need to know the login ID, the email address, the physical address/name of the owner, or some credit card into, in order to prove you’re you. You are not Gracie Allen, after all.

What’s Running Your Website: I Don’t Know Your App

This is the ‘what runs my site?’ one, and I am often amused by people who don’t know they’re using WordPress. Why amused? Because it’s at the bottom of every page, it’s on my login page, and … well it’s there. I don’t advocate removing all traces of WordPress from the site, because when you’re trying to figure out ‘what’ runs your site, these are helpful clues.

Even if you don’t use it, you should know what it is. Check if your site has a ‘readme.html’ page like https://halfelf.org/readme.html. Drupal has a README.txt (see http://www.typepad.com/README.txt for example), and MediaWiki just uses README (see http://jorjafox.net/wiki/README for one). So you may need to try multiple variations until you find one.

Of course, complicating that is the possibility of custom code. If your site is just plain HTML, hey, awesome. It’s easy and flexible and you’ll be fine. But the custom stuff, where someone comes up with cool ways to do things and doesn’t document them… this is why I like Web Apps, personally. Someone’s documented, or if not, there are other people who know how to help me.

What else?

What do you consider a ‘must know’ when you’re hosting a site? One thing that’s always interesting to ponder is “Where does my email live?” When I host other people’s sites, I tend to put their email on Google or another email only service, since that makes ‘moving’ way easier. Never assume people will want to have their files with you forever.
19 August, 2013
Code By Any Other Name

While this post is mostly geared to how to better name WordPress themes and plugins, the concepts should be easy to extrapolate for just about any bit of code. One of the hardest things to do, as a developer, is to come up with a name for your plugin or theme. Sometimes it’s really easy, like if you want to make a plugin that shows the phases of the moon as a widget, you’d probably call it ‘Phases of the Moon Widget.’ But is that the best name to give your plugin?

One of the least obvious aspects of plugins is that the name you submit when you fill in the form on the WordPress Add a Plugin Page is the name you get for your plugin. So if you submitted ‘Phases of the Moon Widget’ then you get the url http://wordpress.org/plugins/phases-of-the-moon-widget, and that will also be the name of the folder on someone’s blog: /wp-content/plugins/phases-of-the-moon-widget/. That may not be what you wanted.

When you’re coming up with the name of your plugin, few people give thought to the ‘slug’ you get with your plugin. They try to think of a name that is evocative and descriptive, but often not short and succinct. One might think, in this Twitter/SMS world, we’d be better coming up with short plugin names, but we often get plugins like ‘recently-used-categories-with-alphabetical-or-most-used-ordering’ and then the author gets annoyed with his URL.

In fairness to everyone, this isn’t well understood. And even I have plugin names I regret in the long run. The process is a little mystical and magical to how someone should be submitting a plugin with name and description. After all, you have more than one name and description to consider. You have the name, the slug, the description and the readme. Ouch! How do you do it?

For this example, I’m going to pretend I wrote a plugin that pulls in data from mlb.com and sends an email to people on my blog every time the Cleveland Indians win a game. I plan for this plugin to be used for a BuddyPress community (The Base-Belles), but after I wrote it, I realized I could make this work for any MLB team, and for wins and losses. Thus I now have a plugin that, on my site, is probably called “Indians Game Winner Emails” and has a slug like “indians-winner-emails” or something weird like that. When I write code just for myself, I rarely concern myself with anything fussy with names.

I’ve also made a theme for this site that I want to share, and I’ve called it “Base-Belles” (after the site), but if I release this to the world, I’d want to make it something everyone can use for any team’s fan group, so I will genericize that up.

When you submit a plugin, you’re asked for a name, a description and a zip. So let’s get started. When you submit a theme, you’re uploading the zip directly, and it’s in there you pick your name and slug. So for themes, this is less of a hassle, but the basic principle remains.

The Name

Even themes have two ‘names.’ You have your slug-name and your name-name. As I go to submit my plugin name, I might be tempted to type in “MLB Game Results Emailer by the Base-Belles” and in some ways, that is a great name for a plugin. It’s descriptive after all. But the first thing you need to do is drop any mention of ‘by…’ with your submissions. That’s just not needed, as a theme has a style.css to show who wrote it, and a plugin has the readme. We’ll know.

That means your name is now “MLB Game Results Emailer” which looks great. Or does it. Do I really want the slug mlb-game-results-emailer? What about mlb-results-alerts instead? That’s not much shorter, but as a slug goes, it’s descriptive. Even mlb-results-mail would be better. They’re to the point, and when I read the list of plugins via SSH or SFTP, I’ll know right away which plugin it goes with. This means I will submit my plugin with the name “MLB Results Mail” and I’m happy.

If this was a theme, I’d call it “Base-Belles” after the site, and use the slug base-belles. Boy that would be easy. Except … I generalized it, didn’t I? Now I have “MLB Fansite Theme for BuddyPress” which is a good name, but a bad slug. So for a slug, I’d use mlb-fansite instead. My child theme for my own site will become base-belles and now I’m happy here too! If I was really clever and totally made the theme generic, it would become “Sports Team Fansite” and sports-fansite.

Descriptions

When we ask for a description what we really want is your short description. “This plugin sends an email to your subscribers every time your chosen baseball team wins a game.” Or a theme “This BuddyPress optimized theme is perfect for running fan-sites for baseball teams.” This is all anyone wants to see for a short description. It should fit in a tweet. Short, simple, perfect.

Why don’t we want all the details? Well for one you overwhelm us with too much information at once if you paste in the readme. And for another, themes and plugins gets hundreds of reviews to comb through a day. Keeping it simple and short saves us time, which makes it easier for us to work through high volume. Where we want to see details is in your readme.txt. These are absolutely required for a couple reasons. First (and most important) we want to know that you’re ready to go live. A plugin should only be submitted when it’s ready to be released to the wild, after all, and that means you have a fully finished wordpress.org repository page which is handled by (you guessed it) the readme. If I can’t read your readme and go “Aha, that’s how the plugin is installed and configured and that’s how I use it” then you have done something wrong. The readme.txt is your gateway drug. Love it. Make it sing.

Something I often tell people who have had plugins rejected is that when they resubmit “Put ‘I talked to Ipstenu about XYZ’ in the description so we know you’ve already spoken to one of us. That makes it painless for me to look in our group email box, find the previous conversation, make sure we’re all on the same page, and approve. Also if I both handled the earlier conversation and I see your submission, it’ll trigger my memory and I’ll get through your ticket faster.

ZIPs

As of today, you cannot submit a plugin or theme to the WordPress.org repositories without a zip. not a RAR, not a gzip, but a zip.

I love getting zip files, but many times people submit zips that don’t open on linux, or have another zip in them. What we want in that zip is your complete plugin that I could upload to a test site. A theme will be auto-rejected by their scanner if it doesn’t meet their standards, you’ll have to start over. Plugins we still review everything by hand, so we have to open your zip. Personally, I use TextWrangler, which actually lets me open a zip without having to unzip it, but sometimes people zip things weirdly and I have to open it and drag the folder up.

If you’re using Github, there’s a built in link to a zip, which you can send us. BUT. Keep in mind, the zip will not bring in submodules. Yeah, ain’t that a damn dirty trick? You can use it to update your own code, but anyone who pulls down a zip to test with won’t get it. That really annoys me, and I’m not sure if it’s a bug or something Git did intentionally. Oh, submodules. You’re so complicated.

Do we care what you name your plugin’s zip? No. Do we care that you’re calling that name explicitly in your code? Yes. Use functions to determine directories and save us all a hassle. Do we care about calling wp-config.php and other WordPress core files by name? We sure do, but that’s another topic altogether.

Summary

In summary? Short slugs, descriptive names, simple descriptions, detailed readmes.

Of course, that’s high level stuff and doesn’t explain how to pick a plugin name. I’m highly fond of puns (hence Genericon’d) or I name things based on their original concept (rss2email was plugin’d as post2email). Sometimes the name is just obvious (Rickroll). Do you have tricks for coming up with a good name?

7 August, 2013