Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: wordpress

  • Moving WordPress Multisite

    Moving WordPress Multisite

    I answer this a lot.

    Edited to add: If you’re just moving to a new server and keeping your domain name, it’s exactly like moving Single Install WordPress. Just remember to make sure your new server is set up to handle wildcard domains, and your httpd.conf has ‘AllowOverride’ set to ‘All’ and you should be fine. If you’re moving to a new domain name, read on!

    Edit #2: The Incerconnectit Search/Replace DB script is also perfect to use, though you still need to manually edit a couple places.

    Moving a normal WordPress site is really easy. Copy over your data. Change your URLs, do a search/replace on your wp_posts table (to fix any internal links), go out for a beer. Some of you may need to edit a wp-config file, but mostly that’s it.

    Then there’s Multisite, which sucks. See, unlike single installs of WordPress, you can’t change your site URLs easily. Don’t get me wrong, if you’re a Super Admin, you can easily go into WP Admin -> Network -> Sites and edit the sites. You’d have two places to edit it:

    On the Info Tab

    On the Settings Tab

    But here’s where it starts to suck. If you’re changing tech.ipstenu.org to press.ipstenu.org for example, you do that and then you need to go to your database and look for the site posts table (in this case, it’s wp_2_posts) and search/replace tech.ipstenu with press.ipstenu.

    That’s not terrible, right? It looks a lot like moving a single install of WordPress.

    What if you have your site as subfloders, using ipstenu.org/tech and ipstenu.org/press though? And you want to move everything to lipstenu.org?

    This is where it sucks.

    See some widgets and theme settings store your data and include your URL. This is done with data serialization as well, which means the length of your URL matters. If you changed from ipstenu.org to Lpstenu.org, then you would be perfectly safe doing a total database search/replace of the domain name! But since I’ve proposed changing it to Lipstenu.org, I can’t do that. Any field that counted my domain name would be off by one, and thus invalid, and thus wipe out my settings. Oh and to make it worse? Depending on how you uploaded your media and included it in your site, your postmeta table might also be filled with this.

    It’s important to understand two things here.

    1. This situation exists on a normal single site install.
    2. You don’t have to change it in those places!

    And as a maybe third, I know a lot of people who do a blanket search/replace all the time and never have a single problem. But because I know enough who do have issues, I can’t safely recommend you try it unless you have a rock-solid backup of your database.

    This brings us to the point. How do you move WordPress Multisite to a new domain name?

    Very, very, carefully.

    You’re going to have to do some work in the database, so now’s the time to get some coffee and practice not freaking out. If you have phpMyAdmin, editing your WordPress database is not terrifying, but like a cat, should be approached with caution. Remember to take a full backup of your database before you start. A good backup.

    First, it’s perfectly safe to edit all wp_posts (and wp_x_posts) tables with a search/replace of your domain name. I strongly suggest using as much of the domain as you can: i.e. http://newdomain.com instead of just newdomain. This will make sure you don’t confidently change the content of your posts. The Incerconnectit Search/Replace DB script is also perfect to use here, but it won’t fix everything, which is why we have another step:

    Next you need to manually go through these tables:

    • wp_site
    • wp_blogs

    Those two tables are really straight forward, by the way. You’ll see what to edit right away.

    Then you have to manually (again) review all the wp_x_options tables and look for THREE fields:

    • home
    • siteurl
    • fileupload_url

    Only edit those. And yes, you have to do it manually in each of the options table unless you used the Incerconnectit Search/Replace DB script earlier.

    Once you’ve done that, go into your wp-config.php and see if you have to change define( 'DOMAIN_CURRENT_SITE', 'ipstenu.org' ); (depending on your change, you may not).

    And … that should be it.

    It’s a pain, but it’s not insurmountable.

    Right away, though, you can see the complications if you’re moving a site from ipstenu.org/wordpress to ipstenu.org, and while most of the changes remain similar, you need to remain vigilant and attentive with every change you make. The wp_blogs table is where it gets stickiest, as you have to add in the new subfolder (or remove it) by editing a separate field in the row.

    Just pay attention, read carefully, and remember to breathe.

  • SOPA Blackout

    SOPA Blackout

    I’m lazy and I don’t want to write a plugin, so I asked on Twitter if someone had one to black out a site for SOPA on the 18th of January. If you don’t get why this is a thing, please read WordPress.org’s post on SOPA. A lot of sites are going black from 8am to 8pm. I am, and I to didn’t want to use a plugin.

    My solution for this involves two files and is all thanks to Pete!

    To do this is really simple. Go in and make a file called .maintenance in the top level of your WP install. For most people, it’s the same folder as your .htaccess and wp-config.php files.

    Now edit that file and put in the following content:

    <?php
 
// Let's make sure you're not an admin/logged in!
 
function is_user_logged_in() {
    $loggedin = false;
    foreach ( (array) $_COOKIE as $cookie => $value ) {
        if ( stristr($cookie, 'wordpress_logged_in_') )
            $loggedin = true;
    }
    return $loggedin;
}
 
if ( ! stristr($_SERVER['REQUEST_URI'], '/wp-admin') &amp;&amp; ! stristr($_SERVER['REQUEST_URI'], '/wp-login.php') &amp;&amp; ! is_user_logged_in() )
 
// If it's after 8:00:00 on the 18th, we're going to show the blackout page
 
if ( time() >= mktime(8,0,0,1,18,2012) ) {
	// When we hit 8pm (20), we're back.
	$upgrading = mktime(20,0,0,1,18,2012);
}
?>

    What does this do? It’s pretty simple. First it checks to see if you’re logged in and, if so, lets you get where you need to go. If you’re not logged in, though, it checks the date and if it’s after 8am on the 18th, you get a maintenance page. After 8pm on the 18th, it swings back. (All this code, except for the date stuff which I wrote, is from Matt (Sivel):
    WordPress Maintenance Mode Without a Plugin and WordPress Maintenance Mode Without a Plugin Part 3/ ) Pretty cool right? And the 8am to 8pm is based on your server’s time, so it’s all local. It’s also pretty easy to see how you change that for your own time. I would say pick your busiest time to go black.

    But if you want it to look pretty, you need to do a little extra. (Code from WordPress Maintenance Mode Without a Plugin Part 2 and text from Blaccupy) Make a file called maintenance.php and put it in your wp-content folder. Here’s an example:

    <?php
/* Tell search engines that the site is temporarily unavilable */
$protocol = $_SERVER&#91;"SERVER_PROTOCOL"&#93;;
if ( 'HTTP/1.1' != $protocol &amp;&amp; 'HTTP/1.0' != $protocol ) $protocol = 'HTTP/1.0';
header( "$protocol 503 Service Unavailable", true, 503 );
header( 'Content-Type: text/html; charset=utf-8' );
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
        <title>BLACKED OUT</title>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        <style type="text/css">
        body {
                background: black;
                text-align:center;
                color: #eee;
                font-family: Helvetica;
                font-size: 2.2em;
                }
        </style>
</head>
<body>

<div style="width: 960px; margin: 0 auto;">
<h2>This website is..</h2>

<h1>BLACKED OUT!</h1>

<p>In protest of pending US legislation, which threatens the freedoms of websites like this one and the freedoms of the people who use them, this website is offline on January 18th, 2012 from 8am to 8pm EST.</p>

<p>Please <a href="http://americancensorship.org/">help protect our free speech</a> against the corporate and political interests which seek to take them away!</p>

<p>(And don't worry, we'll be back in business tomorrow!)</p>
</div>

<?php
die();
?>

    Which means your site will look like this on January 18th. You’ll notice I made some tweaks on mine. This is a default feature of WordPress, by the way. You can design your own maintenance mode page just with this one file, so y’know, party time.

    Now there’s only one catch. If you update WP via the automatic updater between now and then, you lose the .maintenance file. I don’t have a fix for that, but if you do, please comment!

    And yes, my sites are going dark on the 18th.

    ETA: If you have a Multisite and only want SOME sites dark, use Customize the Suspended blog page from WordPress Must-Use Tutorials. Suspend the sites and boom goes the dynamite.

    ETA 2: If you’re using MediaWiki (like I am on another site) I came up with this idea to go dark for SOPA. Its just a normal extension that, between those hours, redirects to the same page I use for WordPress. You could have it point to any page, of course.

    <?php

if ( !defined( 'MEDIAWIKI' ) ) die();

if ( time() >= mktime(8,0,0,1,18,2012)  &amp;&amp; time() <= mktime(20,0,0,1,18,2012) ) {
     
        include('/location-of/wp-content/maintenance.php');
    exit();
}
?>

    That code, sans the Mediawiki line, will also work as an extension for ZenPhoto, so pass it on.

  • Yourls

    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

  • Why You Shouldn’t Use Plugins

    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.

    Don't Edit CoreThat 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:

    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:

    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):

    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!

  • “Without a plugin” considered dangerous | sabreuse

    There’s just one problem with this. Plugins exist for a very good reason: to add non-core functionality 1 to your site without hosing up the whole lot.

    Via “Without a plugin” considered dangerous | sabreuse

  • Plugin Banners

    Plugin Banners

    WordPress now lets you add banners to your plugin pages.

    Naturally, I added one to Impostercide that reflected my own brand of humor:

    Which is now Nacin approved:

    https://twitter.com/#!/nacin/status/149884924990734336

    Add your own by creating an assets folder in your SVN repo (same level as tags and trunk) and add a file called banner-772x250.jpg (or .png). Make the image 772×250 px, check in your change, wait 15 minutes, and you’re done!