Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: wordpress

  • eCommerce Dream

    eCommerce Dream

    At the end of my WordCamp San Francisco talk, I said I had a dream. A dream about a plugin that can share an inventory between WordPress sites on a Multisite Network.

    Firefly_-_WhitefallImagine, if you will, a store with a physical products (Geisha dolls). The store has a bunch of different types of dolls. The store has satellite stores, one in Ariel (their flagship store) but now one on Bellerophon and another on Whitefall. While the Companion-Style dolls sell well on Ariel and Bellerophon, the Cowboy-Style ones sell best on Whitefall. Also each store has a different kind of clientele.

    So the Dollhouse Store makes a website, and then using Multisite, makes another site for each location: whitefall.dollhousestores.com and so on (or maybe whitefalldollhouse.com even). At first, the webpages are just a list of the local store products, come and buy them here, photos of the locale, employees, and local events. Then they decide to sell stuff on line. But they only want to list items for sale under specific criteria.

    1. All items for sale are stored on the network admin
    2. Each store can select what products they have at their store
    3. Each store controls product volume.
    4. Stores can request more product from homebase

    Now of course they could have a separate store for each site, but they want to manage what possible items could be sold online, so having that controlled by the network makes sense, doesn’t it?

    Firefly4_LMeanwhile another store sells cows. All the cows live at Persephone, and are shipped out to Jiangyin and other stores. They’re doing well with everyone going to cowship.com, but they too want to have jiangyin.cowship.com and so on. Each store lists what cows are for sale that live well in each location because Holsteins’ don’t like Bellerophon, who knew? This way, someone on Jiangyin can order Holsteins but not Texas Longhorns. Obviously they need to control which product can be sold at each location, same as the Dollhouse, but they also have a different problem. Their product amounts must also be stored in one location and shipped out from there, so they want to make sure they don’t oversell their cows.

    Their criteria:

    1. All items for sale are stored on the network admin
    2. Network admin controls absolute amount of products
    3. Network selects what products they have at each store
    4. Orders per store base product volume on the network amount

    These are pipe dreams. Today there is no plugin that ‘shares’ an estore across multisite sites on a network. You can’t even do it with ‘digital’ products which now that I say it aloud, I think Pippin should totally get on that.

    Today, all sites are separate, and since estores have their content saved per-site, there isn’t an easy, friendly way (if there is at all) to pull data between sites in a way that preserves shopping carts and such. I wish there was. I get asked about this at least once a week, and I have to say “Today, there is no plugin that can share an inventory between WordPress sites on a Multisite Network.”

    But this is a complicated thing. Multisite itself isn’t actually built to handle that kind of thing, since the network doesn’t have posts or pages. You’d have to dedicate a site on the network to the shop and pull in content from there, which of course has a switch_to_blog() overhead penalty. I can’t even begin to get past the paper thoughts I have here.

  • Why Does The WordPress Background Auto-Upgrade Work?

    Why Does The WordPress Background Auto-Upgrade Work?

    Way back in the stone ages I wrote an explanation as to why the WordPress Upgrade didn’t work all the time. In that post, I pointed out that servers and your installs are special snowflakes and not all the same, and that’s why an upgrade doesn’t work all the time. I’m amused that no one pointed out to me that stance (one which I still maintain by the way) seems contradictory to my proclamation that we should love the built-in updater as of WordPress 3.7.

    Allow me to challenge myself.

    Your server, with your install and your plugins and theme and tweaks, is still a special snowflake.

    The background updates for WordPress keep this in mind.

    Oh, I have to go further into this? Fine. The reason the updates are restricted to just minor, security/maintenance, updates is that, in general, they do not cause the problems people experienced 2010. It’s been three years. We’re smarter, we learned a lot, and most importantly, if the problem in 2010 showed up again, WordPress would not to install. I heard the sounds of brakes screeching. Let me explain. We want WordPress to not install itself if it can’t. We’re not defining that as a ‘failure’ because while your install did fail to upgrade, your site didn’t break.

    Let’s get the down low from the man himself:

    Those seem pretty straight forward. WordPress 3.7.1 was made so that a failure to update didn’t break your site, because if it couldn’t apply the install, it would rollback seamlessly to 3.7 without you noticing. Well, except for the email you got to say “Hey, this didn’t work, man. Sorry.”

    Why does this work and the major upgrade does not?

    That’s the real question, isn’t it? Why are we having such a monumental success for 3.7 to 3.7.1, where we didn’t from 3.6 to 3.7? Actually, we did, but you’re not comparing the right things.

    First of all, the 3.6 to 3.7 upgrade is one of the more stable ones we’ve had in a while. 2.9 to 3.0 was the birth of my OMGWTFBBQ!!! post in the forums (and the catalyst for why I’m working for DreamHost). It was a major overhaul, with a lot of changes, and a lot of complicated tweaks. Let’s be frank, it was a re-write of a crap-ton of modules, and it was just going to break things. WPMU folded into WordPress and changed to Multisite? Yikes! But as time has moved on, I’ve been reporting more and more “Everything’s okay in the forums.” This does not mean everyone is perfectly happy and perfectly safe, and the upgrades were a 100% success. We have the same type of complaints as we always have. Themes and plugins were not robustly tested enough with the new release, so they broke when the upgrade happened. This is (currently) unavoidable.

    So again, why is this working so well?

    Three Nacin MoonBecause the core team who wrote the update script learned from their mistakes in the past. The changes made in WordPress may be bold and large, but they’re also done carefully. Instead of just saying ‘What’s done gets into the new version,’ 3.7 took the ‘feature teams’ trend started a few releases back to the next level. Only if the feature was done-done did it get into 3.7. This meant that while we did not have a major ‘feature’ this release (like we did with the Media Release in 3.5), we had the opportunity to make each feature rock solid on it’s own. And this worked better than many expected because of “features as plugins.”

    While some aspects of core have to be developed in core, others begin their lives as plugins. Like the password-strength improvements and auto-upgrades were both plugins before they were added to core. Also if you look at 3.8, pretty much every major feature that can be a plugin is one. This means that one feature, a new post editor, didn’t make it because right now it’s not ready. Having things be plugins also lets more people test them, by installing the plugin without having to upgrade to a beta version of WordPress!

    Finally, and this is really important, not everyone gets upgraded at the same time. Within 24 hours of the release of WordPress 3.7.1, only 75% of English installs were updated. This was done to keep an eye out for load issues on WordPress.org’s boxes, but also on shared webservers. Which by the way are doing just fine. As we go forward, Nacin’s said he expects this to be sped up, especially for a 100% security release.

    How does it work? Glad you asked! The best explanation I got at this was over beer with Nacin, and sold me. At 7am and 7pm your site pings WordPress.org to see if there are updates. When this happens, your URL is hashed into MD5. Then the first three letters of that is converted to a base 10 number (MD5 being based on base 16, which doesn’t do you any good unless you have 6 extra fingers) and that’s used to decide if you get an update or not. The cool part of this is that it can be used to push to only one out of four thousand sites.

    I know this is all probably sounding like fan service. Like I can’t see anything wrong with this. Nothing is perfect. I’m well aware that things can break. I’m well aware there are possibilities like WP being DNS highjacked, or a plugin circumventing the updater. But. If the DNS is jacked, the API just won’t work unless the jacker has a duplicate that works. And the evil plugin would kind of have to do the same thing, or they would only be able to impact you when a natural upgrade occurred. And neither of those are actually related to background updates. They could have happened at any time in the past. They could happen tomorrow.

    Why do the upgrades work?

    Because WordPress grew up.

    And that’s pretty cool.

  • Is SEO Best Handled by a Plugin or Theme?

    Is SEO Best Handled by a Plugin or Theme?

    I’m not an SEO expert, but I know a heck of a lot more than many people who claim they are. For the record, I’ve been messing with SEO since it was ‘correct’ to put hidden text in the source code of your site. I used to spend time getting sites to rank well on Lycos and Altavista, back when I was but a wee intern for my friends. It’s fair to say I’ve been around the block with SEO.

    I don’t consider myself an expert because of skill, though in the last couple years, I’ve decided not to keep up as closely with things like schema, mostly because I don’t have to. I still retain a solid grounding in what does and does not make for good SEO (content!), and I understand that part of good SEO isn’t just content, it’s how the content is displayed for the reader, but also how the information is sorted for the computers at search engine companies.

    Credit: Plymouth UK
    Credit: Plymouth UK
    About every couple months, someone asks me if I prefer using a theme or a plugin to manage my SEO, and I have been giving the same answer for a couple years now. I don’t use either.

    This does not mean that the themes I use aren’t ‘SEO’ optimized, of course. It means that I don’t use their ‘extra’ features. I use, primarily, StudioPress’ Genesis Framework right now, and that comes with an SEO settings page which I never use. Ever. In fact, I turn it off in any child theme I make. This is not because I don’t think that it’s useful, but that what I do ‘use’ for SEO is already included.

    My SEO consists of making my content fantastic, using a theme that includes schema headers (or adding them myself if not), and following the guidelines Yoast outlines in his article WordPress SEO Tutorial. I don’t do everything he says (he likes ‘category/postname’ for permalinks, I like ‘year/postname’ but if date doesn’t really matter, I use category instead), but I do read and think about what it means.

    That’s the crux isn’t it? I don’t blindly follow advice, or use a plugin or theme because people say I have to. I read, I think, and I come to logical conclusions, and I apply them after I write my post.

    For example, Yoast says not to use ‘stopwords’ in titles and make them SEO friendly. I take this to mean your human readable title should be gripping, but the title slug should be short, to the point, and descriptive. So I customize every single title. I come up with four or five before I post, and then when I have one with a good grab, I tweak the title slug to be as short as possible, while still being descriptive. Sometimes I’m better at this than others, but I keep working it.

    pgpoaNext I customize my ‘publicize’ lede. This has to be good and it has to be short. I know I’m using my helf.us yourls, so the URL itself will be tiny, but that doesn’t mean I should use just my title for Twitter. I customize it, trying to make it a little more witty and pithy, to reflect me and my readers. Finally I customize my excerpt. Oh yes, my excerpts are all custom written, and they are intended to grab you hard. Like Yoast, I feel the only well written description is a hand written one, and I do it. For everything.

    This puts me at a funny disadvantage. Most plugins and themes I’ve seen tend to want you to make a custom meta description. There are plugins (like the one I do use, listed further down in this post) that allow you to use your excerpt as descriptions, but I’ve never quite understood why themes make this so hard. In Genesis, I have a field for “Custom Post/Page Meta Description” in every post, which if I use it, will change the meta value for description.

    When I dug into the code, I saw that it was pulling this:

    genesis_get_custom_field( '_genesis_description' );
    

    Clearly all I need to do is make that default to what I want. And when I figure that out, I’ll let you know. Right now, all I could do was remove Genesis’ function and replace it with my own. Not elegant at all.

    Now all that said, there are times when I see to ‘improve’ upon the SEO I’ve been given, because someone else is handling the content will far less care than I give. When that happens, I grab Yoast’s WordPress SEO Plugin. But for the most part, I don’t do anything on a regular basis that involves having to ‘customize’ my SEO, so it’s infinitely portable to any theme I want.

  • WPwatercooler – Multisite Edition

    WPwatercooler – Multisite Edition

    Half an hour kbittzing about Multisite with the players from WPwatercooler

    Credit: WPwatercooler

    It’s also going to be on podcast and sticher and apparently I have a nice, soothing, voice. Thanks, Cousin Dan, for the tips and tricks about that!

  • Command Line Cleaning WP

    Command Line Cleaning WP

    Blob-Town-The-Blob-1958-Documentary-@-Phoenixville-Pennsylvania-by-James-RolfeI’m a huge fan of the scorched earth clean up for WordPress. By which I mean when I clean up WP, I rip it out, scrub it, and reinstall. This scares the heck out of people sometimes, and if you’re doing it in a GUI, yeah, it can be sucky and time consuming. Me? I do it in 5-10 minutes, depending on if my cat wants to be petted.

    I’ve been asked ‘How do you do it that fast?’ so here are my steps for cleaning up WP, with the following assumptions:

    1. I’m working in the folder where WP is installed
    2. wp-config.php is in this folder
    3. WP is in ‘root’ (i.e. I’m not giving WP it’s own folder)

    If any of those aren’t true for you, adjust the folder locations in the commands:

    Download WP: wget -P ../ http://wordpress.org/latest.zip

    Unzip it: unzip -qq -d ../ ../latest.zip

    Backup DB: wp db export

    Pause. Here I’m using WP CLI, which makes my life way easier. If you’re not, you’ll need something like this: mysqldump --opt --user=username --password=password --host=yourMySQLHostname dbname > domain_com.sql

    Zip up the files I want to backup: zip -r ../domain.zip *.sql wp-config.php .htaccess wp-content/

    Set glob. Glob is scary, I know, but read about glob before you dismiss it (if you’re on korn, you can usually skip this): shopt -s extglob

    Delete files: rm -rf !(wp-config.php|wp-content)

    Pause. At this point, It’s probably wise to consider that my hack may be in my theme and/or plugin. If so, I want to nuke them and JUST keep my uploaded files, so I use this instead…

    Delete files: rm -rf !(wp-config.php|wp-content) wp-content/!(uploads|blogs.dir)

    Pause again. No matter what, want to scan for evil files, but this way I do it over a much smaller group of files. Either way, though, I do want to scan the folder for evil, because leaving behind hacks in themes and plugins is really common. Also it’s a good idea to delete every plugin you don’t use, and theme as well. Since you really can’t delete all themes but one on a Multisite, this gets harder. Generally I don’t delete the themes automatically, but instead go in and nuke them one at a time, so I run this…

    Delete files: rm -rf !(wp-config.php|wp-content) wp-content/!(uploads|blogs.dir|themes|mu-plugins)

    Now we can move on, knowing our personal files are clean.

    Copy it back: cp -r ../wordpress/* .

    Clean it up: rm -rf ../wordpress ../latest.zip

    And now you’re done! When you want to reinstall plugins and themes, I do via wp-cli because it’s faster: wp plugin install NAME and wp theme install NAME

    Then I activate as needed and I’m off to the races. If I deleted my mu-plugins, I copy those back from my backup zip, one at a time, checking each file for hacks.

    The best thing about this is you can apply the logic to any CMS out there. Just know what you have to delete and keep. The downside? It doesn’t touch your database. Rarely is this an issue for me, except in the case of the Pharma hack. I’ve not had a DB infected yet.

    Do you have a solid methodology for cleaning it up?

  • Plugin Wish: Login With Google

    Plugin Wish: Login With Google

    Now I know what you’re thinking. “Mika, there are a hundred plugins that let you log in via Google!”

    That’s not what I mean. Let me explain with a story.

    You have a business, example.com, and you use Google Apps for everything. Then you start tying this into other companies, like a time sheet company, that let’s you ‘Login with Google’ and redirects you to the right company settings. Cool, right? Kind of like this:

    replicon

    And you think you’d like an internal, private, blog, where people can post cat pictures. Or whatever. What if you could just have the login screen be that Google button? And you know there’s a bajillion plugins for it, but you want to have it be only people on example.com. So you@gmail.com can’t login, but me@example.com and dad@example.com can too!

    I want that.

    I have not yet seen it, but I think that would be an amazing plugin. By default, the domain it ‘validates’ would be the one on which it’s installed (so here it’d be halfelf.org), but you could override it (which is good, since I’d want to use ipstenu.org). Then you’d want it to ‘generate’ new users if they don’t exist, since you don’t want to have to add every single new person, right?

    Oh and you don’t have to terribly worry about that fired guy, bob@example.com, because once he’s fired and you disable the email account, he can’t log in!

    Some concerns of course would be Two-Factor Authentication. Also how do you handle multisite? I would envision a default nothing-set option for Multisite, where the network admin could network activate, and set the default domain there. Add in a check box for “Allow individual sites to override?” at the very least. Maybe a sneaky “Always allow the super admin to log in” setting too, though that gets complicated fast.

    Cliff Seal pinged me about this and said he’d been fidddling with https://github.com/logoscreative/wordpress-openid but he never finished. Who’s up for the challenge?

    And no, it did not escape me the hilarity of me, a loud “I don’t like Google owning all my data!” person suggesting this.