Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: essay

  • Owning My Data

    Owning My Data

    This post is dedicated to Aaron Jorbin, who donated to help me get to WCSF. Aaron knows that haters gone hate and never lets that stop him. Also: We’ll always have schwarma.

    BricksThere is a reason people call me a Tin Foil Hat. First, I do have a small tinfoil square in my hat (as a joke) but also I have a ‘thing’ about owning my own data, which in turn has surprisingly helped my ‘SEO’ and ‘brand’ over the years.

    While I often cross post links to my content on other sites like Twitter, Tumblr, Facebook, Livejournal and Google, my content primarily lives on my sites. I link back and share some content, but the content is mine and it lives with me on my sites that I pay for, maintain, and support. I really like to be in charge of my data and how it behaves. That’s why I crafted my own mailing list from WordPress and RSS2email, why I use Yourls, and pretty much why the only data I ever outsource is analytics, even though I could use my own.

    Analytics is funny. I have a lot of tools on my server, but frankly they suck. If someone open sourced GA and I could install it on my server, I’d probably use that. I’ve used all the locally installed Analytics tools, and just never really been fond of the interface. Right now, I have GA on my sites and it’s actually the only Google interface I use, save ‘Webmasters’ which is just there in case I get blacklisted.

    You see, I don’t trust Google. I don’t like how they, like Facebook, take all your data. I don’t like their ads which screwed me over big time last year, and I switched to Project Wonderful. I make less money, but I get to approve my ads. Google Ads hit me hard when I said I didn’t want any religious ads on my site. Suddenly my profit went from $60-100 a month to $10-20(For what it’s worth, I make the same money now on Project Wonderful and feel better about the ads.). The point of this is, the larger a company gets, the more funny rules and regulations they end up following. If you read Jane Well’s ‘A Tale of Two Brothers’ and how it relates to construction and development, basically Google started as Brother , and are now Brother . There’s a time and a place for both brothers, sometimes in the same project. And with each brother, you have a comfort level. Some people love flying by the seat of their pants. Others prefer to have a plan. Some of us just want to wear a hat. This comes into play, for me, when I consider my personal data and content.

    One of the schools of thought is that social media is for being social, and your website is for complex, static, content. There is a lot of line blurring these days that didn’t exist back when we just posted on our blogs and replied to comments. Now we can leave comments, or tweet, or share, or a hundred other ways to push our information out there. We have options on how to communicate with our readers. How many of us end up responding to comments on Facebook and Twitter, as well as our blogs? It’s nearly at a point of information overload, and we don’t know where to post this content. There’s clearly a need to balance out your brand promotion and your brand. Will you be diluting your brand by posting all over the place? How do you drive the readers back to your site, engage them, and keep them coming back for more?

    This is where you need to own your data.

    Obviously it’s a good thing to post to Twitter and Facebook and Google+. These are avenues to connect with people, but you need to follow up on them. Recently I had an odd experience with hotels, where a handful tweeted me, asked for contact info to help me with ‘deals’ and never followed up, except for one, who did email me, and got me a great rate, $40 off their normal ‘low’ rate. Guess which hotel I’ll be using? What made this odder was that they said I could get better rates at their website than at places like Kayak or Orbitz. We all know the pain of a hotel is finding one and comparing prices, right? Travelocity and Orbitz said $167, Kayak said $199. I ended up getting $167 but through the company’s website directly. They cleverly both played the system (getting two of the three sites to show accurate prices) and offering the same deal on theirs. By owning their data and content, and letting these other sites feed into their site, they’ve won. They communicated, they contacted, and they put up accurate information that led me back to their site where, indeed, they made a sale (and the likelihood for a repeat visitor).

    Owning your data is controlling your presence. It’s not just remembering not to post that awesome information in just one place, it’s knowing how to ensure that your face is seen, the content is shared, and in no way does it misrepresent you. That last one is why I like to use my own short URLs, and why I dislike Facebook and Google. Think about the advertising on Facebook and Google (and now Twitter). You don’t get to say ‘Never show people ads for things I find reprehensible or scammy.’

    Weather.com Ads
    Weather.com Ads
    Personally I think the world would be better if every company said ‘No more get rich quick ads, or ‘With this one secret tip…’ or outright scams.’ Weather.com is notorious for this. Looking at the ad I screencapped, you can see things that no one in their right mind would click on. And yet these things clearly ‘sell’ or Weather.com would have scrapped them years ago. They feel the trade off between ugly, scammy ads and free content is fair, so they show the ads.

    There are times when not owning your data is alright, but generally those run towards sharing your social media and any analytics. I mentioned analytics before. It’s not just that I don’t like any of the tools I could install on my server, it’s that Google does it better. There are multiple layers I can peel through, and if you’re an analytic junkie, that’s what you want to use.

    Any time you come to a place where you have to decide between owning your own data and letting someone else be the master of your domain, I strongly lean towards self-ownership.

  • The Perception of Security

    This post is dedicated to Frederick Townes, who donated to help me get to WCSF. I use his rock ’em sock ’em W3TC plugin on this site, as it happens.

    TSA TieThe TSA is a funny thing. They make us go through all these hoops and ladders to make it look like we’re safer. They check us for weapons, they check us for bombs in our shoes, and essentially they check for everything they know about. And we call it ‘Security Theater’ because it actually doesn’t make us one inch safer.(If you’re really interested, go read Bruce Schenier‘s books. The security methods in place pre-9/11 are the ones that have caught the bad guys. None of the new stuff has.)

    At work, I have a product from a vendor that has pretty insecure passwords. I can’t make them expire, I can’t make them require special characters. In fact, you can pick a blank password if you want. There’s no security and most people use the same password (123456) because of it. It was up to me to invent something more secure, and I sat and studied the login form for the app. This was a locked down product, so hooks and actions, like we use in web apps, were unknown. But there was a hidden option, down in the bowels of an ini file, that was for ‘advanced username options.’

    Unlocking that option gave me rules for usernames, just like you’d think. But how is that going to make things safer? We already used login ids of our initials plus a number, so if I could leverage that somehow, maybe I could do something. My idea was that if the login name was always pre-filled, and uneditable, with the same ID you logged into the computer with, then in order to ‘hack’ into someone’s account, they would either need their LDAP password, or the person would leave their PC unlocked. I thought it was genius, and after some fiddling around, found how to extend the settings to allow that.

    Months later, the Auditors come around and say it’s not secure enough. We need to change the passwords more often. Even though the desktop password is the most secure of all passwords we use, and even though leaving your PC unlocked is a fireable offense, they said that since someone could gain access to your PC, the bad password was a problem. I remarked that they had a lot more to worry about in that case, and pointed out the vendor didn’t have a fix. They’re still arguing that one.

    The problem is the auditors want to be able to feel safer. They know and understand LDAP security, ergo all things must comply. It is a benchmark of safety which, in many cases, isn’t going to make things safer. If you got my LDAP password, you now have access to everything I log into at work. That isn’t safe at all, is it? It’s a single point of failure.

    Security CameraRecently, someone asked why WordPress doesn’t let you move the wp-admin folder around, and that doing so would be safer. Actually they accused WordPress of being egotistic for not letting you move the folder, and for putting meta info in the source code. But let’s not get into where they’re wrong on that end. Why doesn’t WordPress let you move wp-admin? Certainly they could put the effort into decoupling the various places where it’s hard coded, put in a define you could override, just like we do for wp-content. Then you could move it where ever and you’d be happy. I cannot speak for the developers, but looking at the code (not insurmountable, just annoying), I see it as security theater.

    Moving the wp-admin folder simply cannot make your site safer. It just can’t. Look at it logically, you still have to be able to get the folder, ergo people will still be able to figure it out. The rule of the web has always been ‘If it’s on the web, people will take it.’ Normally this applies to pictures and text, but when we extrapolate it to include source code, like for open source code, which is there for the taking, we reach a point where anyone can look at WordPress’s code and determine how to quickly figure out where the admin folder has been moved to. We have now put in extra work for a very teeny tiny benefit, that can easily be circumvented.

    But isn’t that benefit worth it? Not when you look at the costs. Computers do what we tell them to, every time, every day, repeatably. When we go in and complicate our code, we introduce more human errors. The more possibility for errors, the more likelihood that we’ve missed something. So by adding in a way to move wp-admin, we run the risk of screwing it up and making things less secure. Would you rather have the brains staring down WordPress and trying to make things actually more secure, like by preventing XSS vulnerabilities, or locking down nonces and cookies, or would you like them to make you feel better?

    Furthermore, there are the themes and plugins to consider. Now we have to update all our themes and plugins that are doing_it_wrong() in the first place, and get them to join the new world order of right. Yes, they should have done things right in the first place, but some don’t because the old way still works. What happens when they don’t update? We’ll have to leave some deprecated code in there so the old wp-admin still works and … oh. Well that didn’t do you any good, now, did it?(NB. I’m certain there is a way to do this. I just don’t care enough to verify it, as you’ll see in a moment.)

    This has everything to do with the fact that open source software is open source, and ‘hiding’ anything means it’s always going to be easily reverse un-hidden. Moving wp-admin is called ‘Security by Obscurity’ and it’s a waste of time. It’s just not effectual in the long run, it doesn’t protect anything, and the only time someone knowing my WP version or where it was installed would worry me is if I didn’t upgrade and there was a known hack on the older versions. Even then, Hackers will just try the same attack even if I’m protected (which I know from the TimThumb debacle, where my server was scanned for the file exploit – I don’t use timthumb, but they scanned me all the same).

    When you make me draw the line between where I’d want ‘my’ developers spending time, and the options are ‘feel good security’ and ‘make the damn product actually more secure’ … I think you know where I stand.

    What about you? What aspects of ‘security’ do you feel are just window dressing?

  • The Dangers of Being Uneducated

    The Dangers of Being Uneducated

    This post is dedicated to Rachel Baker, who donated to help me get to WCSF. In lieu of Coke (and a sincere promise of no heckling), thank you, Rachel.

    Like many of these posts, it started with a tweet.

    Just six months ago, a WordPress plugin named RePress, hosted by all4xs, came on the scene. This is hosted at WordPress.org, see WordPress Plugin – RePress, and at the time it showed up, I was seriously worried about it.

    The plugin itself is made of awesome. It’s a proxy service, so if you happen to live in a place where freedom of speech is an unknown quality, you can use your site to serve up pages from other domains and read them, even if they’re blocked. Essentially, instead of going directly to wikipedia.org, you go to yourdomain.com/wikipedia.org, and the content from Wikipedia is requested by your server, not your local IP, so if your ISP is blocking the content, you can still see it. If you’re visual, it’s like this:

    How RePress Works

    This relies on two important pieces to work, however. First, whereever your site is hosted has to have access to where you’re trying to get (that is, if my webhost blocked Wikipedia, this won’t work). Second, you need to know what you’re doing.

    It’s that second point that worries me to no end.

    Look, I firmly believe in freedom of information. Once something has been invented, people are going to figure it out, so giving it to the world to improve upon it is sensible. Patents are just a weird concept to me. To say ‘I invented a thing, and no one else can invent the same thing, and you can only use the thing as I’ve made it!’ just blows my mind. We need to crowdsource our intelligence, share, and improve. It’s the only way to evolve.

    But that’s besides the point. The point is I worry like you don’t know about people being uneducated as to what this plugin does. Regardless of if it’s a good idea or not, it’s a dangerous thing because it has a great deal of power.

    The Pirate BayI have a slightly selfish reason for worrying about it. I work for a company where using a proxy to get to websites they’ve blocked is grounds for being fired. I’m not the only person who has this concern. The worst part about this is if I went to a site that used a proxy, without telling me, I could get ‘caught’ and fired. Oh sure, I could argue ‘I didn’t know!’ but the fact remains that my job is in jeopardy. This is part of why I hate short-links I can’t trace back. A proxy being ‘right’ or ‘wrong’ doesn’t matter, what matters is the contract I signed that says I will not circumvent the office firewall knowingly. Now I have to be even more careful with every link I click, but the uneducated who don’t know anything about this are at a huge risk.

    As Otto would say, we worry about the evil people, the ones who use this proxy to send you to virus infected sites, or places they could hack you. I really don’t worry about them very much. Evil is evil, and people are always going to be malicious. They know what these plugins do and how to use them, so again, my fear is for the uneducated who don’t understand. The people who still open those attachments from usps.com are the people who will be hurt by this. The rest of us will just deal with ‘You work on computers? Mine’s acting funny, can you look at it?’

    My main fear is for the people who don’t really understand how the plugin is dangerous to have on their own site. RePress, in order to prove that their plugin worked, hosted a proxy to The Pirate Bay, a popular torrent site. Near the end of June, BREIN told them to remove the proxy to The Pirate Bay. BREIN, to those of you who are wondering who they are, is the RIAA of the Netherlands. Essentially they’re a Dutch anti-piracy group, and they think that the proxy service to Pirate Bay is breaking the law. It may be. Greenhost, the hosting company behind RePress, and their webhost, is in the Netherlands, and it does fall under that law.(It’s nearly impossible to keep up with all this, but Wikipedia has a nice list of everyone who’s blocking The Pirate Bay, and their status. That’s a real Wikipedia link. In the US, so far only Facebook and Microsoft will edit your links to The Pirate Bay, and only on their services.) As of July 9th, all4xs/Greenhost lost the argument. A court order came in and now there is no more hosting on their site.

    It’s important to understand this Court order only impacts the proxies at Greenhost. There is no action against the plugin itself, and none at any other website using it.

    So why does it worry me?

    Screaming UserI do a lot of forum support, and I can easily envision people getting cease-and-desist orders from the Courts, telling them to remove their proxies. I can see webhosts shutting down sites because they don’t want to deal with the hassle, or because their servers happen to be located in a country where the site being proxied is blocked. And without any effort at all, I can see the users, who don’t understand the risk they’re getting into by running this proxy, screaming their heads off and blaming WordPress because they are uneducated. They’re not stupid, and they’re not evil, they just don’t see the big picture.

    It’s like when I had little sympathy for Blogetery, when it was shut down in June of 2010. They were running an open, unchecked, Multisite, and allowed anyone in the world to make a site, and didn’t monitor their users. Thus, after multiple copyvio issues, and now a terrorism claim, Blogetery’s webhost decided enough was enough and shut them down, impacting around 14,000 people (give or take, I wasn’t able to get the number of splogs on that site sorted out). The point there is that Blogetery screwed up by not taking care of their site. It’s your responsibility to do that, and the less people know about what they’re doing, the more likely they are to screw up.

    I’d be a lot happier if RePress’s plugin page explained the risks. Until they do, I give you my own:

    RePress will let your server to act as a proxy to any website you chose, allowing visitors who would be otherwise blocked by their country or ISP to visit those sites. Please investigate the laws of your country, as well as those of your webhosting company, to ensure you are not violating them. Also remember to review the terms of use for your webhost, and do not provide proxy service to any site (or type of site) that you aren’t permitted to host yourself. If your hosting company doesn’t permit porn, don’t proxy a porn site. While this plugin makes every effort to prevent cross-site scripting, you are expected to monitor the sites you proxy and be aware of their intention. Remember: If you put it on your server, you are responsible for what it does.

    (If RePress wants to copy that and use it as is, or edit it, they have my permission to do so. And they don’t even need to credit me if they don’t want to.)

  • 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.