FreePress Blog

Every time Facebook changes its look, I’m reminded of how the things people post online are not really an adequate (or at least not complete) reflection of who they are or what they care about.

There are always tons of posts about whatever FB change has just occurred, even from people who rarely post. I don’t want to call it whining, but a decent percentage of them are usually stating that the change has negatively impacted them in some significant way. If measured by these attributes (posting frequency / percentage and degree of emotion or conviction) their “relative” degree of interest in the FB UI would seem to be high.

Thankfully (hopefully), we can be sure that for most people it can’t really be that important to them relative to all the other stuff in their lives; it’s just that they just choose not to post much about those other things for various reasons.

Food for thought…

As tempting as the Kindle (and now the competing B&N reader) are as alternatives to paper books, it’s really frustrating how much they’re hindered by DRM issues.

They’ve both recently released reader applications for the PC (meaning – for them – Windows only, and soon for Mac), but no equivalent versions have been announced for Linux. I can only assume that this is because they are afraid that the Linux OS will allow for easier hacking / working around the DRM features of the app. While this is probably true, it’s a frustrating reminder that these guys haven’t learned the lessons that the music industry already spent a lot of time and effort trying (unsuccessfully) to ignore / avoid.

This case in particular is doubly frustrating, because the original devices themselves (Kindle and the B&N Nook) are both actually based on Linux themselves, so their software certainly would work in Linux, if they chose to allow it.

This leads one to believe that the hardware almost certainly employs a tactic that has become known as “Tivoization“, a practice that exploits a loophole in earlier versions of licenses like the GPL, which has been addressed in v3 of that license. The term was coined because of the Tivo hardware, which used Linux as a base and therefore was required to be released under the GPL, but the hardware itself imposed constraints designed to prevent the running of any modified software, even though the modifications had to be allowed under the license.

The same probably applies to the Roku Netflix player, which supports instant watch streaming and is also built on Linux, while at the same time Netflix does not support a player for general purpose Linux use.

While the Kindle reader app will work on Linux under WINE (just verified it now on my system), I’m really hoping these guys will eventually “see the light” and stop doing this kind of thing. I think the best hope on this front is currently Android. As it continues to gain ground, I hope that the pressure to release a reader app on that platform will allow them to overcome these hesitations.

Summary

A quick lesson in the importance of consistency of meaning in terms you use on your site. Doing things like this skews the meaning of those gestures by the user and therefore makes them (and to some degree, the site itself) less valuable.

Details

I heard an announcement on the gdgt podcast today (an old podcast, but I just heard it now, so no grief about “old news” please) about a promo they are running where users can try to win a blackberry phone from a pool of phones (two models) they are giving away.

It’s a fine enough idea for a contest, but the problem is that the way you enter the contest is to log on to the site (gdgt) and add one (or both) of the devices to your “want” list. I see this as a mistake, since (as a user) your lists of devices on that site (“Have”, “Want”, etc.) form the core part of what the site is about.

Having people indicate that they “want” one or both of these phones (in order to enter the contest to win them) seems like a major mistake, because lots of people will indicate that they “want” the phones even though it isn’t actually a true measure of whether they really “want” it, relative to the criteria they’re using for marking other things on the site as “wanted”. By doing this, it is (IMHO) polluting the meaning of a term that seems like it should be very important within their system.

The counter argument is that if you don’t really want it then don’t enter the contest, but that is a bit silly as well. There are wide variations of what want could mean; the important thing is to keep that meaning consistent (for a given user) for their use of the site. As an illustration, I don’t “want” either of those phones. I definitely wouldn’t plan to buy them now or in the future (one possible interpretation of “want”), and I don’t even think I’d pick them up if I had enough cash to make the cost irrelevant (another possible definition), although I would gladly accept one for free (the only definition that applies in the case of the contest).

What do you think?

I’ve mentioned this a few times in conversations, so I’ve been meaning to do a blog post on this for a while, but I really wanted to tidy up the theme before I got back into posting more, so now that I’ve done that, here goes…

This is an example of how to use the “externals” feature of Subversion in order to simplify the maintenance of your software project when it contains references to other libraries or projects that are hosted on their own repositories, and you want to keep them all updated from their respective sources without having to do any tedious copying / exporting, etc.

This particular long, rambling example will use a somewhat typical WordPress installation, with a couple minor organizational tweaks to keep things simple and clean.

Working Backwards

I’ll start by laying out what the end result will look like, and then walk through the steps of how to get there.

The goal in this case is to have a single SVN repo (under your control) which you can use to manage your complete package (in this case a WP install), but internally have it contain your own stuff but also pull from several different “external” SVN repositories (WP core + various separate plugin and theme repos) that you don’t need to manage or copy things from.

The obvious benefit here is that you end up with a single SVN source that you can put on your server(s) with a single svn co http://your.repo.url and keep updated with a simple svn up or svn switch http://your.repo.url/tags/1.2.3 if you use tags to manage your releases (which I recommend, but that’s a topic for another post).

Basic Directory Structure

This is the part that may be a bit different than you’re used to, but I find this structure to be much easier to work with when doing stuff like this, and recent versions of WordPress have supported this (moving wp-content and wp-config.php somewhere other than their standard locations) for quite a while.

So assuming we’re starting with a blank directory that is a local checked out copy of your trunk/ directory, here is what the end result will look like once we’re done (just so you’re ready). Assuming we’re under something like /var/www/yoursite/, you’d have three items in that directory:
*NOTE: See this comment below about making sure you start with an empty dir, and that the local target dirs you reference in externals do not exist before SVN creates them by loading the external.

core/
wp-content/
wp-config.php
Where

• core will be a copy of the WordPress core files, linked via an svn:externals reference to the latest tagged release of WordPress, and fetched automatically from their servers. This is the dir that your apache vhost should map to as its root.
• wp-content is where all your themes and plugins (among other things) will go. This will contain a mix of plugins and themes from other sources (via svn:externals) plus whatever themes and plugins we add to this repo itself.
• wp-config.php This will be a copy of your WordPress config file. I usually keep it on it’s own out here, and exclude it from the subversion repository by adding it to svn:ignore. That’s perhaps another post for another time, but I just don’t add it to the repo since my local and server passwords are different, and I don’t want either sitting out in a repo that I may or may not want to make public at some point. Also it helps to stick to the rule that you don’t need to modify any files (other than .htaccess) under the core directory.

OK, so far so good. If you are not cool with that project layout, it’s possible to use other structures, but I wouldn’t recommend it, and won’t answer any questions supporting it.

Step by Step – How To Get There

So, starting in a blank directory (checked out copy of your trunk, which should be empty at this point), first you want to set your SVN_EDITOR if you haven’t already.
export SVN_EDITOR=vi, substituting vi for your text editor of choice.

Step 1 – Core WP files

Within this directory, type the following command to add the first external reference to WordPress itself:
svn propedit svn:externals .and add the following (single) line of text:
core http://svn.automattic.com/wordpress/tags/2.8.2then save and close the file.

To get a preview of the magic now at work, go ahead and check in your changes and then update:
svn ci
svn upYou should notice that when your local copy goes to update from your SVN repo it now also knows to go pull down the contents from the Automattic WP repo you linked to and put them in a directory called “core”.

Step 2 – wp-content

Now that we have the core dir handled, we want to make a wp-content dir, under which we’ll put all of our custom content, in addtion to other external plugins and themes.

Again assuming you are in the same directory as above (which should now only contain the “core” directory, issue the following command to get a clean copy of the wp-content that was retrieved from WP:svn export core/wp-content wp-content* Do not just do a normal copy here, because that will copy the SVN info from the dir as well, which will screw you up.

Now we’ll add a couple themes from other external repos. svn propedit svn:externals .and append the following two lines of text (after the existing core line):
wp-content/themes/redoable-lite http://svn.automattic.com/wpcom-themes/redoable-lite

wp-content/themes/sandbox http://sandbox-theme.googlecode.com/svn/trunkthen save and close the file.

svn ci
svn up and we will see that those two themes right where they belong inside of our wp-content directory.

I could make this post even longer by illustrating linking to additional external plugins, etc., but it would work the same way as what I just did for themes. I’m sure you’ve got the hang of that by now.

All your other changes within this wp-content directory (your own themes and plugins, etc.) will be handled just like you’re used to with SVN; it’s just that now you’ll also have other content in there that you don’t need to manage yourself.

Step 3 – wp-config

This step isn’t strictly related to the svn:externals thing, but you’ll need it in order to follow the structure I laid out above.

cp core/wp-config-sample.php wp-config.php This is now your official config file, and you’ll need to edit it as normal to point it at your database, etc.

WP is smart enough to find this file here (assuming you don’t have one under the core dir), but you’ll also just want to add an entry in that wp-config file to tell it to use the alternate wp-content directory we were working with in step 2, instead of the one under the core directory. In wp-config, add the line:
define( 'WP_CONTENT_DIR', '/var/www/yoursite/wp-content' );
Depending on your configuration, you may or may not also need to add an entry for ‘WP_CONTENT_URL’, but I wouldn’t bother with that unless you find you need it. You may also want to add Alias /wp-content /var/www/yoursite/wp-content to your Apache vhost config as well.

Upgrading – AKA The Payoff

I should start by clarifying that I do not use the built in WP updating mechanisms for core WP or plugins, because I prefer to manage everything from SVN this way.

I find it easier to work with anyway, and it also has the added benefits of supporting more restrictive file permissions on the server, as well as allowing you to work with and test a local copy that you know is exactly the same combination of core files, plugins, etc. as what you will eventually put on your server, because you are pulling it all from the same place: your SVN repo.

Let’s say WP releases 2.8.3. You will simply svn propedit svn:externals .and change the URL reference for the core dir to point to the 2.8.3 release:
core http://svn.automattic.com/wordpress/tags/2.8.3then save and close the file. You can also change any other externals refs (plugins & themes) to their latest versions.
svn up will then update your local copy with all the latest references from your external sources. Test everything out locally, and then once you are happy svn ci and your latest config is checked in, ready to be updated on your server, via svn up or svn switch.

Closing Remarks

If you’re more of a hands on learner and want to follow along but also explore a reference, here is the trac view of the trunk of the repo I was using as a demo for this article, and the corresponding SVN repo itself as well.

Thanks for taking the time to read this (assuming anyone got this far). Any questions?

Pay no attention to that post that may have shown up in your feed readers…

While working on my theme a bit last night, I accidentally posted an unfinished draft post that I had been working on (and put on hold) about using svn:exnternals. Sorry for any confusion; I’ll finish that one up shortly.

To Block, or Not to Block?

I’m going with “block”.

Twitter recently went through a round of cleaning up spam accounts, and a lot of people have noticed their follower counts dropping because of it. That inspired me to take another list at the “people” following me, and weed out several more that Twitter hadn’t deemed as “spam”, although I think they may have understandably been trying to be conservative for fear of trashing a “real” account.

No harm, no foul?

In the beginning, I was of the opinion that it didn’t matter too much to me if these other people (or bots, etc.) wanted to follow me, because I still wouldn’t see stuff from them unless I followed them in return. That position is still pretty much true, in that their actions don’t ever really impact my day to day use.

The one issue that changed my mind and made me think that it might be a negative thing to “allow” these kinds of followers is that search engines may index those links, and give their Twitter account “link juice” by following it from my page. It’s not clear whether this happens or not, but I’d prefer to avoid being a part of it just in case.

So, how to decide?

I basically just went through and cleaned up (blocked) any followers who appeared “spammy”. I give a free pass to anyone I actually know, and in a few cases some local businesses that I’m OK with giving whatever benefit they may get from following me.

Other than those, I just try to decide whether it’s a “real” person with a genuine interest in following me, and if not, I axe them. Some of the indicators I use for “blocking” criteria are:

• Following tons of people without reciprocation (“following” count is way higher than “followers”)
• Primarily “marketing” related content (usually web / social network “experts”, etc.)
• Majority of their tweets are just links promoting their own web site / blog

There are probably others, but that covers a good deal of them. In rare cases, I’ll see a person I don’t know who seems “normal” enough, so I give them the benefit of the doubt that they’re honestly interested in following my posts, so I’ll usually leave them.

What Do You Think?

I’m curious to hear how other people go about making this decision, or whether you’re in the “who cares” camp and let anyone follow you.

Now that I’ve gotten my list paired down, I think I’m going to be more careful about weeding out every new follower, blocking them immediately if they seem suspicious according to my standards.

This topic started as a comment thread on Google Reader, on a post about a web application being built on top of WordPress as a “platform”.

I don’t want to call out the specific project or post in question, because the point of this post is to educate, not to slam or put down any particular person or application. It’s sufficient to say that the core of the application was unrelated to blogging or content management (which is what WordPress can be a good base for, BTW).

Ground work

Even if you haven’t heard of the Golden Hammer anti-pattern before, it’s very likely you’ve heard some variation of the quick summary of what it means: “if all you have is a hammer, everything looks like a nail“.

This is unfortunately a common pitfall in the software development world. It has many variations, but one of the most common comes in the form of a developer being overly familiar with a certain tool or system (often to the neglect or even exclusion of any others). Since the developer is so familiar with the particular thing in question, he begins to see all other future possibilities in the context of that thing he is most familiar with, and it will lead him to choose it for tasks where it may not be the most appropriate.

Like I said, this one is very common – common enough for it to earn its place as one of the most well known software development anti-patterns. This means that it is widely recognized and regarded as a bad practice by most people who know what they’re talking about in a particular field.

To WP or not to WP?

In light of that, only one question remains: is creating an application that is not primarily (or even peripherally) related to content management or blogging by building it on top of a blog/CMS product/platform a case of this anti-pattern, or not?

I would argue that it is.

Exhibit A: WordPress Itself

If you’ve been around the core WP dev scene for long enough, you will have seen innumerable requests or proposals that this or that feature be added to the WP core. What is the usual, default answer, unless an excellent case can be made for why it fits? That’s right: “no”, or sometimes more politely, “do it in a plugin”.

There is a very good reason for that policy, and it’s basically a recognition of the principles that my argument here is based on. The idea is that anything that is added to the WP core increases the overall complexity of the system, and that is a very expensive proposition when you want maintainable code in the future. It increases the burden of maintenance as well as diluting the focus of the development effort.

Since maintainable code is essential for being able to quickly fix bugs, add new features, improve performance, and virtually every other change you will inevitably want/need to make to successful software, its importance cannot be overstated. For this reason, Matt and the other core devs will quickly turn down any feature proposal that is not essential to the core purpose of WordPress as a blog / CMS system, and they are very right to do so.

Do Likewise

You should take the same approach with your software. You should vigorously oppose the inclusion of peripheral code that is unrelated to the core function of your system. Basing your application on an entire codebase that is largely unrelated to your application’s core purpose is essentially the exact opposite of this approach.

“Platforms” vs. …

One of the biggest things (IMHO) that drives people towards building things on top of WordPress is that it’s talked about and considered to be a “platform”. There is certainly truth to this; WordPress can be a pretty good platform for building a CMS-style application on, since that’s what it’s meant to be.

Of course, the problem arises when people confuse “platform” to mean something you can build anything on / with. That usually isn’t the case, and it certainly isn’t for WordPress in the case of applications that are not primarily CMS or blog focused.

The issue is that the developers of WordPress regularly make important decisions regarding the structure of their code. They make these decisions with the driving goal of what will make it the best blog / CMS product / platform, and any other considerations are justifiably ranked extremely low or ideally discarded.

This is a huge issue if you’re trying to build an application (not a blog or CMS) on top of WordPress, because you will find yourself constrained by those decisions, when they often will not (because they should not) be made to facilitate you doing something unrelated with the codebase. You will find yourself working around parts of the system that are rightly designed for their intended purpose, when you are trying to use them for something else.

You will find yourself being required to update your code in response to updates / changes made in the base platform that are unrelated to your core functionality or to patch security issues that your product should never have had, but it has inherited them. You will have to look at every potential new feature or change you make through the filtered view of “what’s the best way to do this within WordPress” as opposed to “what’s the best way to do this”.

… “Frameworks”

Don’t get me wrong, constraints can be a good thing. They are great when they are at the appropriate level of abstraction. This is where frameworks come in. Things like Ruby on Rails (or the PHP clones like Cake) will impose opinions / constraints on how you write your applications as well, to varying degrees.

The difference is that frameworks like those are designed to have general purpose applications built on top of them. They will often handle the “plumbing” details like data access, etc. so that you can focus on writing the actual application code necessary for your application without being burdened by unrelated concerns. Platforms like WordPress, on the other hand, are existing applications that are built to be extensible within the scope of what they’re designed to be.

Can you, by looking hard enough through the WP goggles, find a way to map the unrelated features of your application to what WordPress provides, and only write new stuff or workarounds when you really, really can’t squeeze and make it fit? Sure, with the right hammer you can bang those square pegs into round holes all day long. The problem is that at the end of the day, the square pegs get pretty thrashed.

Wide Is The Road That Leads…

… well, you know where. The fact is that PHP is a very easy language to learn quickly, and modifying WordPress (via themes or plugins) has become a popular first step into web development. There’s nothing wrong with that, but there is a dangerous side to it.

Just because something is easy and/or quick does not make it the right technical decision. For an example web devs can relate to, dragging and dropping stuff onto web pages with MS FrontPage was a pretty easy thing to do for a lot of people who had no knowledge of HTML, CSS, web standards, etc. Why should they take the time to learn about all that stuff when they can be publishing their own web sites from the comfort of their WYSIWYG editor?

Of course, I think most web designers with any degree of experience would advise those FrontPagers that if they really wanted to make good pages / sites, they should take the time to learn more about the underlying technology and the other options available to them, knowing that along the way they will learn why FrontPage is evil.

In a similar vein, I would propose that people who are considering building their decidedly non-CMS app on top of WordPress take some time to expand their horizons. Maybe even build an app or two outside of WordPress, explore the other frameworks and lower-level components available for handling some of the stuff you’re depending on WP for (user management, etc.) and then come back and make a more educated decision on the best approach for your project.

I got an e-mail today from someone who noticed that my old Top Commenters plugin had been included as a target in some automated tool that searches for WordPress blogs that allow for links to be posted for the purpose of SEO manipulation.

There are a couple mitigating factors explaining why I don’t plan to do anything about it.

1. I don’t update / maintain this (or, currently, any other) plugin anymore.
2. It was only very early versions of the plugin that passed the commenter URL through to the “Top Commenters” list (this is the nature of the “exploit”). As of a version released in December 2006, it only uses the URL of registered users.
3. Even if it hadn’t been “fixed” years ago and I felt the need to issue an update to address the “problem” now, these people have obviously gone without updating this plugin for years, so it’s extremely unlikely that any of them would apply this one.

I’m interested in other thoughts as to what (if anything) I could / should do about this news.

UPDATE – I do not plan to link to the “tool” here, for obvious reasons, but I did see the page that displayed it, explained the “hole”, and even included a YouTube video showing how to find vulnerable blogs. At least they’re trying to be professional about it, I guess.

The look of this blog has been bugging me for a while, so I finally got around to doing something about it.

I think the main problem I perceived was that there was just way too much “stuff”, so I started from scratch and got rid of everything I deemed “expendable”, and tried to be pretty strict about it.

It’s still a work in progress, and I haven’t even looked at it in any browser other than Firefox yet, but I’m liking it a lot better already.

This is an open letter to the grumpy old guy in seat 17C on today’s US Airways flight 115:

In case you don’t remember your seat number, you were the guy who was sitting in the aisle seat next to a dad and his son (in 17 A & B), and the kid’s mom was seated in front of you (16C). They got a bad break and weren’t able to get seats next to each other, presenting you with a great chance to help them out.

I was in the unfortunate position (across the aisle in 17D) to be able to observe this incident but unable to offer any help – that was your unique opportunity. Let me refresh your memory, since I’m guessing you didn’t even give it a second thought…

Giving you the benefit of the doubt that the thought hadn’t occurred to you, the flight attendant suggested that you switch seats with the mother in front of you so that they could be together, since her seat was identical to yours: an aisle seat in the very next row ahead of you.

You looked up from your book and asked if she could move you to first class. Good try, BTW, but since US Airways is really trying to push selling those upgrades at the gate, that was unlikely to happen. Can’t blame you for trying, but the shocking part was when the attendant said she couldn’t do that, and you told her that you “liked the seat you had”, and that you were totally unwilling to consider trading.

Fortunately for the family, the plane was not completely full. In fact, it was just full enough to contain people with hearts and a shred of decency that were willing to shuffle around until there was a whole row open that the family of three could be moved to.

In the end, you ended up with the whole row to yourself, since the boy and his father had moved to the space everyone else made for them. Congratulations, although you may want to ponder the significance of those two empty seats next to you as a metaphor for your life in general if you continue to treat people that way. Here’s hoping you consider something better next time…