Tag: wordpress

MeetWP: Troubleshooting

I met the guys from MeetWP when I was at WordCamp Chicago, and when they asked if I’d be interested, I thought about it for a second and said “Sure, why not.” I live in the OC, you see, and while I enjoy meetups, the two nearest me are just over an hour away. I’m a one-car home, and generally my spouse has class when these meetups are, so the timing has just be downright rotten. But a virtual meetup? Hey that has potential.

What is this thing? From their site:

MeetWP is an online WordPress Meetup. Local Meetups are a great place to learn about WordPress and meet new people in the WordPress community, but not everyone can make it to a local meetup or are in an area where a Meetup dedicated to WordPress can happen. MeetWP, the online WordPress Meetup, is here to bring together people all over the world in a virtual meetup to learn from each other.

So yay! They’ll be posting this up on their webpage as a link with all the logs soon enough, and you’ll see me up there as MeetWP #4 (following JJJ, Chris Lema, and Lisa Sabin-Wilson). I didn’t do slides, so you get to watch me break a site, fix it, and then show you my break-fix site (more on that later) where I have examples and plugins you can use to install, break your site, and fix it.

There were crowdsourced notes on Google (you can read them here), and one of them is ‘Don’t be Stupid.’

I try to cure myself of stupid as much as I can, because being hacked almost always boils down to someone being stupid. If I can not be the stupid, I’m in good standing.

Oh and yes, I think SSH and SFTP are a requirement for a webhost. If they can’t do that, I’m gone.

11 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
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
DreamCon In Review

The weekend after WCSF I talked at DreamCon, which was our own little Webhost convention/camp for technology and other things. As Matt said, we’re kind of the wacky Webhost, and I love it that way here at DreamHost.

Some of my coworkers talked about the technical stuff, like WP-cli and how DreamPress works, but I talked about some slightly more esoteric and conceptual things, no coding involved topics, because I tried to think about the questions people who host with us asked me the most.

Choosing WordPress Plugins

This was the more geeky of the two, but was an overview on how I search for plugins, value the devs and their work, and determine which ones I use. I mentioned needs and wants a couple times, which makes me think I’ll end up giving people a talk on that one of these days…

The questions I got after this session were interesting. I preemptively answered the long standing question I had never been able to answer before, which is “What is your favorite plugin?” I finally have an answer, and it’s MP6. My eyes suck, and for me, MP6 finally made the back end of WordPress totally readable for me, without having to increase my browser’s font size. The font was better, and larger, and clearer. Normally I hate black backgrounds, but for some reason MP6 doesn’t give me headaches.

The best question I got was how to search effectively. My answer was to be more exact with search terms. Too often we go for broad terms and narrow down, but I like to go the other way. “wordpress plugin calendar event list” – I pick every major term I need in that plugin, and more precise results follow.

Get Out Of The Monkey House

Besides the fact that all the devs in the room cheered when I stated “code is art” I think this one really opened people’s eyes. Remembering that the design of your site doesn’t stop at the pretty stuff, that your content and the flow of how the site works is also a major impact, is huge.

By the way, code is totally art. You’re making something out of nothing, inventing and building a concept that never existed before. It’s just like writing music. Be proud of it. The most standout question from this talk was what do I do when a customer demands they stay in that monkey house? I put my foot down. When I get into contract work, I have always stated up front “You’re hiring me to be your expert, which means you may suggest things for your website that I, out of my experience and expertise, know to be bad ideas. When that happens, I will tell you that we should not do these things, and why. This is my power of veto. I will only use it when I have proof, via research, that what you are proposing is not in your best interests. If that’s not okay, then we don’t sign the contract. If it is, then you will accept my actions on web design, just as I will accept yours about your product. You know more than I do about that, I know more than you about this.”

Thus far, no ones walked away, and I’ve never made a website with a blink tag (except for the gag website, where the contract was to make it look like Ling’s cars…).

5 August, 2013