Half-Elf on Tech

Thoughts From a Professional Lesbian

Category: How It Is

Making philosophy about the why behind technical things.

  • On The Segregation of Code

    On The Segregation of Code

    WordPress stores your URLs in the database as the full URL. That is to say all the links to other pages on your site, all the images, use the full path.

    When I changed this site from tech.ipstenu.org to halfelf.org, I knew that meant I’d need to do a quick search/replace in the database. That meant first I searched wp_2_posts for everything saying tech.ipstenu and replaced it with halfelf. Then I did the same in wp_posts (since I knew I’d done some of that). I did this directly in SQL because I can, and I believe in using the right tool for the job. To whit:

    UPDATE wp_2_posts SET post_content = REPLACE (
post_content,
'tech.ipstenu',
'halfelf');

    That code searched all my posts and changed the URLs so my images looked right. Now, since I’m using a domain mapping plugin, I don’t need to go in and change wp_blogs, which I would be very hesitant to do anyway. I’d sooner make a new site with the same name (either manually or via a replicator), delete the old one, and use .htaccess to redirect.

    Why would I do all this? Well, because WordPress stores URLs in a non-relative way. The link to my about page is https://halfelf.org/about, not just /about, and that screams in the face of what I learned back when we all agreed that paying for Netscape as a browser wasn’t a terrible idea.

    The real question people are asking is why are we this way?

    There are a lot of arguments, one is that you shouldn’t change your URLs. Another is that WP is written for the user, not the developer. A third is that you’re trying to force your process on a tool, when you should really develop the process for the tool. That third argument is where I live. I believe in being adaptable, while I want all my code to be flexible, adaptable and fluid, there’s a time and place for the flexibility being the code, and the flexibility being me. In the case of URLs, I think the flexibility must be mine.

    In the ‘real’ world, you should never change your URLs, and if you do you always have the old ones forwarding to the new ones. Go on, go to http://tech.ipstenu.org/about/ and where do you end up? That’s because the plugin works. Go to http://code.ipstenu.org/about/ or even http://ebooks.ipstenu.org/ and see what happens. That’s because I forward those (obvious) URLs to where they should be. I know that people can adapt to change, but I can help with them a well crafted .htaccess rule. That’s flexibility in my code.

    When we take another step back and consider the flexibility of code, we muddle that up quite nicely with the flexibility of content. These are different things. Code should be flexible and adapt to any situation you put it in, but you need to be flexible to adapt your content to the situation. Content cannot be considered in the same breath as code, because they are segregated by their very nature. We should be able to pick up our content and plunk it down in any code, and have it work equally well. This argument was fought, and won, by CSS back in the day. So how does this work with URLs? They’re in my content as links, and if I change them, I have to change my content.

    Let’s take the example of building a site locally. Personally, I use a hosts file to make halfelf.loc so that when I’m done building it all out, I export the DB, replace halfelf.loc with halfelf.org, and I’m done. Why do I pick halfelf.loc? If you’ve been here before, you may remember I wrote about Moving Multisite. In there I mention serialization. That’s why. Searching for domain.loc and replacing with domain.org will not break serialization! This is, some claim, a ‘bush league’ maneuver (yes, zamoose, I heard you), but have you ever tried to move an application on your desktop to a new location? You have something installed in Program Files, let’s say, and you want to move that to Program Files/Half Elf? Congratulations, you get to search the whole registry!

    See, it’s not just WordPress. This isn’t an excuse, but a statement of fact. Many applications on the web don’t use relative paths, and they do force you to search/replace things to move to a new location. This is especially the case when you think about how we write links. Some people use the link interface, which if used, could insert variables for ‘base path.’ But some of us use the old fashioned manual way, and now you have to code a really fancy bit to check “Did Ipstenu post a link to myself? If so, I need to change halfelf.org/foobar into [basepath]/foobar so I can update it later if I move.” Certainly it can be done, but it’s actually going to be easier to just search/replace. The ‘more’ you search for, the easier it gets. I actually know someone who did this. He says it was more trouble that it’s worth.

    That really doesn’t surprise me. What all the proposed fixes to this try to do is to force WordPress into working a certain way, rather than customizing a solution. That probably sounded the same to a lot of people, but it’s not. The method by which you move static HTML files around servers is, for lack of a better term, a migration method. When you migrate an application from sys to test to production, you do so because there are a lot of moving parts to test. It’s in these moves that we face headaches with the relative path locations. When we hard code locations into our content, like in a URL, we lock ourselves into that URL, now and forever. But does the content actually matter?

    For me, the real question is ‘What moving parts of WordPress might I be testing that I would need to ‘push’ to my production site?’ I came up with three things:

    • Themes
    • Plugins
    • Content

    I ‘push’ themes and plugins out to a test server and then my production server all the time. I do it for hundreds of different applications a day, and it’s all automated. We never have a problem (unless the code is bad) because we perfected our migration method, and let go of the idea of pushing our content. Our content is not our code.

    Initially, we didn’t replicate content for legal reasons. We have sample data to test with when we’re checking out theme and plugin changes, but we don’t bother with data replication. Realistically we can’t, since the people who are testing things out don’t have the security clearance to look at the content. Because of that, we have to trust that the live data is the live data, and that it’s good. Instead of sweating over the content, we concentrate on copying up, in this case, themes and plugins. Since those may have customizations, we take a snapshot of the database, install the theme, make our changes, and take a snapshot after. Get the diff, and now we know what needs to be applied up. Then we script it. The job will FTP up the files, run the SQL diff (which we’ve already edited for the new domain name if needed, but rarely since we use hosts to point at our dev server instead), and off we go. Same thing for plugins.

    If I apply this to WordPress, suddenly I have but one, minor, headache in moving my code, and that’s the wp_options table, and it’s serialization which includes the URL. I agree, that’s a headache and if I was going to put paid effort to fixing anything about relative URLs, that would be it.

    But I don’t think that URLs for WordPress should be non-relative. Given the alternatives and the possibilities, right now the issue isn’t that WordPress stores the like that, but that we don’t have a migration ‘process’ defined yet. We should stop getting hung up on ‘fixing’ what isn’t broke, and instead start looking at the best ways to move what needs moving. See, once we found we couldn’t replicate our content, we started looking into what needed to be done to protect it, outside of ‘migrations.’ In WordPress, today, the best way is to have your writers submit their posts, and your editors review and publish. You may want to look into groupflow plugins, or do what the Bangor Daily News did.

    The right tool for the write job.(Pun intended.) Moving your content between testing and live servers isn’t needed. Just concentrate on moving the ‘app’ as it were. It’ll work better.

  • You Can’t Be Everything

    You Can’t Be Everything

    There’s no app out there that does everything.

    A lot of you just said ‘I know.’ but did you ever stop to think about why that’s the case? After all, some applications do everything you need them to do, and some you don’t, so who gets to decide what is and isn’t needed? When I talked about how WordPress was just fine on it’s own, without any plugins, people stepped up and said “But Ipstenu, I really need XYZ.” Heck, Lorelle said she needed Akismet.

    Learning how to separate your personal needs from the needs of the masses, when writing software, is a full-time job, and many of us come at it from a slant-wise point of view. In fact, writing core code for WordPress is in diametric opposition to why we write plugins! While I’m going to talk about it from a WordPress point of view, the concept holds true to any application that has ‘add ons.’

    Plugins are written, by in large, to solve a specific problem. They’re not ‘fixing’ WordPress, they’re expanding. Remember, your iPhone wasn’t broken until it had Angry Birds, nor was your iPad incomplete without Twitter. Those are things you wanted, and solved a problem for you. The base tools, in and of themselves, address a broader group of people, with a diverse set of needs, and have the option of being everything or nothing.

    The best tool, WordPress, your computer, etc, are built to be extendable. They’re built with the innate knowledge that the users may want things they can’t forsee. Five years ago, how many of you thought Google+ or Twitter would be a ‘thing’?  Let’s take that further. You know how when a new video game comes out, sometimes you can’t play it on your older computer? That’s because it wasn’t built with the new game in mind, so it’s just not capable. And that’s why computers generally let you upgrade memory, CPU, and hard drives. They are built to be extendable becuase they know they can’t know the future.

    Bringing it back to WordPress, it was built to meet a need. People wanted to blog, they wanted it to be easy and they wanted it to just bloody work! So the Matts said ‘This is what we want’ and built it. Thankfully, they understood that people wanted to extend WordPress. But not at first. Oh you didn’t know? Back in December 2003, a ‘new feature’ was introduced called my-hacks.php, which let you put a file by that name in the root of WP, and it would treat it like a functions file. In fact, that’s why I call my non-plugin code ‘hacks.’ Heck, we didn’t get pretty permalinks until January 2004 (then called ‘cruft free’ URLs).

    The point of this is not to expose the funny looking beginnings, but to demonstrate the nature of the software. As it grew, people had needs, and instead of writing everything into core, they cleverly changed WordPress so it was extendable and let people grow as they needed. So when we talk about things like needs and wants, we do it in the understanding that we write our software to fill a need, and we make add-ons to fill wants. Sounds like double speak, I know, but that’s why I said plugins and core development are in direct opposition.

    When I want to add things to core, I want them to be useful to everyone, so I’m forced to remove my ego from the equation. Looking at the (few) core submissions I’ve made, I carefully thought them out beforehand. I looked at places were the user experience was inconsistent or diminished. When I make suggestions or offer commentary to what I think could be better, I try to show my passion without acting like a teenager’s first big crush, or a screaming fangirl meeting her heroes.

    This isn’t to say I don’t think passion is a part of the driving force of any product, but that it must be tempered and controlled in things like WordPress core. We know that we can’t make WordPress core do everything, and we know we shouldn’t. When things are extendable, we utilize that and demonstrate our fire. When they’re difficult to extend, or kludgy to implement, we come back and say ‘You know, it would be nice if we could…’ But at the end of the day, when WordPress tags your trac ticket ‘wontfix,’ it’s because they know, being unable to be all things, that they must limit the things they are.

    If you haven’t yet, take the time to read WordPress’s Philosophy.

    Aaron Jorbin - Haters Gonna HateWhen I usually talk about divorcing my ego from a project, what I mean is that I don’t let my passion cloud my better judgement. One of the lessons I’ve learned in nearly 20 years of active fandom is that when you love something, you get fired up about it, and you tend to view peoples opinions and actions as a personal attack when, in fact, they often aren’t. Yes, there are idiots and trolls and people who hate-monger, but in general, people actually aren’t dicks. They’re selfish and self-centered, but that’s just human nature. Part of designing a project means you have to let go of your personal attachment to your baby, and understand that haters are just gonna hate, and there’s nothing you can do about it.

    This also applies to using a tool, though. People mock the evangelists, and we all hate the extremists, and certainly no one actually supports those who are outright malicious. But all those archtypes come part and parcel with a system, and are all aspects of the simple problem that no one product can do all the things. We want things to be a silver bullet, to fix everything we, personally, have a problem with, and we’re totally unrealistic in wanting that.

    Mark and I were talking recently, and he pointed out that WordPress was once 230kb. It’s now 3.8megs, even zipped up. Part of this is because it all grew and became more, but if you ask the old-timers, some will complain that around the 1.5 days, WordPress just became too big. It does too much! And those people say we should pull things like the importer out of WordPress. After all, you’re going to use it once, if at all. Core plugins would get pretty big too. Jetpack is 2.4megs on its own, zipped up. By trying to be everything, maybe we’re making things a little worse.

    So the next time someone gets their panties in a bunch at you for not doing everything, tell that it’s by design. Do what you want with your code, make it easily extendable for the next guy (or forkable), and carry on. They’re not getting that unicorn.

  • Permalink Elephants

    Permalink Elephants

    Broken Link The best permalink format for your site is so simple, you’re going to wonder why you never thought of it before. It’s obvious, intuitive, and perfect. In fact, I dare say it’s genius. Want to know what it is?

    The best permalink is the one your visitors can remember.

    I told you it was obvious.

    Look, you can waste immesurable hours and days trying to determine if /postname/ is better than /2012/postname, or you can sit down and remember you’re not making a site for search engines, but for your visitors.

    SEO does have a point, don’t get me wrong. If it’s easy for people to find your site, you get more traffic. One of my sites, following the recent Panda and Penguin updates on Google, jumped from 5th place to 3rd on a search for the major keyword. Another went from 12th to 9th (we’re working on that). None of that has to do with me changing anything, or even picking the best SEO plugin. It was done the traditional way.

    1. I wrote good copy
    2. I networked with related sites for links
    3. I advertised
    4. I was memorable

    Those three things, when done correctly, are how you get your site to rank high. And it’s that last item, being memorable, that should drive your URL choices.

    A URL like http://example.com/12897342134/jkahsdu.aspx isn’t memorable. It tells me nothing of what your site’s about, what the topics are, what the subject is.

    Elephants being adorableOn the other hand, a URL like http://example.com/2011/how-to-save-elephants tells me quite a bit. I know when the post was written, so if there was a big to-do about elephants in 2011, it probably is related. But it’s not always easy to tell someone that URL, nor is it a given I’ll remember it tomorrow. I may remember that example.com had a cool posts about saving elephants,  however. It’s certainly more likely I’ll remember it than the other link!

    This is where WordPress does something cool, though. See, I can tell someone to go to http://example.com/how-to-save-elephants/ and that will redirect them to the right URL! You can do this on Drupal as well with a module called Global Redirect (Drupal folks, correct me if I’m wrong/there’s a better one).

    To me, that says the issue isn’t what permalink pattern you pick, but what permalink slug you use! On that train of thought, what if I made my URL http://example.com/2011/save-elephants instead? Naturally then http://example.com/save-elephants  would also work.

    Now we can clearly see that ultimate issue is not the permalink structure. The only thing I don’t like about how WordPress defaults URLs is that I have to tell people ‘it’s example dot com slash save dash elephants’ and that’s not as easy as ‘example dot com slash elephants.’ Or even ‘saveelephants, all one word’ (I don’t know why that’s easier, but people tell me it is).

    The whole reason people like short URLs is that they’re short and easier to remember. If I told you to get to a site you used http://bit.ly/elephant, you’d have a much higher likelihood of remembering. Invariably, however, we look at branding and think “I don’t want bit.ly to have my name.” That’s a case for Yourls, and now, as long as you customize all your Yourls, you’re in it to win it. I know most people use short URLs for Twitter and such, but I find that making a handy short URL to tell someone ‘go to foo dot in slash facebook’ works astonishingly well. Of course Facebook knows that too, and lets you use http://fb.com/username to find people.(I don’t have a yourls setup here because I’m incapable of finding a short URL I like.)

    Sadly, there is one problem with this, and it’s that you can only use each ‘slug’ once, so once you’ve use ‘elephant’ you’re never able to use it again.

    Name your slugs wisely and plan, as best you can, for the future.

  • WordPress 3.4 – No Problem

    WordPress 3.4 – No Problem

    It’s in beta, don’t nobody panic.

    The last 3 releases of WP, I’ve made troubleshooting posts about what to do, what plugins are going to barf, and so on. This time, there really doesn’t seem as much to worry about. Of course, having said that, everything will die in a fire. Actually, though, I haven’t made a list of things yet, because there’s nothing to list. I’ve not run into any stand out ‘Oh shits!’ and the forums are remarkably quiet. So. If you’ve got stupid problems, or found you have to edit themes/plugins, please reply and let me know! I’ll get on it.

    So here’s some of the cool new stuff:

    Akismet 2.5.6

    Custom Headers and Backgrounds — See also Flexible Headers in 3.4 Themes and Backwards Compatibility for WP 3.4 Headers and Backgrounds

    Twitter was added to oEmbeds — This should just work out of the box, but if you have a plugin (like Blackbird Pie), you may want to disable it before upgrading.

    RPC-XML support for Custom Post-Types.

    Admin Toolbar To The Top! Click on any blank space in the admin bar and you go to the top of the page. (It’s the toolbar, damn it, I know this!)

    Sexier Theme Options. Have you ever wanted to see what the changes did to your theme on the fly? Go to WP Admin > Themes and click on Customize Theme to get a quick way to see what you’re tweaking. Not every option is there, nor will every option be added, but this is pretty nice!
    Theme Options

    You also get that view when you preview a theme.

    Of note, Twenty Twelve and Favicons got punted to 3.5.

    Edited to add…

    Jane Wells has a nice write up of some of the new stuff. It’s on .com, but a lot of this (all) is on 3.4 too. What? You didn’t know .com used the same (mostly) WordPress we do?

  • Storify oEmbed

    Storify oEmbed

    Of note, this no longer appears to work. It’s been almost 2 years. Not shocked. Embedly has a plugin though. http://wordpress.org/plugins/embedly/

    I was reviewing a plugin that went the long way around for this (similar to how things work on my Rickroll plugin, with a search/replace).

    You would think this is easier:

    // Add Storify oEmbed
function add_oembed_storify(){
    wp_oembed_add_provider( 'http://storify.com/*', 'http://api.storify.com/v1/stories/');
}
add_action('init','add_oembed_storify');

    But even though there’s a nice API, it won’t work. Why not? Because Storify doesn’t have it’s own oembed provider. Boo. Instead you have to use something like embed.ly

    wp_oembed_add_provider( 'http://storify.com/*', 'http://api.embed.ly/1/oembed?url=http://storify.com/');

    Then you put http://storify.com/dailydot/betty-white-joins-twitter in your post and it shows a story.

    Example:

    http://storify.com/dailydot/betty-white-joins-twitter

  • Lesson #1373 – Learning

    Lesson #1373 – Learning

    All the help I give on all the forums and various places works using this maze. I can tell you, but then you won’t learn anything.

    Lesson #1373 - Learning (Surviving The World)

    There’s more than one path to knowledge; it’s not always the same knowledge once you get there, either. But if you think it was easy to get there, you’re not at the destination you think you’re at.

    Credit: Surviving the World