Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: wordpress

  • Changing Your Domain Name In Multisite

    Changing Your Domain Name In Multisite

    Even I hate moving Multisite if I have to change folders (like from domain.com/wordpress to domain.com). But if you told me “Mika, I need to change my domain from cocobanana.com to cocoabanana.com!” I’d say “Hold my beer for five minutes.”

    No. 2 pencilsI will note: If this process freaks you out, remember to never make changes like this without a backup. If it’s still super spooky, you may not be ready for Multisite yet. I would consider this to be a good litmus test, though, for a wanna-be-multisite-master. You’re going to need to be able to do these things to get there.

    Step 1: Search and Replace

    This is the easiest one. If you have WP-CLI it’s super easy.

    wp search-replace http://cocobanana.com http://cocoabanana.com

    Don’t have WP-CLI? Okay, grab Interconnectit’s Search/Replace DB Tool and use that.

    This will take care of 99.999999% of your site. It’s imperative you remember to use this tool! If you don’t use a tool that searches and replaces with consideration to data serialization, you will cry and reset all your themes and widgets. Manually. See? Told ya you’d cry!

    Step 2: Edit the Database

    Go into the database. Look at the wp_site table. Change the domain field from cocobanana.com to cocoabanana.com (seriously, that was it!).

    Then look at wp_blogs and change those domains similarly as needed.

    Step 3: Edit wp-config.php

    Open the file and look for this:

    define('DOMAIN_CURRENT_SITE', 'cocobanana.com');

    Change the value to cocoabanana.com and save it.

    Step 4: .htaccess and plugins

    I lied. There’s another step. Make sure you weren’t super smart earlier. Like if you used some rules to block hotlinking, make sure the new domain is added in there. Also make sure your plugins aren’t calling your domain in some weird way (though that search and replace should have fixed that too).

    Also if, like me, you hate www’s in your URLs, you’ll want to put this in your .htaccess to force everyone around. It also has the benefit of making sure the weird redirect of www being treated as a subdomain stops happening on Multisite. By the way, I still strongly encourage you to NOT use www in your Multisites, it’s a pain in the ass and you can educate people as to why no one has to have www anymore. Also WordPress itself has always suggested you NOT use it when activating Multisite. Do you know better than WordPress? No? Okay then, don’t use www.

    <IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteBase /
	RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
	RewriteRule ^(.*)$ http://%1/$1 [R=301,L]
</ifModule>

    Now can I have that beer back?

    Beer and a cup

  • Catch a Session

    Catch a Session

    When I was at WordCamp Chicago in 2013, Brian Richards asked me if I’d be interested in giving a WordPress ‘Session.’ Since not everyone can make a WordCamp, what if there was a live, online, session they could watch to get the same information? Thus was born WPSessions!

    I said yes, and months went by. Then he pinged me again, asking if I was still interested, and would I might talking about eCommerce and Easy Digital Downloads? That was new! Most people want support, community, or multisite. Since I’d recently written a book about running an ecommerce bookstore, I said yes again, and on Thursday gave a session.

    If you missed it, and you probably did since I did a terrible job promoting (sorry Brian!), you can check it out at WPSessions – eCommerce for Site Owners. It’s $30 for four sessions (mine is 51 minutes long), and while my slides are online , you never get quite the same impact as seeing me give them, do you?

    http://slides.halfelf.org/wpsedd/

  • Whatevergram: The Honeymoon is over

    Whatevergram: The Honeymoon is over

    I’m not a photographer. I’m not artistic in that particular way and I don’t want to learn to have to be. The joy of Instagram is I can take a photo, slap a filter on it, put a border, and boom. Done. Share it with friends. The sad part about Instagram is putting that photo on my blog. It’s all machinations and annoyances.

    What I wanted:

    1. An easy way to take ‘styled’ pictures.
    2. An easy way to push those pictures to my blog.
    3. An easy way to determine how I want the pictures to post.

    That’s all, three things. Now, Instagram wins at #1, and Pressgram wins at #2, and the both suck at #3.

    a cameraThat third one is the hardest, I guess, but what I want is that when I upload a file, it either makes an individual post or makes a gallery post of the whole day. And in both cases, I get the option of making a post publish right away or save it as a draft. I kind of love the idea of ‘This week in [Insta|Press]gram’ as a post for a photo blog. In looking at my options, I determined there’s one Pressgram plugin and a million Instagram, but none really do all of that.

    But really … Pressgram 2.0 fixed most of my issues with UI, and for that I’m very happy about the new version. It’s easier to read and use, the layouts make sense. I’m even okay with the in-app purchases for things (though charging for some of the things Instagram offers for free strikes me as a poor call). Lacking the nice, snazzy filter names (imagine naming them after WP Themes) and borders/patterns means that if I want those in a quick way, I use Instagram and the maybe Pressgram to upload.

    Except that isn’t what happens. I take a bunch of photos. At the end of the day I manually upload them all to my blog. Manually. What an annoying thing. I can’t do the one thing I want, which is make a gallery post. By default Pressgram 2 publishes my posts, so I have to use a plugin to not do that. Or I can use a plugin to import from Instagram (though again, it’s a single post per image). Of note, people recommended Instagrate to me, but it’s not Multisite compatible (says so on the plugin page) and that means it’s either poorly written or it’s doing something really wrong, since Multisite shouldn’t matter at all for that. Also it’s manual.

    The best plugin I found was one that daily pulls in my Instagram pictures and saves them as draft, leaving me to manually merge and make a “This week in Instagram” gallery. There was another that can make a weekly post, but it’s old, out of date, and doesn’t actually save as draft anymore. There’s not really a perfect way to do that, though, as even the ‘import on demand’ plugins seem to have gaffs and time delays. Obviously Pressgram’s ‘Post direct’ method is going to be more precise, but even then it doesn’t have a ‘collect everything from a week’ if it’s going that.

    I know I said the Honeymoon is over, but to be honest, I don’t know that it was ever here to begin with.

  • Why Can’t Multisite…

    Why Can’t Multisite…

    Many times people complain that WordPress isn’t ‘complete’ because it doesn’t have the features they feel are indispensable. While explaining, and educating, to people that they can’t always get what they want out of core is often fruitless, the point remains that WordPress cannot, and should not, do everything. That’s a part of a longer post, but once you are willing to accept the fact that WordPress will never be everything to everyone, we can move forward.

    There are practical reasons why Multisite doesn’t do everything people envision, and there are also some weird impractical reasons. Sometimes the answer to this is a very simple one, sometimes it’s confusing, and sometimes it’s technical. But there are reasons, even though we don’t like them, and over time they change or go away as issues are resolved.

    Here’s a list of the common questions I get and their answers.

    Why can’t I manage everything about all sites from the network admin?

    Mailbox FaceIt would slow your site down. You’ve probably heard me say something like “WordPress Multisite was intended to be multiple separate sites managed by one install of the WordPress files.” When I say that, I don’t mean ‘managed’ the way some people envision managed. When I say ‘managed’ what I mean is “You manage your network settings from the network dashboard, and you manage your per-site settings from the per-site dashboard.”

    Not every site has the same settings, anyway. The point being, if WP had to query every site for every setting (like all your comments), it would get really really slow when you have 11k comments on your blogs. And you’d be mad.

    Why can’t I set all defaults from the network?

    Oh you want them to be all the same? I’m not sure you should be using Multisite, but since you are, this one is annoying.

    In normal WordPress, you shove everything into wp_options and call it a day. On Multisite you have an options table per site, so wp_2_options and so on, but you also have wp_sitemeta. Some settings and plugins have been coded in a way to fall back, so it grabs defaults from that table. But. Not everything has been, because there’s a tacit assumption they don’t need to be.

    Now there are plugins that will let you force in defaults on new site creation, but given that every single site admin can go in and change them, it would defeat the point. They’ll just change them! Thankfully, it’s a growing trend for plugins to include a Network Admin Settings page, where you can determine how to control things for your network. But that’s only going to be for things like caching and probably Jetpack. Not ecommerce. Yet.

    Why can’t I share media?

    Because media is content and content is per-site.

    There’s a plugin called Network Shared Media which purports to being able to do this, but by it’s nature, content is sacrosanct and separate.

    Tennis Only

    Why are usernames using characters like – . _ are not allowed?

    Because they’re not permitted in subdomain URLs and since the blog URL is generated from your login name, it’s not allowed. The site admin can do it from the back end, though. This is highly imperfect, and perhaps should be changed (so maybe we could also have less than four characters in a name, which not even an admin can fix). The logic to do the detection would be a pill though, and you’d still want to do it on things like a mapped domain.

    Why can’t I just map a domain!?

    That’s being worked on. Eventually WP will have that superpower.

    Actually that brings me to the biggest reason why Multisite can’t… It’s not that it can’t, it’s that it probably shouldn’t, or it will be able to do so eventually. If you consider what the original intent of Multisite was, much becomes clear. Open Source Development doesn’t move at your pace, not even if you’re Matt Mullenweg. It moves at the pace of everyone involved in the coding and testing, and it moves at the pace of their ability to innovate. That means sometimes what you want isn’t there yet because it’s not easy, or because it’s not ready, or maybe because no one agrees with you right now that it’s a priority.

    After all, sometimes we’re wrong about Open Source Developmen.

  • Very Voluminous Vagrants

    Very Voluminous Vagrants

    I finally sat down and installed Vagrant.

    Specifically I installed Varying Vagrant Vagrants. I read, like I do, and the directions were thankfully pretty clear for a change about what the prerequisites were, and I found myself with an install of Vagrant up and running within an hour. At this point I joked “Now what?”

    Vagrant is yet another tool you can use to create test websites. It’s a super-powerful command line tool one might use instead of DesktopServer or MAMP. Now, I love MAMP. While I find DesktopServer more ‘flexible’ in that I can spin up a client’s site really fast to check it, MAMP is even faster to boot when I just want to see one site and test a plugin on it, in part because I use MAMP No Password and run it on port 80 (which lets me use Multisite).

    But… Sometimes when I want to test, I want to test different configurations at once. Like I want to test on current (3.8.1) and trunk, and I probably want a Multisite Network as well. But Vagrant is way more than just a lot of different environments in one go. I mean, if that was all it was, I could edit my hosts file and make a couple extra sites in MAMP or DesktopServer and be done.

    What do you get?

    You get a lot with VVV, and if all that seems weird to you, it’s okay. The more I work on servers, the more I see a varity of weird setups and the more I want to mess with them for testing. This isn’t to say VVV is perfect. You can’t switch (easily) between PHP 5.2 and 5.3 and 5.4. There’s a whole discussion ticket on the matter.

    Vagrant makes multiple servers. Not PHP/Apache instances. Servers. They’re virtual, but let’s be honest, so is the server this site is running on. That means I can mess with the server, install extra features if I need to test a clash with PHP version or add ons or whatever, I can do so without blowing up my laptop (or a real server) pretty quickly. That means my plugins test site (on a live server) may not be needed anymore, which led me to the first actual thing I had to do with Vagrant: Make my own sites.

    My own sites!

    You get five ‘default’ sites when you use VVV:

    That’s four, I know. The fifth is “vvv.dev” which lists the other four sites. That’s pretty much what most of us need when testing. A local site, one on trunk, one using src, and one with grunt for those CSS/JS things.

    I needed more:

    Those all run stable. I though about naming them wordpress-something, but I needed the subdomains and it was easier to just make multisite.dev for that. I know what it is, and this is for me first. The way you do this is with Auto Site Setups, where Vagrant looks in your www folder and if it finds more folders with the right files, will build sites! Natually that means I made a little Github repo for this called VVV ASS. Because you’ve met me before, right?

    What do you do with it?

    Test all the things, really. Bang on plugins and code that isn’t right, make patches, and have a generally clean environment to play with. It’s also good for building on (core or plugins or themes).

    I’ve been struggling with PHP Unit Tests, as well. I understand them, but I don’t really grok them yet. While I dig the idea of unit tests, creating them is a little complicated to me. Suffice to say, I know WordPress on push day wants to unit test all the things, so I should get used to this.

    1. In terminal, navigate to your clone of the VVV repo.
    2. Run vagrant ssh to connect to the virtual machine.
    3. Run cd /srv/www/wordpress-develop and go into the folder.
    4. Run phpunit

    And there you go. What did all that do? A lot. Check out the Core Handbook on Automated Testing. Beyond that, I cannot tell you. Yet. Expect more on that later when I’ve gotten someone to explain it better.

    Do I have to use VVV?

    Nope! There’s VIP Quickstart, by Automattic (yes, that Automattic) which lets you bring up a WordPress.com-esque site. And there’s WP Vagrant which gives you more testing environments, so when you want to blow up core on PHP 5.2, you can do it easy as another vagrant up.

    Am I sold?

    Developer Ipstenu is sold. User Ipstenu still likes MAMP best. “Yes, I’ll fix your site” Ipstenu likes DesktopServer. Each has their own place. I’m so comfortable in CLI now, it’s more natural to use MAMP and VVV. DesktopServer comes in to play for me when I need to spin up a site specifically to test an existing site someone else broke.

  • Easier Control

    Easier Control

    In a WordCamp I heard a developer say something along these lines:

    “I include my own jQuery because it’s easier and I can control things.”

    The moment he said this, I clamped my mouth shut and bit my tongue. It was not the subject of this presentation, and multiple other people in the room had already pointed out that WordPress has it’s own version. Afterwards, someone remarked she saw steam coming out my ears. All I said in the room was “We reject themes and plugins from the .org repositories for including their own copies of jQuery.” and then shut up. After all, I was in the room because I wanted to learn about something I didn’t know, and that wasn’t jQuery.

    Control KnobsIt’s sad that my major takeaway from that talk is too many people sacrifice sustainability for ‘ease’ and ‘control.’

    You may think that if you force install your own jQuery, you can be sure a random upgrade of WordPress won’t break your theme. You have full control over the theme, after all. And you may think that you can make your theme or plugin faster if you compress all the JS together yourself, rather than having WordPress load a dozen separate files. Those thoughts are both true, but you’re wrong. You’re never ‘master of everything’ unless you only use WordPress core and the themes and plugins that you built. And even then, you’re still not.

    While it’s perceived as easier and faster to write code if you assume you know the truths of your website and will always be it’s master, the fact is the assumption is plain ignorant. These days, it’s rare you’re ever the sole developer of a site. You may be hired to make a theme, I’m hired to make a plugin, and someone else is titularly in charge of both of us, but probably doesn’t know a lick of code while still being the driving force behind the website. Not to mention we’re not the webmasters of the site. That may be some intern nephew of the boss, who will take over once we’re done.

    And that is exactly where using our own versions of scripts will get us into trouble.

    You’re master of your plugin, or your theme, but you’re not master of the rest of the world. Even if you’re making it on spec for someone for a specific purpose to be used on a specific site, there’s no guarantee that it’s the only time and place your code will ever be used. There’s no assurance that then 10 other plugins you tested with today will never upgrade, or that they won’t add more. If you get hit by a bus tomorrow, there’s no promise your code will remain untouched. Basically we’re running on pure arrogance that not only are we crystal clear about the present, but we’re totally perfect about knowing the future. And that just ain’t possible.

    old men hitting each otherSo. How do I explain why including your own jQuery in a theme or plugin, instead of enqueuing the one with WP, is bad?

    “Picture this. Your theme has jQuery 2.0. So it de-enqueues WPs and re-enqueues yours. My plugin is using version 1.7. I do the same thing. Bob’s plugin uses 1.11, HE does the same thing. Joanne over there properly uses WP’s. Which one of our jQuery files wins?”

    The problem is that you’re emphasizing short term gains (speed of development, speed of site) over long term sustainability (regression conflicts, duplicate files). You’re making your life a little easier, and actually harming the website you’re trying to make because tomorrow, you will be gone and they’ll be trying to figure out why the site is so slow. Or why it’s breaking when they upgrade Jetpack. After all, you tested with Jetpack, right? You were selfish, short sighted, and just … wrong.

    But it’s okay. You can learn to do things better. You can do it right with your code and fix those mistakes. You can let the wookie win, and let WP control what it’s supposed to control, while only augmenting what you must control. And you can do it all in a friendly, sustainable, updatable, extendable way. Which is how WP wants it.

    Should I use my own jquery flowchart?

    Oh and how to I handle minification? I have a proxy service do it for me. In my case, Google’s mod_Pagespeed compresses and combines all my JS and CSS to make it one file that loads faster.