Author: Ipstenu (Mika Epstein)

Software Freedoms

Like a million other posts, I’m starting this with a warning: I Am Not A Lawyer. Sure, my mom is, but that qualifies me for a cup of coffee, if I have the cash. Personally, I support open-data and open-code because I think it makes things better, but there are a lot of weird issues when you try and pair up software licenses, explain what ‘freedom’ means, and where it’s applicable. For the record, I am not getting into the ‘is a plugin/theme derivative software or not’ debate. I will wiggle my toe and point out it is a point of contention.

I’m presuming you are already familiar with the idea of what GPL is. If not, read the GPL FAQ.

Why are WordPress and Drupal GPL anyway?

The people who built WordPress took an existing app (b2) and forked it. Forking happens when developers take a legally acquired copy of some code and make a new program out of it. Of the myriad caveats in forking, you have to remember that the fork must be a legal copy of the code. In order to create WordPress, Matt et al. were legally obligated to make WordPress GPL. No one argues that. The only way to change a license from GPL is to get everyone who has ever committed any code to the project to agree to this, and you know, that’s like saying you’re going to get everyone in your house to agree to what pizza to order.

WordPress and Drupal is GPL because it must be. There is no other option.

So why is this a problem?

GPL poses a problem because of interpretations of what ‘derivative works’ are. It’s very clear cut that if you take or use WordPress’ or Drupal’s code, you are taking code built on GPL, which means you must keep your code GPL. The definition of ‘code’ is a bit squidgy. A generally accepted rule of thumb is that if your code can exist, 100%, without WordPress or Drupal’s support, then it’s not a derivative. By their very nature, plugins and modules are seen as derivative. Both Drupal and WordPress have long since stated that this is, indeed, the case.

Themes, modules and plugins are GPL because they must be. There is no other option.

Except…

Except there is. Only the code that relies on the GPL code have to be GPL. Your theme’s CSS and your images actually can be non-GPL (though WordPress won’t host you on their site if you don’t). Also, if you have code that lives on your own server, and people use the plugin to help the app talk to that code, only the code that sits on WordPress or Drupal has to be GPL. Your server’s code? No problem, it can be as proprietary as you want! Akismet, a product made by Automattic (who ‘makes’ WordPress, in a really broad interpretation) works like this. So does Google Analytics (most certainly not owned by WordPress), and there are many plugins to integrate WordPress and Google. This is generally done by APIs (aka Application programing interfaces), and are totally kosher to be as proprietary as you want.

Themes, modules and plugins are GPL where they need to be, and proprietary (if you want) where they don’t.

So what is GPL protecting?

As we often carol, the GPL is about freedom. And “free software” is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech,” not as in “free beer.” Freedom is a tetchy subject, misunderstood by most of us. For example, freedom of speech does not mean you get to run around saying what you want wherever you want. Free software is a matter of the users’ freedom to run, copy, distribute, study, change and improve the software. This is pretty much the opposite of what you’re used to with the iOS, Microsoft and Adobe. Free software may still charge you, but once you buy the software, you can do what you want with it. Your freedom, as a user, is protected.

WordPress’s adherence to GPL is for the user, not the developer.

What’s so free about this anyway?

The term ‘free’ is just a bad one to use in general. Remember, freedom of speech, as it’s so often used in inaccurate Internet debates, does not mean you can say whatever you want. ‘Free speech’ means ‘You have the right to say what you want, but I have the right to kick you out of MY house if I don’t like it.’ So what are these GPL freedoms anyway? In the GPL license you have the four freedoms: (1) to run the software, (2) to have the source code, (3) to distribute the software, (4) to distribute your modifications to the software. Really they should be ‘rights’ and not ‘freedoms’ if you want nit-pick, and I tend to think of the freedom of source code to be similar to data freedom. The freedoms of open-whatever are for the people who use the whatever, not those who come up with it.

Software freedoms are for the user to become the developer.

So if GPL is for the users, what protects the developer?

Not much, and this is where people get pissed off. If anyone can buy my software and give it away for free (or pay), why would I even consider releasing something GPL? The question, as Otto puts it, really should be ‘What exactly are you selling in the first place?’ What are we selling when we sell software? I work on software for a living, and I never sell my code. I’m hired to write it, certainly, and I do (not as often as I’d like). Most of what I do is design. It’s part math, and part art. My contract doesn’t allow me to keep ownership of my art, which sucks, but if I was a painter, I’d sell the painting and lose the ownership anyway, so what’s the difference? That painting can get sold and resold millions of times for billions of dollars. And most artists die starving.

Software Freedom doesn’t stop people from being dicks (though they should).

So what good is the GPL to the developer trying to make a buck?

It’s not. But that’s not the point. GPL isn’t about the guy who wrote the code, it’s about the guy who gets the code (again, legally) and says “You know, this is great, but it should make milkshakes too!” and writes that. GPL is all about the guy who uses the code and the next guy who takes the code and improves on it. If you have an open community where everyone has the privilege and right to use, view, share and edit the code, then you have the ability to let your code grow organically. If you want to watch some staid, tie-wearing, Dilbert PHB lose his mind, try and explain the shenanigans of Open Source development. “Develop at the pace of ingenuity” versus “Develop at the pace of your whining users.”

Software Freedom isn’t about making money, it’s about making the next thing.

Why would I want to use GPL?

If you use WordPress, you use it because you have to. I prefer the Apache licenses, myself, but the purpose of using any software freedom license is, at it’s Communist best, a way to make software all around the world better for everyone. You stop people from reinventing the wheel if you show them how to make the axle in the first place! Did you know that Ford and Toyota independently came up with a way to make your brakes charge your hybrid battery? They latter opened up and shared their tech with each other, only to find out how similar they already were! Just imagine how much faster we could have had new technology if they’d collaborated earlier on? With an open-source/free license, my code is there for anyone to say “You know, this would work better…” And they have! And I’ve made my code better thanks to them.

I use ‘free software’ open source licensing on my software to make my software better.

28 March, 2011
Obfuscation Obtuseness

I’m not getting into the ethics of free vs pay and theft or any of that. Comments on that matter will be deleted on sight.

Earlier in the year I remarked on how right-click protection doesn’t work. Right-click disabling is a form of obfuscation protection. By hiding the normal methods to perform actions, you are ‘protected.’ You’re not. I told you so then, and I tell you now. If it’s on the internet, it can and will get ‘stolen.’

Pretty recently I got into a ‘tiff’ with the guy who wrote a WordPress plugin to disable right click. A user had a problem and bitched (generically). I told him that the plugin worked well for what it was, but that disabling doesn’t really do much. The plugin author accused me of trolling (incorrect, I was attempted to start a conversation with the user to sort out why he needed the plugin, and to then help determine a solution – which is my volunteer job). Of course, that meant I wanted to see how this guy’s product worked. I went and grabbed WP Protect and determined that you can block right-click, image drag and text selection. He doesn’t block CTRL-A, though, so I could easily select all and move on. (Actually you CAN block ctrl-A, per Disable ctrl + n and other ctrl + key combinations in JavaScript, but remember that on a Mac it’s Apple-A and you have to take all that into consideration.)

My point remains valid that the technical code for doing these things is not complete, doesn’t work for all situations, and puts a burden on you. And it doesn’t work! If you printed up a newspaper, it’s easy for people to copy your work. We have a copy machine, a scanner, and scissors. If you send out a DVD, we can rip it at home and pass it around to our friends (which is legal actually, so long as you’re not selling it as your own work – see mix tapes, yo). Why is stopping copying bad for your users? If I want to send someone a link to your article, there are two things I want to do. First, I copy your URL. Second I want to copy your title (and maybe an excerpt to illustrate a point). By killing right click, you made it a royal pain to SHARE your work. And if you’re online, you want people to share. The same goes with DVDs, mix tapes etc. Sharing is how we tell people “I really like this!” You’ve shot that down and will lose customers.

Apropos of all this, the New York Times decided they needed to charge for media. This makes sense, as they charge for a newspaper. I have no objection to paying for media (traditional or not) at all. What did The NYT do? They put up a paywall. You now have to pay to get in. Kind of.

Come March 28, you’ll only be able to read 20 articles per month for free. After that, you’ll need a digital subscription, which costs $3.75 per week for Web and mobile phone access, $5 per week for Web and tablet access and $8.75 per week for access on the web, phones, tablets, TimesReader and the Chrome Web app. Print subscribers get all this stuff at no extra charge. (New York Times Paywall: A Small Change That Seems Big – By Jared Newman, PCWorld Mar 17, 2011 12:00 PM)

And then there’s a catch. If you go to their site via Google, Facebook or Twitter, it’s ‘free’.

Essentially, the New York Times doesn’t want to charge you for its content. It wants to charge you for the delivery mechanism, whether it’s through the Website, the iPhone app, the tablet app or the TimesReader software. That’s the best approach, because content is abundant on the Internet. An elegant tablet app is worth more than the individual stories within.

The problem for the Times, and the reason a lot of people should shrug off the paywall, is that people don’t necessarily need major media gatekeepers to provide the delivery mechanism. A recent study by Pew Internet found that 75 percent of people who find news online get it through e-mail or social networks. (Here’s a fitting anecdote: a friend alerted me to the Times’ paywall announcement by e-mail.) (New York Times Paywall: A Small Change That Seems Big – By Jared Newman, PCWorld Mar 17, 2011 12:00 PM)

Not to mention that you can overcome the technical aspects of their wall pretty easily. The Times built their paywall with some simple Javascript, which can be tweaked pretty fast. And it cost them $40 million. (New Media Barbarians Breach New York Times Paywall in Hours – By Erik Sherman | March 22, 2011)

What the NYT is learning pretty quickly is that hiding your content, or putting up barriers, isn’t effective. Nor will their plan succeed because of the same reason we still have people out there who can crack your DVD and DVD players. If you build it, we can unbuild it and share it and there you go. If you don’t want people to read your articles for free, you stop putting them online. That’s it. If you email me an article, I can email it to my friends (copy & paste) after all.

I hate to say it, but once it’s out there, it’s done. Hiding it doesn’t help, because you either chase people off who can’t find it (and who would have paid) or you make people smarter who steal it (and they wouldn’t have paid anyway). We need a culture shift to make this all ‘profitable’ as well as something the end users are willing to pay for. We’re not there yet. I’m not entirely sure we’re all that different from where we were when I was in high school, though. The only major change is how easy it is to find the information to steal. That’s why I think the problem isn’t the technology, but the mentality.

It’s hard to see a future where we can run a business like a newspaper, make it profitable, and convince people to pay for it. Yes, part of this is our own fault for providing information for free all this time, but the other part is the abject denial that this was an issue until it was too late. I certainly cannot advocate cable TV’s method of charging, but perhaps a restructuring of sites, so you can only see domain foo.com if your ISP pays a fee to foo.com (and you can access it by telling your ISP you want to ‘see’ foo.com as well). Lifting the model wholesale strikes me as a terrible idea, but the idea of charging the provider, not the end user makes some sense.

After all, basic network TV is ‘free’ in the US, isn’t it? Well, that’s another post. The point here is that the methods we’re using now to stop ‘theft’ isn’t working. So how do you protect your intellectual property and attract readers?

28 March, 2011
Limitations on Sortable Columns
As of WordPress 3.1 you can add new columns to admin pages and sort them. You could always add them, but being able to sort the columns is new! This was very much welcome from pretty much everyone who makes extra columns, for whatever reason. As someone who likes them (they make sorting so much easier), I pinged out there to ask how it was done?

My Twitter friends bailed me on and found these very helpful links:
- Stereo Interactive & Design » Wordpress 3.1 sortable admin tables
- Create your own sortable columns by scribu
These both told you how to add columns to the posts table. But what I wanted to do was add a column to the USERS table. When you see what I wanted to add, I’m sure it’ll be obvious:
1. Show the DATE someone registered in the users menu
2. Allow the column to be sortable
Adding in the date was really painless, but I could not, for the life of me, get it to sort! Small problem. Again, I appealed to Twitter, and bless his little black heart, Otto bailed me out and explained to me why that one could work, but others would not.

What I learned

Unless your data in the header is stored in the database, you cannot sort by it. End of story. No further discussion needs to happen. This makes sense, as you cannot sort by dynamically generated content.

Unlike the wp_posts table, you cannot sort by user generated headers in the User Table because of how it draws from the database. Your plugin would have to write to the wp_users table (making new columns instead of using wp_usermeta which is prefered) and even then, the sortables are hard coded. That one broke my head a little. The sortables in the posts table are pluggable (that is, you can make your own). This just isn’t the same becuase WordPress knows what columns are in wp_users. After all, we add stuff to wp_usermeta. This created a circle of ‘Auuuuugh!’ for me.

Thankfully, Otto pointed out that since ‘registered’ is listed for MultiSite, you can leverage that on SingleSite and MultiSite (and also explained why my tweaks worked on MultiSite!).

In the end, I was able to take all that and tweak my “Recently Registered” plugin for WordPress 3.1, and made it look hella cool. If you’re using WordPress MultiSite, you don’t need this at all.
24 March, 2011

Show Site ID Columns in MultiSite

This is totally a use at your own risk sort of thing. I really have no plans to do anything with it, and no, you cannot sort by ID due to limitations in how the columns work in WordPress.

Installation Instructions
Make a file called show-site-ids.php, put this code in it, and upload to your mu-plugins folder.

<?php
/*
Plugin Name: Show Site ID
Plugin URI: https://halfelf.org/hacks/site-id-columns-multisite/
Description: Show Site ID in Sites Column for Multisite
Version: 1.0
Author: Mika 'Ipstenu' Epstein
Author URI: http://ipstenu.org/

        This plugin is free software; you can redistribute it and/or modify
        it under the terms of the GNU General Public License as published by
        the Free Software Foundation; either version 2 of the License, or
        (at your option) any later version.

        This plugin is distributed in the hope that it will be useful,
        but WITHOUT ANY WARRANTY; without even the implied warranty of
        MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
        GNU General Public License for more details.

*/

function siteid_columns($column, $blog_id) {
        global $wpdb;
        if ( $column == 'site_id' ) {
                echo $blog_id;
        }
        return $value;
}

// Add in a column header
function site_id($columns) {
    $columns&#91;'site_id'&#93; = __('ID', 'site_id');
    return $columns;
}

        add_filter( 'wpmu_blogs_columns', 'site_id' );
        add_action('manage_sites_custom_column',  'siteid_columns', 10, 3);
        add_action('manage_blogs_custom_column',  'siteid_columns', 10, 3);
?>

14 March, 2011

WordPress MultiSite – New Dashboards

Back in the WordPress MU and the recent WordPress Multisite 3.0.x days, we had something called a ‘Dashboard Blog.’ This was the ‘main’ site of your install, and ostensibly was the default blog to sign users up to and control them from. This was also where you, the admin, had the Super Admin menu. So what were those things for and why were they moved? After all, a lot of people will tell you they worked just fine.

The simplest answer is that it’s considered good design to separate the ‘user’ interface from the ‘admin’ interface. That’s why, when a regular user with the lowest role possible logs in to a regular (non-MultiSite) WordPress install, they see a very limited site. They see a dashboard, their profile, and that’s it. You want to keep the subscribers out of your meat and potatoes. Pursuant to that, there are plugins like WP Hide Dashboard that kick users to just their profile. I love that plugin, because it hides the man behind the curtain. If the Dashboard of WordPress is not a part of your desired experience (and really, it only is for the people who run the site), then you keep Dorothy, Toto, the Scarecrow, the Tin Man and the Cowardly Lion out, Ruby Slippers or not.

When WordPress 3.0 came out, it was a bit of a chimera. We’ve got all sorts of weird parts where we call things blogs instead of sites, and from the back end, it’s really confusing. The sad thing is we cannot declare fiat, fix it all, and move on, because that would break backwards compatibility. Did you know WordPress is backwards compatible, nearly all the way to the start of WordPress 1? (17 Reasons WordPress is a Better CMS than Drupal – Mike Schinkel, Dec 1st, 2010) In order to be able to upgrade from WordPress MU (which was a fork – i.e. a totally separate version – of WordPress), the fold-in of MU to regular WordPress was a lot of work and duplication. There are some things I’m sure the devs would have chosen to do differently in a perfect world, but they decided the headache for them was worth it because it was beneficial to the users. For that alone, I laud them and owe them beers and coffee.

One of the many drawbacks of that mentality is the users are very much used to getting what they ‘want.’ The users think ‘This worked before, it will always work, therefore, it’s cool to do it now.’ Take (not for random example) the issue with the /blog/ folder in the main site of any subfolder install. (Switching to WordPress MultiSite Breaks Links – Mika Epstein, 14 July, 2010) Back in the 3.0 days, we had a work-around to fix this, but that was a ‘bug.’ We were all taking advantage of a flaw in the system, and that flaw was plugged (mostly) in 3.1. Of course, fixing the flaw meant breaking things, and those people who were not up to speed on the dev channels (which in this instance included me) went ‘Hey, what the hell!?’ We were angry, we were upset, and then Ron told me that it was bug and I stepped down.

A lot of people are still annoyed by this, and while there is still a buggy workaround, it’s not something I would generally suggest be used for my clients (myself, yes). Then again, the original tweak wasn’t something I considered using for clients, since I was always aware that WordPress’s stated intent was to make that /blog/ slug customizable. And I hope they do.

What does this have to do with the new dashboards? It’s another change WordPress implemented to ‘fix’ things people didn’t see as broken. The people are wrong.

Now don’t get all het up, thinking I’m drinking the WordPress Kool-Aid. There’s a vast difference between being ‘WordPress is always right, WordPress can do no wrong’ and the acceptance that what WordPress did was for a good, understandable, reason. In software development, I’ve learned to distance myself from the all too personal feelings of investment in my product. Many times, the product needs to be designed in a certain way to work better for the majority of people, and many times, I am not that person. Look at JetPack. This is a fantastic plugin for people moving off WordPress.com and onto self-hosted WordPress. It has absolutely no meaning to me, and I won’t be using it. But it’s great for the target audience. I accept that I am not that audience, and I look at the product with as unbiased an eye as is possible.

I have to look at the Network Admin and User Dashboard the same way.

The Network Admin was moved from a Super-Admin sidebar menu to it’s own section, in order to provide a clearer delineation between Site Admin (in charge of one site) and the Network Admin (in charge of all sites). (Network Admin – Trac Ticket) (Network Admin – WordPress MustUse Tutorials, October 21, 2010) This is a basic, normal, every-day bit of separation in my everyday life. For one app I use, I even have a totally separate ‘Admin App’ to use when I want to control the whole network, versus just one part of it. It’s done for security, but also to kick our brains over and go ‘Hey, moron, you’re in the Network admin section!’ Our brains need that kick, and it lessens the human errors. In doing this, we also found the plugin management was separate. Per-site admins saw the non network-activated plugins only. The Network Admin had to go to the Network Admin section to see the network-activated plugins and the must-use plugins, though many plugins needed to be recoded to handle this move. (Adding a menu to the new network admin – WordPress Must Use Tutorials, November 30, 2010) While this is annoying and takes a little time to get used to, this is good, sound UI/UX. It’s called “Separate of Duties” in the buzzwords game, and it’s really a blessing.

Once they moved the Network Admin, the devs took a shot at getting rid of the Dashboard Blog. (Personal Dashboard – trac ticket) Once you moved the super users off to their own network, there’s no need to sign-up users to a main blog. I assume this was originally done becuase you had to hook them in somewhere with 3.0, to make them be a ‘user.’ Well, now WordPress.org Multisite now behaves like WordPress.com. You sign up for a blog but unless you get assigned a role to the blog, you’re not a ‘member’ of the blog. And you know… that’s sensible. You have no real role as a psudeo-subscriber. Nor do you need on.

As I pointed out, part of the goal with moving the menus to Network Admin is that the whole ‘Dashboard Blog’ concept was a massive annoyance to everyone code-wise and UI wise. Having to say “Oh yeah, the main site is the master site and it’s where I control the universe” is logistically unsound. Much like you cannot in-line edit posts, you should not be mixing up Admin and User areas. So to further that separation, your users are not assigned to any site when they register. I find I need to repeat, a lot, that in most cases, this has no effect on usability. It doesn’t affect my BuddyPress site at all, because the users are the users. They just don’t have blog access. They can comment, which is all they need to do for me, and they’re happy. If they need to make posts, I can add them if I want to. But now I have security, knowing they can’t accidentally get in and poke around.

Like it or not, it’s not going away. And most of us won’t need it to come back. I do know that some people do need it, and are struggling to find a way to auto-assign users a role on their main site at ID creation, so if you know of a fix for 3.1, please share it!

13 March, 2011
Do Pretty URLs Still Matter?

With all the kerfluffle about the new Lifehacker (and the 2.0.1 redesign) one thing stood out for me as the more interesting fallout: a rush on articles about the dreaded Hashbang.

Unix heads can skip this paragraph. For the rest of the world, a hashbang (aka a shebang) is the character sequence consisting of the characters number sign and exclamation point #!. You see this a lot at the beginning of scripts, and are used to define which ‘interpretor’ you’re using. Basically you’re telling Unix which program to use to parse the rest of the script. It’s more complicated than that, but this is not the place for goobley tech speak.

A hashbang used in a web URL is also an interpretor, but of a different sort. The hashbang is a fake tool used to get URLs generated by javascripts and AJAX picked up by Google. Great, what does that mean? The # tells the browser that the rest of the URL is an ‘identifier’ and everything after that # is computer code for a part of the current page. So in the case of Lifehacker, URLs went from http://lifehacker.com/5753509/hello-world-this-is-the-new-lifehacker to http://lifehacker.com/#!5753509/hello-world-this-is-the-new-lifehacker.

Most people missed the change and concentrated on the new layout. The #! in there manages to parse the right page, so why should we worry? After all, AJAX is the ‘future’ of the web. AJAX, by the way, is not the dim-witted but incredibly strong Greek hero. AJAX is shorthand for Asynchronous JavaScript and XML, but has very little to do with XML. Instead it’s used to create interactive web-apps. It’s exceptionally powerful, but a little dim-witted. Oh, okay, maybe my Illiad joke wasn’t so far off, after all!

AJAX has a whole lot of problems, most important (to me) is the fact that it’s not easily read by screen-readers, which means your blind visitors get the shaft a lot from poorly written AJAX sites. You also can’t use the back button most of the time, nor are these sites easily read by web crawler bots, which means that you don’t end up on Google results. Your page isn’t ‘real’, therefore it’s not followed. Of course, the folks at Google recognized this problem and came up with a weird solution: The Hashbang! That’s right, Google introduced it as a way to get sites dependant on AJAX into their results. (A proposal for making AJAX crawlable – Google Webmaster Central, Wednesday, October 07, 2009 at 10:51 AM)

Sounds great, though rather complicated and a little kludgey. Now you can have the best of both worlds. There are still drawbacks, of course, and I hear this refrain over and over:

The main problem is that LifeHacker URLs now don’t map to actual content. (Breaking the Web with hash-bangs – Mike Davies (Isolani.co.uk) Tuesday, February 08, 2011)

This initially perplexed me. After all, WordPress (which runs this site) is really a single page site (index.php) with a million identifiers, and it’s not like there’s an actual, physical, page on my server called do-pretty-urls-still-matter. What’s the difference? Turns out it’s all in how the URL is generated. The hashbang method is prone to error, as Lifehacker found out already, all you have to do is kill javascript and your entire site goes down. That I knew, but as I sat to write this I got myself in a bind. After all, in order for my pretty URLs here to work, I need .htaccess (which means my httpd.conf stuff is all in a row), PHP and SQL. Of course, all that is server side, and the user only needs the most basic of browsers to get to my site. But how were those failure points less than a javascript induced set?

I appealed to Twitter and got a couple fast responses from @JohnPBloch:

JohnPBloch: The difference is that one (js) depends on millions of different configurations working correctly; the other depends only on one […] for example, I’ve had chrome extensions that crashed JS on non-jQuery pages before.(JohnPBloch) (JohnPBloch)

Thanks to John, my brain kicked back into gear. There is no browser dependency on my URLs. The only way for them to fail is if I screw up the backend (that could be my site setup or my server). Either way, the critical failure will always be me, and never my user. That’s as it should be. We’re so often told that our customers are always right. As a corollary, your customers should never be at fault for a problem (as long as they’re using the products as intended). There are good reasons to use AJAX. Like using AJAX and javascript allows for a responsive and truly interactive experience for you users, in situations where small parts of the interface are changing (think Gmail, Flickr and Google Maps). Gmail actually would be perfect. That’s something where I neither want nor need a ‘pretty’ URL past http://gmail.com because I’ll never share the URL.

The rest of the time, though, URLs are important. If I want someone to visit my site, I tell them ‘Go to https://halfelf.org’ and they know what to do. Back in the Trojan War days, you’d hear “Login to AOL, keyword ‘Ipstenu’.” instead of a URL, and we’ve moved away from that to allowing people to claim their own domains and their own presence online. We shouldn’t be reliant on AOL, Google, or anything else to generate our representation. So, regardless of the problems with the hashbang (and there are a lot), your URL is important.

We all know the difference between a ‘pretty’ URL and an ugly one on sight. https://halfelf.org/?p=1358 is ugly and https://halfelf.org/2011/do-pretty-urls-still-matter is pretty! Simple. Lifehacker (and Twitter for that matter) have always had ‘kind of’ pretty URLs, with a weird number string in there, but enough to make you go “Okay, this Lifehacker post is about monkeys” or “This tweet is by Ipstenu.” With the change to hashbang, both sites (temporarily) broke the cardinal rule of websites: never change your URLs. By now, both sites will redirect a hashbangless site to a hashbanged one, which is as it should be. You never get rid of your old URLs, which is why on older sites, you have a really freakish .htaccess with miles and miles of regexp. AJAX makes you jump through hoops for pretty URLs.

But that really begs the question of whether or not pretty URLs actually matter anymore, or this just me being an old stick in the mud? Much like Google’s minor issues with AJAX/Javascript, they have minor issues with Dynamic URLs. Quickie explanation: static URLs are pretty, dynamic aren’t. Basically, they can and do crawl dynamic URLs, but static are preferred. (Dynamic URLs vs. static URLs – Google Webmaster Tools, Monday, September 22, 2008 at 3:20 PM) On the other hand, we know that shorter is better, and you can’t get much shorter than https://halfelf.org/?p=1358 when you get down to it.

I would posit that, since the web is based on look and feel, the design of your site still relies, in part, on the ease of someone in understanding the URL.

28 February, 2011

Author: Ipstenu (Mika Epstein)

Software Freedoms

Obfuscation Obtuseness

Limitations on Sortable Columns

Show Site ID Columns in MultiSite

WordPress MultiSite – New Dashboards

Do Pretty URLs Still Matter?