Technobabbles I try to sound like I know what I'm talking about. Don't be fooled.

30Jan/100

“Houdini” plugin for WordPress is no magician

I've seen some pretty absurd WordPress plugins show up in the Plugins dashboard widget on this site, but the recently-released "Houdini" takes the cake so far. It claims to prevent spammers from copying the contents of any post or page upon which the [houdini] shortcode is placed.

The fact is the internet is open can lead to theft especially to content stealing and plagiarism.

Until now, there was very little to discourage and deter this serious crime. Yes content theft and plagarism is a crime in some jurisdictions.

You cannot rely on others or the authorities to continue to police the internet as they do not have enough resources. You need to protect your content and deter this theft.

The basic form of content theft is to copy and paste your content to another medium.

Well Houdini, prevents this using a little known special algorithm that prevents copying by making the selected text that is targeted by the perps to be copied, to disappear! Yes disappear!!! The only way to recover is to reload the page in the web browser. If they try again, the content disappears again. As long as they keep trying to select and copy your content, the content will disappear before they can get a chance to execute the copy command!

After a few unsuccessful attempts, the theives will move on to a easier target.

Your safe!

WordPress › Houdini « WordPress Plugins

So what can we glean from this PHK Corporation plugin's description, other than the fact that the author has poor English skills? We can most definitely conclude that phkcorp2005 has no understanding of how most copying of Internet content is carried out. As I and others have pointed out many times over in blog and forum posts, copying is usually not done by a person using a mouse to cut and paste, but rather by automated computer programs called scrapers. (For the uninitiated: See these two Wikipedia articles.)

What is left out of that messy, error-riddled description is the word "JavaScript". It is by no means the only word or phrase that should be inserted, but it is the most important. That fifth "paragraph" (the formatting is also very poor) should say "special JavaScript algorithm", which is synonymous in this case with "useless JavaScript algorithm". All it does is wait for the user to try to select text in the browser and clear the selection if any is made. Besides, any copy-protection scheme based upon JavaScript is inherently useless by virtue of the fact that it doesn't do anything to prevent copying. There are tons of ways to get around it. Disabling JavaScript, for example (as mentioned below).

For example, take hatkirby's rant. I quote from that post the list of circumvention techniques below:

  1. Go old fashioned and turn off JavaScript. Yep, the script is rendered useless.
  2. More advanced content thieves likely don't just go around to random blogs and copy/paste off of them. They write screen scrapers, small programs that visit sites and download specific parts of the site. As these do not render pages and simply download from them, the script isn't even seen by the scraper.
  3. Due to the nature of the Internet, anyone, and I mean anyone, can see the source code of a website. It's done differently in different web browsers, but it's always pathetically easy and, as it simply shows HTML code instead of parsing anything, no scripts are run.
  4. RSS. Syndication feeds are normally viewed in feed readers with little to no JavaScript interpreter. Script bypassed.
  5. There's this cool little button on most keyboards that says "Print Screen". Even on the keyboards that don't have it, there's usually a key combination that achieves the same effect. It takes a picture of whatever's on the screen. No selection occurs and yet the thief has a copy of your article. They do, however, have to retype it, so this keeps the lazy thieves out.

That's just a smattering of ways to get around the JavaScript inserted by Houdini.

In the face of all the arguments presented, the plugin's author has insisted that the purpose of Houdini is not to "prevent" copying, but to "deter" copying. I don't think that statement holds any weight whatsoever. It still depends upon the copying being performed in a JavaScript-enabled browser by a human.

There's also the matter of just how absurd copy-protection of any kind is on the Internet. Every single document or file anywhere on the Internet must be copied in order for the user-agent (usually a browser in the case of human interaction) to retrieve and display or otherwise make use of the content. This is why it's quite simple for any user to just view the source code of a page. It has to be copied in order to display the content.

Also mentioned in the first (started, chronologically) forum thread is the ability of JavaScript to disable the browser's context menu and thus the "View source" option. That's just as useless as the selection-clearing code, and actually more so because many modern browsers allow specific JavaScript capabilities to be disabled — capabilities like removing or replacing the context menu — as an alternative to disabling all JavaScript. The "View source" option is also present in other places — places such as the browser toolbar's "View" or "Tools" menu — which JavaScript code cannot modify even in the most permissive environment.

Legitimate quoting must also be considered. There are a million and one reasons why someone might legitimately want to copy a few sentences of a blog post. Maybe they like it enough to post a quote to Twitter or Facebook, or perhaps they want to comment on it in a blog post of their own. Content theft is a big problem, but the old methods of periodically searching for and reporting content stolen from one's site are infinitely preferable to this plugin's ineffective method.

Finally, why require the use of a shortcode? Why not just add the script globally to all content pages and forget that stupid "This page is copy protected" header?

At most, Houdini has the ability to add a superfluous <h5> tag to the page and annoy legitimate users with an obnoxious script while doing absolutely nothing to thwart real content thieves. I wonder if WordPress Extend would consider removing this laughable plugin from the directory... Of course, we bloggers would then be denied this ripe opportunity to satirize this particular piece of code. :D

22Jan/104

My First WordPress Plugin Patch: Wibiya Toolbar

The beauty of using WordPress instead of Blogger is, in a nutshell, the freedom that comes with using an open system instead of a closed one. Under Blogger, I had very little freedom to extend the platform. Everything I could do had to be added by someone from Google, with the exception of a few JavaScript- and Flash-based sidebar widgets. Under WordPress, I have access to literally thousands of open-source plugins to modify, extend, and replace the functionality of the site.

The beauty of using this open system is that if something doesn't work the way I want it to, I am free to simply change it; every plugin is editable from within WordPress' administrative back-end, and the core code is also hackable (though I don't like messing with it because upgrades will break changes). When I discovered that the Wibiya Toolbar (or Wibar) was showing on the mobile version of the website (which is generated by MobilePress, another good plugin), I simply looked in the source of Wibiya's plugin to see how the JavaScript for the toolbar was being inserted.

I found that instead of using the wp_enqueue_script() function as WordPress plugin developers are supposed to do, the Wibiya developers simply used echo to output a <script> tag. That explained why only the JavaScript for the Wibar was loading on the mobile site. Rewriting the plugin to use the official WordPress script-injection method solved the problem.

The original relevant code was:

add_action('get_footer', 'filter_footer');
add_action('admin_menu', 'wibiya_config_page');

function filter_footer() {
    $wibiya_toolbarid = get_option('WibiyaToolbarID');
    $wibiya_enabled = get_option('WibiyaToolbarEN');

    if ($wibiya_toolbarid != '' and $wibiya_enabled) {
        echo '<script src="http://cdn.wibiya.com/Loaders/Loader_'.$wibiya_toolbarid.'.js" type="text/javascript"></script>';
    }
}

I rewrote it just a little bit. My changes were pretty trivial, really. I changed the function name to be namespaced (including the plugin name) just so it'd be less likely to conflict with another plugin. I also switched actions to enable wp_enqueue_script() to work (get_footer is called too late) and added a check—if( !is_admin() )—to keep the toolbar off of admin pages, preserving the original behavior of the function (and the sanity of anyone using the modifications).

In short, wp_enqueue_script() takes five parameters, three of which are optional. The first two are the $handle and the $src, which specify a name for the script and its source address. Then come $deps (dependencies; Wibiya has none, so set to false), $ver (version; also false because it's irrelevant), and $in_footer (set to true because the toolbar should be inserted above the </body> tag).

So with my changes, the code block above becomes:

if( !is_admin() ) {
    add_action('wp_print_scripts', 'wibiya_filter_footer');
}
add_action('admin_menu', 'wibiya_config_page');

function wibiya_filter_footer() {
    $wibiya_toolbarid = get_option('WibiyaToolbarID');
    $wibiya_enabled = get_option('WibiyaToolbarEN');

    if ($wibiya_toolbarid != '' and $wibiya_enabled) {
        wp_enqueue_script( 'wibiyabar', 'http://cdn.wibiya.com/Loaders/Loader_'.$wibiya_toolbarid.'.js', false, false, true );
    }
}

Following some light testing, I submitted an idea to the Wibiya feedback forum, where my update is currently being reviewed by the company. Hopefully, the change will be included in a future version of the Wibiya WordPress plugin. After all, it changes nothing for Wibiya but works wonders for compatibility with other plugins.

I'll just bet that this won't be the last time I'll send a patch to a plugin developer. I enjoy reporting bugs and coming up with fixes too much to not do it. ;)

22Jan/100

Bringing Back Skribit

A while back, I tried out a service called Skribit on my Blogger site. Skribit's purpose is to help bloggers overcome writer's block. It places a suggestion form on the site where visitors can leave ideas for the blogger to use when he or she is out of his or her own ideas.

It never got much use by readers of the old site, so I initially didn't bother transferring it here; but now that Skribit has launched and (I see) done a lot of work on the experience users leaving suggestions have, I figured I might as well install the WordPress plugin and give it another go. It doesn't take up any space in my sidebar, either, now; since I stopped paying attention to it, a new floating tab option has popped up. For now, it's over on the right-hand side of the page.

Go ahead, shoot me some ideas! I may have something of a backlog from the last few months, but I certainly don't have an endless list.

17Jan/103

How I Beat Blogger and Redirected to WordPress

Yes, I really and truly have migrated to WordPress from Blogger. I know there are a lot of guides out there, but I think the method I used was different enough to warrant a new post. (I won't duplicate the steps of setting up the new WordPress site and importing the content from Blogger; that's pretty obvious, and it's well covered elsewhere. Redirecting is the art form that's been changing every few months.)

Obligatory Rant

Getting away from Blogger is really much harder than it should be. There should be a process to verify with Google that one is not a spammer trying to get free link juice etc. and have the 301 redirects with the Custom Domain feature specifically enabled for the blog one wishes to move. Hackery like what I came across, and what I used, shouldn't be necessary. Blogger should natively support moving away from its platform, even if it might require a little human intervention on Google's end.

It's really too bad that Google is so horrible with customer support. Their products are, generally, really great, but if you run into a problem it had better be something common that others have run into. Your only option, in most cases, is to post in a public support forum and cross your fingers. Fortunately the problems I've encountered have been few, though I am getting increasingly irritated with every issue.

The Premise

Way back in the day, Blogger used to offer 301 Moved Permanently redirects via its Custom Domain feature, even for domains not set to CNAME to ghs.google.com, but I guess spammers were abusing the feature because that ability went away. For a while now, it's been showing an interstitial page to visitors instead of redirecting, warning visitors and crawlers that the site is now redirecting to an untrusted domain. This passes no link juice, and is incredibly inconvenient and unsightly for everyone.

I did a lot of research beginning when I returned from my long summer. In between college applications, family trips, and so on, I performed search after search for methods of migrating away from Blogger to a self-hosted WordPress site. I found a plugin to restore the old Blogger post slugs (to make redirection easier), but every redirect method I came across was in some way outdated and/or broken — until I happened to find Digital Inspiration's method: A Classic Blogger template specially configured to issue canonical links tags, JavaScript redirects, and a big <h1> anchor link to the new site.

Digital Inspiration redirected all traffic to the old site to a special page on the new server, built to handle redirections. A PHP script was offered, but I didn't take that bit. I found a nifty WordPress plugin instead: Redirection by urbangiraffe.com. With two plugins (Redirection and Maintain Blogger Permalinks, mentioned below) and the Digital Inspiration template generator, I was ready to develop my method.

Introduction

Before you do this kind of thing, make sure you run a plugin like the one mentioned here to convert the slugs for posts imported from Blogger to the Blogger format, so they'll match up with the redirects. If you don't, any posts with "small words" ("and", "the", etc.) in the title and posts with lengthy titles will have issues once you switch to the new site.

Also note that you may need to set the number of posts to display on the home page to 1 on Blogger's end. I had a last-minute bug when I implemented this for real that I didn't catch on the test site because I only created one nonsense post. Imagine how frustrating it was to suddenly have seven copies of each <Blogger> section on the page. (Now that I think about it, that's probably why the DI generator kept the homepage stuff out of those sections. But you should change the setting anyway just to be safe.)

Finally, note that, contrary to what a lot of migration guides say, you don't have to set your permalink structure in WordPress to match Blogger's. If you don't want your post URLs to end in .html, they don't have to. Apache .htaccess rewrites and/or the Redirection plugin will be your friend(s). I chose to simply convert the .html into a / but you can pretty much do whatever you want. I've also found that WordPress is capable of redirecting links of the format http://domain.tld/post-slug-here/ to the fully-qualified permalink all by itself, so use that as the target if you want to use a permalink format that doesn't match up with Blogger's. Note: I haven't personally tested this, but given what I know of how WordPress handles things, it should work fine. Use at your own risk, etc. etc., don't blame me if it won't work, etc. etc. But you're welcome to ask for help, of course. ;)

Development

I started with a redirect template generated using Digital Inspiration's generator and set up a Blogger handler in Redirection on the new WordPress site, modifying the newly generated Blogger template accordingly. (DI's generator defaults to /blogger/ which I didn't want; it might eventually conflict with something. I used a more action-oriented /handle-blogger, removing the trailing slash.) The redirect I used was: /handle-blogger\?q\=http\:\/\/voyagerfan5761\.blogspot\.com(\/.+) -> $1

I began developing this solution well before discovering the magic bullet at Digital Inspiration. One of my first steps after installing WordPress was to add mod_rewrite redirects in my .htaccess file so I'd be prepared for redirections from Blogger. Once the handler was in place, I transferred my Apache redirection rules to the Redirection plugin in WordPress:

  • Posts: /([0-9]{4})/([0-9]{1,2})/([^/]+)\.html(\?.+)?$ -> /$1/$2/$3/$4
  • Categories (labels): /search/label/(.+)(\?.+)?$ -> /category/$1/$2+
  • Monthly archives: /(\d{4})_(\d{2})_\d{2}_archive\.html(\?.+)?$ -> /$1/$2/$3

+ – Still need to figure out how to transform this to lowercase and change %20s to hyphens.

Update (02/14): I discovered that query strings killed the redirects and led to 404s. I changed $ to (\?.+)?$ at the end of each regex as well as added extra corresponding backreferences ($4 for posts, $2 for categories/labels, and $3 for monthly archives) to fix it. All query strings are kept, even if they're meaningless on the new site, but otherwise it would be a pain to whitelist only the useful ones. I'll update again with blacklisted query parameters if I discover a Blogger query parameter that breaks something in WordPress.

Once I had all the handling pieces in place on the new site, I tested the Blogger template on a test blog. During my testing, I found room for improvement. For instance, I read in my research that a meta refresh tag, used with a delay of 0, is often treated as a 301 redirect by search engines. I added refresh tags to the template.

I also found that Blogger tries to thwart JavaScript calls to window.location.href by placing script tags on the line following the call and invalidating the entire block. I defeated that by placing a multi-line comment starter after the semicolon, wrapping the block in <![CDATA[...]]>, and creatively faking out Blogger. It still inserts the extra tags, but they don't harm anything because I used trickery to force Blogger to place them inside a comment block (where they're just ignored).

In case future changes to Blogger break the template — and I'm sure that Google will do something to break my setup eventually — I added a link to my new contact page for users to tell me if it's not redirecting.

The template does everything I need it to do. With the Redirection plugin, I didn't need to use the PHP script provided in the Digital Inspiration post. I should also get better results from the migration because of the extra work I put into my template; feel free to get a copy for yourself. If you use it, please leave the existing comment block at the top intact. Both the original authors at Digital Inspiration and myself will appreciate it. I also plan to share my improvements back to DI.

Conclusion

Satisfied with my testing and confident of the results, I implemented the template on my real old Blogger site a couple days ago, where it seems to have been chugging along nicely ever since. If it breaks, and I don't notice, I'm sure someone will take the time to use the contact link I added and let me know. The link might cause a few issues with search crawlers, but I think I'm OK with it. Misdirected link juice is better than broken functionality.

Of course, this is the technique that worked for me. Like all the others I found, I'm sure this one too will become oudated and/or broken with time. But for now, it seems to be the best method for escaping the clutches of Blogger.

Update (01/23): A reader pointed out in the comments that IE6 might not follow the redirect. If your site has a significant fraction of readers using IE6, keep that in mind. I won't worry about it for my site just because most of you use something more recent.

17Jan/100

Migrated to WordPress!

I did it. I finally did it. I ditched Blogger!

You know, there's a certain satisfaction to this. I've been wanting to ditch Blogger for years, ever since I discovered WordPress. And I finally did. I'll consider the completion of this migration to be the fulfillment of my unstated New Year's resolution. :)

Thanks to the generosity of one of my Twitter contacts, @Navarr, I now have a self-hosted (er, friend-hosted) WordPress blog. He offered to host my blog after seeing me complain a lot about things I couldn't do under Blogger. Eventually I bit the bullet and bought a domain name near the end of October. The full story is available (once I finish revising it — oh, hell, that'll never happen, so just read it now and keep checking back :P ) on the about page. Now there's something I couldn't do with Blogger: A static page! :D (Update (01/20): Blogger just launched Pages on Blogger In Draft. Little late, guys.)

As an advance warning to my feed subscribers who've become used to visiting this site at voyagerfan5761.blogspot.com, I'm announcing that all pages on that domain will begin redirecting to a new WordPress site I set up at technobabbl.es soon. In fact, I'll probably have that set up by the time this post is published. Feed and email subscriptions, which are run through FeedBurner, should be unaffected by all this reconfiguration; the most you might experience are some issues with duplicate items being fed or mailed to you when the switch is made. Since I switched the feed a few weeks ago, all of those humps should be done with.

The search for a redirection solution was pretty tedious. Because I want to leave Blogger's hosting behind, the Custom Domain feature wasn't an option. Since I need the DNS records for technobabbl.es to point to DreamHost instead of Google, Blogger wouldn't issue 301 Moved Permanently headers; instead, it would show interstitial "untrusted domain" warning pages (returning 200 OK, creating a horrible search engine situation) that don't redirect users and don't pass link juice on to the new site.

I'd just 301-redirect the whole site if I had any way of doing so. Since Blogger doesn't let me do that, I either have to start from scratch search engine– and backlink – wise or find a more creative solution. Thanks to Digital Inspiration for a great post on migrating and Blogger redirection template generator, and thanks to John Godley of UrbanGiraffe.com for the Redirection WordPress plugin.

It took me a while to find this combination, but my pre-implementation testing indicates that it should be pretty perfect. I've also extended the Digital Inspiration template to issue meta refresh redirects in addition to JavaScript, anchor link, and canonical link tags, which should make it even more search-engine friendly. I could have just used redirects in my Apache .htaccess file, but Redirection will log the redirects for me, so I can keep track of the traffic coming in from the old site. For a more complete explanation of what tools I used for the migration, watch for a new how-to post.

Even with the redirection, I would like to ask all of you to update your bookmarks, and anyone who's linked to me should please edit those links. Redirects are fine, but it's better to not make crawlers (and users) jump through those kinds of hoops. I'd like to try and keep the experience as clean as possible.

Speaking of cleanliness, there were other side-effects of importing everything from Blogger. First, my feed footer was included in every post. So that's something for which I should keep an eye out. I'll get rid of all those pesky footers eventually. I only have to get them out of 500 posts. Second, Blogger uses stupid formatting tags (lots of <span style="font-weight: bold;">...</span> and <span style="font-style: italic;">...</span>) instead of the semantically correct, shorter <strong> and <em>, and it uses more <span> tags to size the text up for headers instead of creating <h_> tags. More slow cleanup work for me to do. Just have to fix a few posts at a time. I also need to do something with my Picasa-hosted images; rumor has it that they'll disappear if I stay away from Blogger too long.

Now I'm going to stop rambling about all the work I have to do on the site. :P Thanks for reading, everyone. I hope you'll weather any transition turbulence and follow me to my new site, where I've been working on a few hefty new posts to make up for the distinct lack of blogging in the last year. ;-)

30Mar/080

FriendFeed Improves in Leaps and Bounds

Since going public last month, FriendFeed has made numerous advances in functionality and service support. In March alone, there have been six posts on the FriendFeed blog, some containing news of multiple enhancements and/or additions to the service. Here's a run-down of all the improvements FriendFeed's made in just one month.

The first thing to happen was a speeding-up of the service. Bret Taylor posted "FriendFeed is now a lot faster" on March 11, and indeed the site was blazingly fast from then on. It still is. The joke at the time was that a new Ethernet cable sped it up (FriendFeed thread), but the truth is that there was a lot of code tuning, caching, and a new indexing scheme added (FriendFeed thread, changelog entry).

Three days later, feeds for comments and Likes were added. March 14 was the day you could finally "See the stuff your friends commented on and liked". There were also some nice statistics added: Comment and Like totals for both the past week and all time became available in the bar on the right of every user's profile page.

On March 17 (yes, another three-day interval), FriendFeed got search! Not only could you now see your friends' comments and Likes, and not only was the site now blazingly fast, but items previously lost to the ether could now be found again. (I call the addition of search the "Googlification" of FriendFeed, because nearly every Google service has a search box.)

Between the addition of search and the next update, there was a one-week reprieve. It was good to have a rest from FriendFeed update stories because it made the next announcements all the more wonderful. March 24 saw a boatload of updates. First of all, there were five new services added (Disqus, Goodreads, LibraryThing, Seesmic, and SlideShare). Second of all, there were numerous bug fixes. Third of all, FriendFeed got the ability to post back to Twitter! Commenting on a tweet in your feed gave you the option to also send the comment as an @reply via Twitter.

As if all that wasn't enough, the FriendFeed team launched their API the following day, on March 25. Since the launch, third-party developers have released a WordPress plugin (which can be seen in action on CodingExperiments.com) and a statistics site, with an Adobe AIR application rumored to be on its way.

So, in short, FriendFeed is making humongous strides in advancing its service. They sure turn around features a lot faster than Google... Here's to another month of FriendFeed advancement!

Oh yeah, it can't hurt to plug my FriendFeed page while I'm talking about the site, can it? ;-)

3Mar/080

WordPress’ Impressive Import Functions

This post has to do with an experiment I conducted last night with the WordPress installation at CodingExperiments.com, one of the other sites I write for. In the true spirit of that site, which is experimenting with code and all things computer-related, one or two visitors (who viewed the site or requested the feed in a window of about two minutes) may have noticed six extra posts briefly appear in the archives. That was my doing. (I did not, however, have anything to do with today's outage; that was possible248. :-D )

See, possible248 (that site's owner) granted myself and i80and (another friend and contributor to that site) admin status within WordPress (I'll have to talk to possible248 about his capitalization, as he writes it "Wordpress") yesterday, and I was exploring the options offered in the control panel. One of the tabs that intrigued me greatly was the import tab, which offers many options for importing content from other platforms:

That... is... so many platforms. Blogger being there is of particular interest, because I currently write for several blogs hosted on Blogger, including this one.

So, to explain why six posts appeared on this site briefly: I decided to give the import a try on the smallest blog.

The import was completed very quickly using Google Data APIs. After the import was complete, I was given the opportunity to change the author of posts. I must say I am very impressed with WordPress' ability to grab content from so many (13 plus itself) different sources.

It's also reassuring to know that, if I ever choose I no longer like Blogger and want to host my own site, it will be a piece of cake to move to WordPress (which is what I'd probably choose). The only question there is moving back to Blogger if I ever decide to do that. But both situations are far out in the future, reserved for when I have the time and money to maintain my own hosting.

Meanwhile, I consider the experiment a success. Go WordPress!