Tag: wordpress

Recovering Your Cape
One of the odder “hacks” out there is one where the person, once they get in, de-frocks your Super Admin on a Multisite. This isn’t always a hack, sometimes it’s just a simple mistake.

To quote my friend Jen Mylo:
1. People give away admin rights like logo-encrusted keychains at a car show and then the new admins abuse the power.
2. Someone who has admin rights deservedly but doesn’t know code makes a mistake.
[…]

Some people make bad decisions about who to give admin roles.
There’s an extra level of problems with making everyone and their pet monkey a super-admin on Multisite. You may think it’s a great thing, because now someone else can add new users, install plugins, edit themes and plugins, and of course, use iframes and PHP and such in widgets.

We run a Multisite at work, and they let me ‘secure it up’ recently. The first thing I did was demote pretty much everyone except five of us to ‘Editor.’ I told them all that I’d done this, and if they found something they couldn’t do, tell me, and I’d fix it. At this point, I’ve changed only three people to Admin, and dropped even more to ‘Author.’ Why? Because they don’t need to have high levels of access to do what they need to do! The admins on the site can tweak theme settings, play with widgets, and add ‘existing users.’ Everyone else? They just write content. Heck, most of them don’t even need to be Editors, but we gave them that level so they could help us copy-edit other posts. Two people complained “I need Super Admin access!” and I gave them my best Enda: NO CAPES.

Limit your admins, and there is less of a chance someone will accidentally remove access from the wrong person.

So now that that’s out of the way, how do you get it back?

Normally, reinstating an admin account is pretty easy. You go in via mySQL, pop open the wp_usermeta table, find your ID, and toss this in for meta_value for wp_capabilities: a:1:{s:13:"administrator";b:1;} That won’t restore all the roles, if you happen to be using Role Scoper, or some other management tool, but if you’ve got that, you can do anything. If you’re using WP-CLI, wp user update 1 --role=administrator (assuming you’re user ID 1).

There’s a sidebar/caveat to this. Sometimes this doesn’t work, and it happens if you change your DB prefix. So normally you have the prefix wp_ and the table wp_options. In that table you have a option named wp_user_roles and everything works. But then you make a new site, and you pick a different DB prefix, maybe you heard it was more secure, or maybe you wanted both tables in the same DB. Either way, now you have wp_wdssrr_options instead, and when you copy over your old options content, no one can log in. It’s because you have to rename that option to wp_wdssrr_user_roles

I just had a site with this problem last week.

On the other hand, getting back Super Admin access is less straightforward, but by no means is it impossible.
1. Go into wp_sitemeta and look for site_admins.
2. In there you will see something like this: a:1:{i:0;s:7:"Ipstenu";}
3. If your userID is ‘superman’ then it would be a:1:{i:0;s:8:"superman";}
Capitalization and stringlength matter. Add one user, and use that to correctly restore power to the others.

Can you do this via WP-CLI? Yes, if you’re on the latest versions. Kind of. You can get a list of super admins via wp network-meta get 1 site_admins and in theory wp network-meta update 1 site_admins USERNAME would work except that the data is serialized. I opened a ticket with WP-CLI, and it’s a ‘plugin territory’ issue right now, so I’ll have to see if I can code it myself.
25 June, 2013

Shortcode: MLB.TV

I like baseball, I like the Indians. I like embedding content. Why MLB.tv likes to make their stuff not easily embeddable is beyond me. I think [mlbtv id=28142247] is way easier to deal with if I’m using the visual editor. I grabbed the default sizes from their settings.

<?php 
// MLB.TV Shortcode - Better code by Konstantin Kovshenin
// &#91;mlbtv id="###" width="480" height="270"&#93;
function mlbtv_shortcode( $attr, $content = '' ) {
    $attr = shortcode_atts( array(
        'id' => null,
        'width' => 400,
        'height' => 224,
    ), $attr );
 
    $attr = array_map( 'absint', $attr );
    $url = add_query_arg( array(
        'content_id' => $attr['id'],
        'width' => $attr['width'],
        'height' => $attr['height'],
        'property' => 'mlb',
    ), 'http://wapc.mlb.com/shared/video/embed/embed.html' );
 
    return sprintf( '<iframe src="%s" width="%d" height="%d" frameborder="0">Your browser does not support iframes.</iframe>', esc_url( $url ), $attr['width'], $attr['height'] );
}
add_shortcode( 'mlbtv', 'mlbtv_shortcode' );

[mlbtv id=28142247]

Looks just fine.

23 June, 2013

Speaking at WordCamp San Francisco – 2013

It’s true! I’ll be speaking at WordCamp San Francisco again this year.

Last year I talked about supporting WordPress and how you can give back. This year, the subject of my talk is “Don’t Use WordPress Multisite.” I wrote a post here about that in 2011, and while quite a lot of it remains true, I still see hundreds of people who think Multisite is the cure to all that ails ’em.

I love it, but it’s not everything and a side of fries. But I’m not going to give away the talk here, and it’s not just going to be a copy of that post. So feel free to read it, offer comments, and meet me where I left my harp: Sam Frank’s Disco.(This is a very bad joke I’ll tell you if you want.)

21 June, 2013
To Fork Or Not To Fork

Sometimes the question you have to ask yourself is if you should fork. With a plugin, this is a fairly easy conversation. You want functionality, the original author doesn’t, you fork. But when you look at a theme, you start getting into messier territory.

In many ways, a theme is ‘simpler’ than a plugin. Theme devs, don’t shoot me! What I mean is that a plugin can be or do anything, but a theme is always a theme. While it may change how your site looks in amazing ways (and I am constantly in envy of people who can visualize like that), it really is just a theme. This is why reviewing themes is easier to monitor and manage than plugins. But that’s another conversation. The point here is that when you want to extend a theme, you make a child theme. Done.

What happens when you’re already using a child theme, though? StudioPress, a theme shop I love, makes child themes and sells those. This site is using a child theme, though it’s currently one of my own devising. Previously, it was using a child theme called Streamline, however, and it had a lot of changes.

So when do you make a child theme, and when do you extend it in other ways? It really depends on what you’re doing. While I sat and tried to figure out where my personal breakpoints were, I realized that since the best themes know they are a theme, and not a plugin, it was really easy. A great theme lets you seamlessly use a plugin to add in functionality. They may even tell you what the best ones are. Recently, Coen Jacobs wrote about how good themes never bundle plugins and he’s right. A plugin is a plugin, a theme is a theme. Keep ’em separate, keep ’em safe.

I’ve done it in three different ways for three different sites, and I’ll explain my rational below.

The Simple

One site is simple. Every ounce of functionality I needed, and more, was in the core code of StudioPress, not even a child theme was needed. All I wanted was to change some colors and add in a couple CPTs and shortcodes. That was easily done via Jetpack, which has a CSS editor, and a couple plugins. Actually, 99% was the CSS, once I sat down and looked at it. All the weird stuff was normal plugins.

Sometimes simple is a teeny bit complicated, and when that happens, I may make a custom mu-plugin or two, but in general, not so much needed unless I want a Custom Post Type. And anyway, I never put a CPT in my theme if I can help it.

The Complicated

On the other hand, one site is hella complex. I found a theme I really, really, liked. Almost. And worse, this was a child theme. It was exactly what I was afraid of. There was no way I would get what I wanted out of this theme unless I edited the functions.php file, a lot of the CSS, and a ton of the images. Could I still have done this via CSS and a couple plugins? No. Well, the CSS yes, but not the code. I had need for some crazy functions, a total re-write of comments, and the list went on.

In this case, I forked. I ripped out the small amount I never wanted. I added in the medium amount I did want. I directly edited the theme’s CSS, added in a post template, and changed all the images to my chose color. I even added in a different font. Could I have re-written from scratch? Of course, but the theme had 90% of what I already wanted to do.

There actually is a step before forking, and that would be using plugins. I know I mentioned plugins before, with the simple themes, but actually most theme frameworks are extra special. They often have custom plugins like Simple Hooks, which fundamentally lets me do everything I might do in a functions.php file for that theme. This means most of the time, I don’t fork. But. This theme really was so complex that I needed more than just the simple hooks. Genesis Complex Hooks may have done it, or another plugin to make a transient functions.php (ala CSS editing). And that would have done it except for when I wanted to change a lot of images, add in JS, and then a custom page template …

Well you see how it goes. The point here, however, is that I sat and thought about it, studied my setup, and made a long term decision. Originally I was using the plugin way, but when it stopped being extendable, I decided to do this, and I regret nothing.

The Original

The last option I had was I theme I kind of liked, but it was old. It was pre-HTML5, it didn’t have microformats, but more-over, it wasn’t aging as well as I would have liked. I made a list of what I liked about it, what I didn’t, and what I really wanted. While the list was short, it was also clearly not going to just be CSS. I wanted a custom front page, an extra page template, images, and Genericons built in. In short, I wanted this theme to be something that could carry me onward, regardless of a plugin, even one I wrote.

I have not made my own, 100% from scratch, child-theme in a long while, and this one may not really count since I was designing it to look like something else. This took me an afternoon to bang out the basics, and a couple days of minor fixes here and there to perfect them. Release and iterate, as they say. Certainly, I could have taken someone else’s theme, but it was going to be a surprising amount of work to do that. Instead, I made a list of my needed features and my desired options, and went to town. It’s still a pretty simple child-theme (which speaks well to the inherent extensibility of the parent), but now it’s mine, and it’s easy to extend it and expand it.

The Rest…

What about you? What do you think about when deciding how to handle a theme that needs changing?

17 June, 2013
Migrating to DreamPress
I should start with the note: You do not need to do this. We’re finishing up the last bells and whistles on a script that will handle all this for you if you have a One-Click-Install, but if you really just can’t wait or had a manual install, here’s what you’ll need to do. Keep in mind, there will be about an hour where your hosting will ‘vanish.’ In the words of Ford Prefect, don’t panic.

Again, you don’t have to do this. We will have a magic button soon enough. That’s why this isn’t going up on the Wiki, it’s really not going to be (long term) useful except to people who love experimentation.

We have a magic button!

But if you still want to do it manually, read on.

So you saw the news about DreamPress and read our bragging post about it? You got super super excited and then bummed, because the magic button isn’t done yet? Well… Okay, you can migrate manually (I did it for this site yesterday), but you need to know shell. You can do all this with FTP, but it’ll take way longer.

If you just want to make a new domain, read DreamHost Wiki: DreamPress, and you’re good to go! Otherwise, pull the hat down snugly, because here we go!

1. Remove Hosting

Yes, I know. It’s scary. By removing hosting you will turn your site to DNS only. This is OKAY. Your files and your DB will remain exactly where they are. The Remove button is right under ‘Fully Hosted / User : elftest‘ so just click that.

See? Now it’s DNS only.

2. Add DreamPress hosting

Go to https://panel.dreamhost.com/index.cgi?tree=domain.wordpress& and add a new site.

You should see a happy green box telling you that it will take 15-30 minutes to provision you the site. Sorry about the wait time, but we’re actually building you the server stuff on the fly. It’s special.

While you’re waiting, let’s get some things done.

3. Export the old DB

Everything is perfectly safe and sound, so just go ahead and do that. Save it locally to your computer.

Go to https://panel.dreamhost.com/index.cgi?tree=goodies.mysql& and log in to your SQL database. The directions are the same as our normal Backup MySQL ones, so just go and do that.

If you’re Command Line savvy, you can do this via WP-CLI.
```
ssh oldaccount@oldserver.dreamhost.com
cd example.com
wp db export
```
That will reply with “Success: Exported to example_com.sql”

By the way, you’ll need to have the server name (not your domain name) in order to SSH in, as we’ve already pointed your domain to DreamPress. It’ll be something like ps10000 which makes your SSH ps10000.dreamhost.com. You can leave the SQL file there, we’ll pick it up later on in the show.

As soon as you get that email saying “Yay! DreamPress for you!” we’ll ignore the email’s directions and skip on to…

4. Get the new credentials for both SQL and SFTP.

On the DreamPress page, you’ll see your new site info.

You’ll be able to find the new passwords at the usual locations. In the case of the user account (which will be something like wp_kxezav), you’ll want to set it to something you know. While you’re in there, change the account type to “Shell account – allows SFTP/FTP plus ssh access.” I personally also check to disallow FTP, for security. I also like to rename the account something like ‘ElfTest – DP’ so I know this account is for ElfTest on DreamPress.

By the way, you may wonder “Why can’t I have one ID for all my domains on DreamPress?” and the answer is twofold. First, we’re charging you per site. Yes, site. Secondly, security. If one account gets hacked, the others are safe. This is a good thing!

5. SSH into your new account

It’ll be ssh wp_kxezav@ps1121212.dreamhostps.com or such and this will dump you into not the domain, but the folder above it. This is important! You need to be in the example.com folder in order to do anything. Notice also how the domain is suddenly dreamhostps.com and not just dreamhost.com? Also important.

By the way, if you’re going to be using a lot of SSH, you should set up passwordless SSH access. It’s perfectly safe (in fact, safer than entering a password), and has to be set up per computer but .. how many of us use more than one computer? Hush, geeks.

6. Super power time! Let’s copy everything over!

Actually, let’s delete everything first. Yes, I know what I just said. There are reasons. This is just faster. I’m super lazy, so I first opened up wp-config.php and copied the SQL data for the NEW database.
```
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'example_com');

/** MySQL database username */
define('DB_USER', 'examplecom1');

/** MySQL database password */
define('DB_PASSWORD', 'likeaflaninthecupboard');

/** MySQL hostname */
define('DB_HOST', 'mysql-1.example.com');
```
Obviously changed for my protection. You’d never publicize your passwords. Right? RIGHT? Good. I saved this to a text file on my laptop for the time being. Now let’s delete:
```
ssh newuser@ps1121212.dreamhostps.com
cd example.com
rm -rf *
```
This wipes out everything in my domain’s folder. Make 100% absolute sure you got the right folder! Once you’ve done it, let’s copy things over!
```
scp -r olduser@oldserver.dreamhost.com:example.com/ .
```
SCP is ‘Secure Copy’, and is a fancy pants Unix Command. I’m fond of it. You’ll notice that I said to use ‘oldserver.dreamhost.com’ and not ‘example.com’ and this is because we’ve already pointed your domain to DreamPress. Zoing! When you do this, you’ll be prompted for a password.

Then you’ll get a mile of stuff like this:
```
wp-config.php                                                  100% 3583     3.5KB/s   00:01
xmlrpc.php                                                     100% 2719     2.7KB/s   00:00
readme.html                                                    100% 9177     9.0KB/s   00:00
admin-bar-sprite.png                                           100% 2470     2.4KB/s   00:00
```
This is SCP copying everything over, safe and sound.

7. Change your Database Stuff

There are two parts here. First you want to copy that DB stuff you saved before into the wp-config.php file, replacing the configuration you had there before. Second you want to import that backed up database into the new DB.

You can do this via phpMyAdmin if you want, but if you’re using wp-cli (and you should, it’s awesome), you can do this:
```
wp db import example_com.sql
```
Whaaaaat? How did that work? Remember when you exported on the old setup and then SCP’d the files over? Guess who came with! That’s right, you slipped your DB over nice and fast, and boom goes the dynamite, you’re in.

8. Have a beer!

I always end things with a celebratory something. Your URLs didn’t change, so you’ve got nothing to worry about. Once you’re sure everything’s good, go ahead and delete the old user ID as long as you are 100% certain you’re not still using it!!! Remember, a lot of us use the same IDs for multiple domains.
4 June, 2013
Not RSS 2 Email
Back in 2011, I made an RSS powered email list using rss2email. The last new version was released that year, and while the last two years have worked perfectly well, there’s one small problem. The developer appears to be done with it. This happens, and the beauty of open source is that people can pick up the code, fork it, and carry on. The annoyance is that sometimes the new coders do things that break it all for you. In this case, the running fork of rss2email uses Python 3.2 or higher.

If you’re using Python 3.2+, grab rss2email the new version and off you go! But if, like me, you’re on a server that doesn’t come with that version of Python, you can start swearing. This is not something you can just upgrade, either as Daniel Eriksson explains how to do this on CentOS 6 (my flavor). Many different flavors of Linux use the old 2.x branch of Python, and there are no plans I’ve seen to upgrade any time soon.

Now I’m faced with a dilema. Do I mess around and upgrade on my own, or do I find another answer. You know I went with option B, right?

I sat and thought really hard about what I, personally, needed this to do. This is a key component to any code you’re going to write. Make sure you know what you need. Let’s break things down:

Needs
- Email to be sent to a specific address automatically when there’s a new post.
- No email sent on pages or CPTs
- Post ‘excerpt’ is message content
Wants
- Change ‘to’ email on the fly.
- Select full post or post excerpt in email
- Customize ‘from’ email address
Dream Future
- Ability to say “no, not this post”
- Customize email message
- Allow options for different post types to get emailed
That’s pretty simple, isn’t it? It’s clear cut what I need, what I want, and what I’d like to have if I have time. Not every project is this simple, but today it is.

I actually knew how to do my ‘needs’ already, but as soon as I tested it I found I had to expand on what I meant by ‘when there’s a new post.’ If I hooked into the publish_post action, the email got sent every time a post was updated too. This lead me down to Notifly, which emails a list of people for every post and comment, but not post updates. That gave me the magic of transition_post_status, which solved that first problem.

At this point, the question became “Why not just use Notifly?” The first problem I had was that it sent out emails for comments too, with no easy way to turn that off. I could have forked, and I started looking into that when I ran into problem two, which was I couldn’t change the ‘from’ email. This was something that became a bigger issue later, when I realized I needed to be able to change the from email to work better with restrictions on certain hosts and with certain mailing lists. I could still edit the plugin, but I looked at what that plugin did and what I needed and wanted. Editing Notifly to do what I wanted would mean overcomplicating it and adding a lot more options. I could fork it, but I’d be stripping everything out and rewriting if I did that, so I decided to carry forward with my own thing. I would say the plugins are similar, cousins, but approach the goal in different ways. Semantics, I know.

Once I mastered only emailing on post publish, I had to tell it not to email on non-posts. No emails being sent on CPTs and pages was easy and I could have used is_post_type() and checked for posts, but I decided to use get_page(), because that let me expand on some other features later. This was new to me, but since I wanted to use the post excerpt, this was going to be, bar none, the fastest way to pull that in.

While I love being able to read whole posts in my RSS reader, I lose a lot with it, in regards to formatting. For the site I desired to run this on, the layout is a huge thing. On top of that, thanks to some idiots, I had to turn on hotlink protection, lest they crash my server again. Also I use a lot of embedded media (HTML5 video, twitter, etc). That means the ‘whole’ post generally looks like crap. So for every single post, I custom craft an excerpt. And this is why get_page() was awesome, because I could use that to pull the excerpt.

The default WordPress emails are sent from ‘wordpress@yourdomain.com’ with the name ‘WordPress’ and while that’s great, I wanted mine to be sent from ‘Blogname’ (the email address was fine, I’ll just add it to the email list as a moderator). That changed my ‘want’ of being able to customize the from info into a ‘need’ but it was also pretty easy to do.

If I was only going to use this code on one site forever and ever, I’d probably leave it at this. But … I know I’ll want to use this around other places. I started by looking at my ‘wants’ and put those in as well.

So what did I end up with?

Post2Email

This is a simple WordPress plugin that lets you set a to email, a from email, and a from ‘name’. It uses the RSS settings to determine if your email body is the full text or the excerpt. It only emails on posts, not pages or CPTs, and not for private posts. You can only set one email because of reasons, first being I only need to send to one address, but second is that I really hate when people send me emails I don’t want or need. Limiting the number of emails you can send to will help that. It also helps you not piss off your webhost by spamming people. Seriously. You use my plugin to spam people, I will hurt you.

What about my dream features? Handling the different post types means using get_post_types(), which isn’t horrible. In theory it’s just a check ‘If the option for that post type isn’t checked, fail out.’ It’s not something I need, and I really don’t feel like auto-emails for everything is a good idea (pages and CPTs are not posts!), so I’m going to wait and see if this is a need for people.

Flagging per post I have no idea how to do, since I don’t yet know how to put a custom post option like that per-post and check it on publish. Yet. Since public posts are public, I think that it’s fine having it email on all public posts. Opting out like that is not for me, but if enough folks come up with it, I’ll consider it because it’s a good excuse to learn something new.

Customizing the message is easy and when I went back in to fiddle with internationalization and proper content serialization, I added it in. I also went and used wp_parse_args to remove setting the defaults in the database, and make it easier for me to add more options in later.
22 May, 2013