Author: Ipstenu (Mika Epstein)

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
Google vs Splogs – Part 2

Now that you know all about the myth of the duplicate content penalty, we can look into spam.

This year, Google got slammed because the quality of their search was being degraded by spammers. Mostly splogs, I will admit, but Google rightly points out that their ability to filter out spam and splogs in all languages is actually much better than it was five years ago. (Google search and search engine spam – 1/21/2011 09:00:00 AM) No, Google isn’t getting worse, there are just more spammers out there. They also take the time to differentiate between “pure webspam” and “content farms.”

“Pure webspam” is what you see in a search result when a website uses meta data or hidden content in order to bully their way into being highly ranked in unrelated searches, or just basically game the system. A decade ago, this was horrific. Now it’s nearly negligible. This type of spam grew pretty organically out of people trying to understand the algorithm behind search engines and manipulate it legally. As we gained greater understanding of meta keywords and in-context content, we came up with more and more tricks to legitimately make our sites more popular. There was a point in time where having hidden text with as many keywords related to your site was not only common place, but lauded. It didn’t last long, as shortly after the good-guys sorted that out, the bad-guys did too.

“Content farms” are the wave of the future, and Google calls them sites with “shallow or low-quality content.” The definition is vague, and basically means a content farm is a website that trolls the internet, takes good data from other sites, and reproduces it on their own. Most content farms provided automatically inserted data. There is no man behind the scenes manually scanning the internet for related topics and copy/pasting them into their site. Instead, this is all done via software known as content scrapers. The reasons why they do this I’ll get to in a minute, but I think that Google’s statement that they’re going to spend 2011 burning down the content farms is what’s got people worried about duplicate content again.

A content farm is (partly) defined as a website that exists by duplicating content. Your site’s activity feed/archives/post tags pages are duplicating content for the users. Does that mean your site will be adversely affected because of this?

No. It will not.

Google’s algorithm is targeting sites of low content quality. While your stolen post is a beautifully written piece of art on its own, it’s the site as a whole that is used to generating a search ranking. As I’ve been touting for a decade, the trick to getting your site promoted in Google searches is to make a good site. Presuming you made a good site, with good content, and good traffic, and it’s updated regularly, there is very little risk that Google will peg your site as being of “low content quality.” Keep that phrase in mind and remember it well. Your site isn’t highly ranked because of low content, remember! It’s the reverse. If you’re being ranked for good behavior, good content, and good work, you will continue to be rewarded. In a weird way, content farms are actually helping Google refine their search so that it can tell the difference between good sites and bad! (Why The Web Needs Content Farms – by Eric Ward on February 16, 2011)

The next Google algorithm update will focus on cleaning content farms from positions of unfair advantage in our index. This will likely affect websites with considerable content copied from other online sources. Once this update is complete, preference will be given to the originators of content. We expect this to be in effect in no less than 60 days. (Google search and search engine spam – 1/21/2011 09:00:00 AM)

What Google is doing is not only laudable, but necessary. They are adapting to the change of how spam is delivered, and doing so in a way that should not impact your site. The only ways I can see this affecting ‘innocent’ sites are those blogs who use RSS feed scrapers to populate their sites. This is why anytime someone asks me how to do that, I either tell them don’t or I don’t answer at all. While I certainly use other news articles to populate my site, I do so my quoting them and crafting my own, individual, posts. In that manner I both express my own creativity and promotion the high quality of my own site. I make my site better. And that is the only way to get your site well-ranked. Yes, it is work, and yes, it is time consuming. Anything worth doing is going to take you time, and the sooner you accept that, the happier you will be.

For most small to medium sites, there’s not a thing you need to do in order to maintain your ranking. There are no magic bullets or secrets behind the SEO, to manipulate your site to a better ranking. In point of fact, doing so can be seen as gaming the system and can downgrade your results! Once again. Make a good site and you will be rewarded. Certainly, as I said yesterday, optimizing your robots.txt file and getting a good sitemap will help, and I really do suggest a Google Webmaster Tools account to help you with that. In 2011, Google is still king, so once you get your site well listed within Google’s machine, you’re pretty much going to be tops everywhere.

Why do splogs and content farm game the system in order to get highly ranked? Profit. Some do it to get their domain highly ranked and then sell it for a lot of money, others do it to infect your computer with a virus, and then there’s the rare hero who thinks this will get them money because of the ads on their site. Sadly, this still works enough to generate just enough of a profit to keep the splogs going. This is also true of spam emails. Yes, that means your grandmother and Carla Tallucci are still falling for the Nigerian Princess scam emails. The only way to stop all of that is to stop those methods from being productive money makers for the spammers, and that is something that will take us all a very long time and a great deal of education to the masses.

Your take aways are pretty simple. Make a good site with good content. Update it regularly. Use a sitemap to teach search engines what’s important. You’ll be fine. Don’t sweat internal duplication.

22 February, 2011
Google vs Splogs – Part 1

I am not an SEO expert. In fact, there are only a handful of people whom I feel can claim that title without making me roll my eyes so hard I get a migraine. Anyone who tells you they have all the answers to get your site listed well in Google is a liar, because there’s only one good answer: Make a good site. That’s really it. How then do all those spam sites get listed in Google, Bing and Yahoo to begin with, and will the techniques the search engines are using to eradicate those sites hurt you?

Everyone’s done that search for something and been nailed by a bunch of splogs. Like you look for ‘Laurence Fishburne’ news and you get 100 websites that claim to have news, but really it’s just total, useless crap? Those are splogs, a neologism for spam blogs, and they suck. Splogs are blogs where the articles are fake, and are only created for search engine spamming. They sometimes steal your hard work and use them, by scraping RSS feeds or who knows what else, and generating fake content. Why? Some people do it to infect your PC with a virus, and others do it to trick in into clicking on their ads.

The problem is spam blogs are so prevalent that they’re adversely affecting search engines, making it harder and harder for you to find real, factual content. This year, rurmors started flying that Google was going to go on the warpath against Search Engine Spam, and in doing so, would downgrade perfectly valid sites with ‘duplicate content.’ Having read and re-read the articles posted by Google on the matter, I’m quite certain that, yet again, people are playing Chicken Little. Nowhere, in any of the articles I’ve read, has there been any discussion of the intent to penalize legitimate, valid, websites for containing internally duplicated content.

In order to understand the duplicate content penalty problem, and yes, it is a problem, you need to understand how most content management systems (CMS – this includes sites like Drupal, Joomla and WordPress) display their data to the users.

You write a blog post and the content is stored in the database, along with any tags, catgories, or meta data you put in. When someone goes directly to the blog post, they see. However, they can also see the post if they go to a list of posts in that category, with that tag, on that date, in that year, etc etc and so on and so forth. So the question a lot of new webfolks ask is “Is that duplicate content?” No. It’s not. Nor is having ipstenu.org and ipstenu.org point to the same page. In fact, that’s good for your site. The more, valid, ways you have of providing your user with information, the easier it is for them to find what they want, and they happier they are. Happy users means repeat users, which means profit (in that oh so nebulous “web = profit” theory).

So what is this mysterious duplicate content penalty?

Let’s take this from the horse’s mouth (or at least Google):

Let’s put this to bed once and for all, folks: There’s no such thing as a “duplicate content penalty.” At least, not in the way most people mean when they say that.(Demystifying the “duplicate content penalty” – Friday, September 12, 2008 at 8:30 AM)

Google goes on to outright state that so long as the intention is well meaning (like making it easier for people to find your valid and useful content), then you will receive no adverse effects in searches for your blog. That means 99.999% of you out there can relax and walk away. What about people who use things like WordPress MU Sitewide Tags Pages (which takes the excerpts of all posts on a WordPress MultiSite installation and duplicates them onto another site), or BuddyPress’s activity stream (which records everything in multiple places)? Again, the answer is the same. You’re doing this to make the site more available and accessible, ergo no harm ergo no foul.

Google also makes the claim that since CMSs generally don’t handle duplicate content ‘well’ (their word, not mine), non-malicious duplication is common and fairly harmless, though it will affect search results. Here’s where things get sticky. Personally, I disagree with Google’s claim that CMSs handle duplicate content poorly. A well written CMS, knowing that no two people think the same way, takes that into consideration when crafting a site. You want an index, but if you know someone looks for things by subject matter or year, you need to have a way to provide that information for the reader. Google’s problem is that in doing so, you have also provided it for the GoogleBots who patrol your site and pull in the data for searches, which makes the dreaded duplicate content.

Perhaps Google has forgotten (or not made the connection) that they do the exact same thing. They want to show you what you want to see, and while I may search for “Laurence Fishburne actor” and you might look for “Morpheus Actor”, in the end, we both want to see sites about this actor guy named Laurence Fishburne. How do you make sure we get the right information? You have the content sortable in myriad manners. Does that make it duplicate content? Of course not (unless you’re Bing, which is a whole different subject). Google points out:

Most search engines strive for a certain level of variety; they want to show you ten different results on a search results page, not ten different URLs that all have the same content. To this end, Google tries to filter out duplicate documents so that users experience less redundancy. (Demystifying the “duplicate content penalty” – Friday, September 12, 2008 at 8:30 AM)

Thankfully, you can eliminate redundancy by providing Google with a sitemap of your website.(About Sitemaps – Google Webmaster Central) With a good sitemap, you can tell search engines how to weigh your site’s content. Which pages are more important, which can be ignored, etc etc. With WordPress and a good plugin, this can be done automatically by making a few choices in an admin interface. You also want to spend a little time understanding your robots.txt file. Perishable Press has a great article on optimizing it for WordPress.

Now that you know about the myth behind the duplicate content penalty, tomorrow we can get into content farms!

21 February, 2011
Has your site been exploited or victimized?
Nothing frosts my lizard more than someone saying ‘WordPress has been hacked!’ and I’ve finally decided it’s just a case of ignorance.

I’ve been using WordPress since around the famous 2004 MovableType bait’n’switch, when they decided to go paywall. That was not what made me switch to WP. In fact, I had already installed a b2 site in order to allow anyone in my family post a story about my grandmother (and I should really put that back online one day…). It was a lot of little things that made me switch, and I don’t really regret my choice. MT is very useful, very cool and very impressive, but it wasn’t what I wanted or needed.

Yesterday, Byrne Reese posted about how WordPress Won the Blog War. He’s a former Movable Type project manager, so I presume he knows what’s he’s talking about. As a former member of the MT community (under a non-Ipstenu handle) and current heavy user of WordPress, it’s very entertaining to hear a behind-the-scenes view of the ‘war.’ I never saw it as a war, and as anyone who knows me can attest to, I’ve never been a rabid fanboi for one OS or another, one product or another, simply because of who makes it. I like my iPad, but if it doesn’t work for you, I’m more than happy to help you find an alternative. I believe in finding the product that works for you.

What really caught my attention in the post were the comments. The very first had this gem by Matt Haughey:

Now that they’ve won the battle, I think the biggest problem for WP now is two-fold: One is the constant threat of exploits with your own WP install. It’s crazy and like running Windows 95 without patches. Everyone I know with a self-hosted WP has been exploited in the last year or two and worries about it regularly.

Two facts:
1) My WordPress install has never been hacked in the 7 years I’ve had it.
2) I do worry about it constantly.

About a year ago, my server was hacked. Ironically it came three days after I’d posted about WordPress security. How was I hacked? Because I followed insecure practices. I’ve touted, for a while now, that security is a tripod:
- The Web Host is responsible for making sure the sever itself is up to date with the latest patches etc, and that the server is configured in a safe way.
- Web-apps are responsible for not unleashing needless insecurities to the system.
- The end-user we pray to the flying spaghetti monster that they’ve not done something to violate security out of ignorance.
I was hacked because I violated security, which made my server open to attack, which thankfully resulted in my Web Host bailing me out (have I mentioned I love them?). I went to a website on an non-virus-protected PC (yes, Windows), I got what I thought looked suspicious pop-up in IE from a site I knew and trusted, and while the pop-up was there, I opened an FTP (not secure FTP!) connection to my server. I seriously could not have been stupider. Thankfully it was easy to fix, and I since turned off FTP (it’s SFTP or nothing). Actually I also wiped Windows XP off my computer, but previously it was required for my work.

On Byrne’s post, Mark Jaquith (a WP developer) remarked this:

I haven’t seen an up-to-date WordPress install get directly exploited in around five years. Seriously.

I thought about this for a moment, and had to nod. This is true for me as well. Every WordPress install I’ve seen with problems has been due to the web-host or the end-user being insecure. Even when that end-user is me, I’ve yet to have WordPress itself hacked. This does not mean I think WordPress can’t be hacked, just that it’s actually a pretty secure little tool by itself.

Then Mark went on to say this:

All of the large scale instances of WordPress being compromised lately were because of web hosts who don’t prevent users on one account from accessing files on another account. In these cases, WordPress wasn’t exploited so much as it was victimized due to a lower level security issue on the server.

He was far more succinct then I’ve been able to be on the matter, but I’ve touted for a long time that the problem is WordPress, but it’s not WordPress’s fault. Ask anyone in IT why Windows has more viruses than a Mac, and most of us will tell you it’s because Windows is more popular. More people use it, so more hackers/spammers/crackers target it. I wouldn’t say, in 2011, that Windows 7 is more vulnerable than OS X, but I would feel comfortable saying that it is targeted more.

The answer is the same when I’m asked why WordPress gets so much spam. Because it’s used a lot! The more prevalent your product is (i.e. the more successful it is), the higher the likelihood is that some jerk with a kiddie script will try to attack it. This is just a fact of life, and I’m not going to get into how to solve it.

What I feel we need to be aware of is the education of the user base for any product. My father once gave a memorable lecture I caught when I was about six or seven, about our expectations with computers and why AI was never going to be like we saw on Star Trek. “Ignore the man behind the curtain!” he said to the crowd. Back then, I had no idea what he meant. Today I realize that it was two-fold. On the one hand, we think ‘Automate everything! Make it all just work!’ That’s the magic box theory of computers. It all just works and we don’t have to do anything. The reality is that there is always a man behind the curtain, making the magic happen.

The ‘two-fold’ meaning is that (1) we want everything to work perfectly without manual intervention, and that’s just not possible and (2) we don’t want to have to learn WHY it all works, just make it magically work.

My savvy readers are, at this point, thinking “But if I don’t know why it works, how can I fix it?” To them I shrug and agree that you cannot be expected to fix anything you do not understand. Furthermore, the less you understand something, the more likely you are to inaccurately blame someone/something. Which brings us back to why I hate when people say ‘WordPress has been hacked!’ Actually, I hate it when they say anything has been hacked (Drupal, Joomla, WordPress, MovableType, etc etc etc).

We have a few choices at this point. We can stop ignoring the man behind the curtain and learn how the levers work ourselves, or we can accept that we’re not clever enough and hire someone. Either way, we should always take the time to sort out what’s wrong. When my cat was, recently, in the kitty ER for bladder stones (she’s fine now), racking up a $1000+ bill for services, I wanted to know all about what caused them, why did the food work, etc etc. I’m not a vet. I would never make it through medical school (I don’t like blood). But I know how to use my brain. As my professor, Dr. Lauer, told me in high school, “We’re teaching you how to think, how to talk to adults while you’re a child, so you know how to be a person.”

Teach people how to think. You’d never take your Mercedes Benz to Jiffy Lube for an overhaul, so why are you trusting a $5/month webhost without a phone number to support your business? You wouldn’t take your child to a back-alley doctor, so why are you hiring some guy with blink-tags on his site to fix your website? Use your brain. If your webhost tells you ‘Sorry, we can’t help you,’ then take your money someplace else. Website support should always include them taking backups at least every day (you may only get yesterday’s backups, but they should still have ’em). A good host will help you when you ask specific questions.

My host (there’s a link on the top right) will answer the phone 24/7, they helped me craft a backup strategy, un-do the hack on my server, trace down what was using up so much CPU, bead mod_security into submission … the list goes on and on. My point here is not that you should use them (though if you do, tell them I sent you!), but that you should find a host who supports you to the level you need. The brunt of what you pay for hosting is an insurance policy. You’re paying them to bail you out when (yes, when) you need help, and if you’re only paying $5 a month, then you should only expect that level of return.

Educate yourself, educate your host, but have realistic expectations.
10 February, 2011
Don’t Bother Disabling Right-Click

Every now and then I see someone ask ‘How do I disable right-clicking on images on my site?’ My answer, invariably, is ‘You don’t.’ The real question I suppose is ‘How do I stop people from ripping off my work on the net?’ and the answer to that is still ‘You don’t.’

Is it online? Yes? Then it can, and will, be stolen. Does that matter? Kind of. The only way to make your works un-steal-able is to never publish them anywhere.

When the last Harry Potter book came one, some diligent nerd spent countless hours photographing every page of the book, uploaded it online, and oh look, we all knew how it ended. That did not stop everyone from buying the book though, and in the end, was pretty much an amusing footnote in the saga of Harry Potter. And anyone who thought Harry wouldn’t defeat Voldemort was clearly not paying attention.

When I put my dad’s stuff up online, I told him it would be better to convert his PDFs to easily readable HTML. He didn’t want to because they could be stolen. I pointed out that the PDFs are actually easier to rip (download, done), and the HTML was just being generated by copy/pasting from the PDF anyway, so he was already there. The point was to make his work more accessible.

Does this mean you shouldn’t protect your data? Of course not! But the point is if you publish it, online or offline, it can, and will, be stolen. The only thing online media does is make it ‘easier’ to steal and re-publish under someone else’s name. Without getting into the myriad laws of copyright, I want to point out that your publish work is only part of your brand. If someone steals a post I make here, yes, they’re taking away from my audience, but realistically, they’re not hurting my bottom line. The reason you’re here, reading my posts, is because I’ve reached you. Either you read my social media outlets, my RSS feed, or you know me and follow me directly. But the people who are going to read this, you, are here because of work I’ve already done. The work I continue to do keeps you here, and you become my promoters. The only thing the thieves do is hurt my search engine rankings, and not even that in my experience. A brand is more than just your work. It’s you, your image, your representation. Spending all your time worrying about your SEO ranking means you’re missing the point. Of course a high result on a Google Search is important, but that’s just one piece of the pie.

Someone is bound to tell me that all of this is nice and dandy, but why, technically, is it a bad idea to try and protect your media/data?

Disabling right-clicks prevents people from being able to download your media. If I then view the page source, I get the URL of your image, load that into a new browser window, and download your stuff. Or I can drag-and-drop the image to my desktop, if you disable view-source. Those don’t work? Why not check the cache of what my browser automatically downloaded when I visited your page? Or how about a screen shot of what’s active on my screen right now? That’s all stuff I can do without even needing to be code-savvy.

Google for “download image when right click is disabled” and you’ll get millions of hits. There’s no way to protect your media, once it’s online. The best you can do is to brand it in such a way that even if someone does get a copy, it is permanently marked as ‘yours’. Watermarks are the normal way to do this and probably the only ‘good’ way to do it, as they tend to be the hardest thing to remove.

Don’t bother disabling right-click, or trying to stop people from downloading/stealing your stuff. Don’t put it online unless you’re willing to have it nicked. Make your brand identifiable with your site, and people will know to come to you.

31 January, 2011