Otto on WordPress

Just a quick note to state this as a fact, in case anybody was wondering (and since I’ve had a few emails about it lately).

Under no circumstances will I ever implement Facebook’s “frictionless sharing” in Simple Facebook Connect. If you want such a thing, I recommend using another plugin.

Facebook’s frictionless sharing is a privacy invading, oversharing, useless-result creating nightmare. I block websites that use it from appearing in my News Feed, I remove Applications and services that implement it (hey Yahoo!, you’ve been axed from my life entirely because of your use of this crap), and I will not help anybody to implement it or even provide them with useful advice.

In my opinion, this is by far the worst thing Facebook has ever created. Even if you ignore the privacy implications entirely, Facebook has finally succeeded at doing something that they have been trying to do for ages: Make Facebook’s main feed almost completely worthless.

I will continue to add other features to SFC, but I use FB a lot less than I did before (and am now focusing more on Google+ anyway). However, this is one “feature” that I will not be adding.

Oh, and I’m not the only one who thinks this idea sucks rocks, BTW.

http://news.cnet.com/8301-31322_3-57324406-256/how-facebook-is-ruining-sharing/
http://www.theatlantic.com/technology/archive/2011/09/why-the-new-york-times-isnt-using-facebooks-frictionless-sharing/245880/
http://technorati.com/blogging/article/facebooks-frictionless-sharing-causes-friction-among/
http://news.softpedia.com/news/It-Took-Two-Months-but-People-Finally-Realize-that-Facebook-s-Auto-Sharing-Is-Creepy-235716.shtml

/rant

I’ve been hosting my sites on GoDaddy for years, despite everybody saying that they suck and so forth. I’ve even defended them. Their interface is crap, but it’s not terrible once you get used to it. It works well enough. Their shared servers are indeed overloaded, but with a little super-caching they tended to work alright. Their new cloud hosting service is definitely faster.

But if there’s one thing I can not stand, it’s censorship.

I recently discovered that a couple of old posts of mine about decoding code used by hackers were no longer loading up. Everything else worked, but not those posts. I couldn’t even pull them up in the WordPress post editor.

After some trial and error and back and forth, I discovered that any HTTP or FTP request that contains the string “eval(base 64_decode(” or similar variants, is blocked. FTP just stops dead, as does HTTP requests, with a continual spinning loading icon. Apparently they have some form of filtering in the TCP stack somewhere that just stops those connections dead in their tracks.

(BTW, the irony here is thick. GoDaddy’s malicious code scanner was blocking my “Scanning for Malicious Code is Pointless” post.)

GoDaddy… guys, I loved your service in the past, but I have to tell you that this is a *shit* approach to security.

After some tweeting back and forth, I found out from the horse’s mouth that this is intentional and cannot be disabled.

@Otto42 Ya we keep that disabled for security purposes. Sorry for any inconvenience this may cause. ^C

— Go Daddy (@GoDaddy) October 8, 2011

@Otto42 At this time you can’t disable it on our shared environments. You can on our Vded and Dedicated servers. ^C

— Go Daddy (@GoDaddy) October 8, 2011

And as much as they’d like to claim this isn’t censorship:

@Otto42 @heykatieben We aren’t censoring posts, the issue is that you are running into a technical limitation of our shared environment.

— Go Daddy (@GoDaddy) October 8, 2011

Guys, you’re wrong. It is censorship. I wrote that post content, and they’re refusing to serve it over HTTP. You can spin that any way you like, but GoDaddy hosting is now censoring me.

What’s more, this is a *new* problem. Those posts worked fine when I wrote them. What changed? I dunno. I did move to their 4GH hosting, but nowhere did I see in the documentation that they would be intentionally blocking my content.

Anyway, I’ve worked around the problem for now with a plugin to add spaces to the proper places in my HTML content, thus bypassing their filter. However, in the long run, this will not stand. GoDaddy thinks it’s okay to block my personal content. I disagree with them, and no amount of argument is going to make me change my mind on this topic. Blocking my own content from being served is NOT a security measure.

As you might be able to tell, I’m a bit angry.

Therefore, I am now looking for a new hosting service. Some requirements of mine:

• Traffic-wise I serve about 6000 page views a day, all told. In terms of total HTTP requests, I’d say somewhere around 30,000 or so.
• Bandwidth tends to be in the 1.5 GB per day range. So, 50 GB per month, say.
• Obviously, any form of censorship or technical limitations is unacceptable.
• SSH access is a must-have.
• I don’t necessarily need dedicated hosting or virtual dedicated hosting, shared is fine if it can handle it.
• Speed would be nice. GoDaddy has always sucked in terms of time-to-first-byte. Their cloud hosting made it better, but not great.
• MySQL Databases. I need at least 10 of them.

So, not too heavy requirements, I’d say.

I’ve heard suggestions for DreamHost in the past, and A Small Orange has always gotten favorable reviews from people I’ve talked to, but what the heck, might as well solicit the opinions of the internets in general, yeah?

Suggestions are happily accepted. If you can provide estimated pricing or links, I’d love to take a look at them.

Seen this a couple of times on various sites and had a couple people ask me on Twitter about it.

Starting October 1st, Facebook will start requiring two new things:

1. OAuth 2.0 support. SFC has this in version 1.1, which will be released shortly (tomorrow, probably).

2. Canvas and Page Tab Applications will require HTTPS/SSL support.

Both of these are true.

However, some people are interpreting that second one to mean that you need to buy an SSL certificate for your own domain to use Facebook Connect type of functionality, like my plugin Simple Facebook Connect provides. This is false.

A “Canvas” application is one that runs on your site, but shows up on http://apps.facebook.com. A “Page Tab” application is similar, but can show up anywhere on the facebook.com website, depending on how it’s written (it makes a “tab” for somebody’s “Page”). Both of those have something in common: Your website’s contents are actually showing up on *.facebook.com.

Simple Facebook Connect does neither of these things. SFC is a way for you to integrate Facebook connection functionality back into your own site. It can publish stories to Facebook, it can let users comment using Facebook, etc., but the whole point of it is to take things from FB and put them on your site. SFC does not enable your site to appear under the *.facebook.com domain name.

You do NOT need an SSL certificate to use SFC, and you will continue to not need one after October 1st.

You will, however, need to upgrade to SFC 1.1. Old versions, including 1.0, will cease to function.

SFC 1.1 will most likely be released tomorrow, and should be a painless upgrade from 1.0. Sorry for the delay.

Have you ever looked at the add_action function in WordPress? Here it is:

function add_action($tag, $function_to_add, $priority = 10, $accepted_args = 1) {
	return add_filter($tag, $function_to_add, $priority, $accepted_args);
}

I know, right? Some people’s minds just got blown.

What are Filters?

A filter is defined as a function that takes in some kind of input, modifies it, and then returns it. This is an extremely handy little concept that PHP itself uses in a ton of different ways. About half the string functions qualify as a ‘filter’ function.

Look at strrev(). It’s a simple-stupid example. It takes a string as an argument, and then returns the reverse of that string. You could use it as a filter function in WordPress, easily. Like, to reverse all your titles.

add_filter('the_title', 'strrev');

Some filters take more than one argument, but the first argument is always the thing to be modified and returned. PHP adheres to this concept too. Take the substr() function. The first argument is the string, the second and third are the start and optional length values. The returned value is the part of the string you want.

What are Actions?

An action is just a place where you call a function, and you don’t really care what it returns. The function is performing some kind of action just by being called. If you hook a function to the init action, then it runs whenever do_action(‘init’) is called.

Now, some actions have arguments too, but again, there’s still no return value.

So in a sense, a WordPress action is just a filter without the first argument and without a return value.

So why have them both?

Because there is still a conceptual difference between an action and a filter.

Filters filter things. Actions do not. And this is critically important when you’re writing a filter.

A filter function should never, ever, have unexpected side effects.

Take a quick example. Here’s a thread on the WordPress support forums where a person found that using my own SFC plugin in combination with a contact form emailer plugin caused the email from the form to be sent 3-5 times.

Why did it do this? Basically, because the contact form plugin is sending an email inside a filter function.

One of the things SFC does is to build a description meta from the content on the page. It also looks through that content for images and video, in order to build meta information to send to Facebook. In order for this to happen at the right time, the plugin must call the_content filter.

See, what if somebody puts a link to a Flickr picture on their page? In that case, oEmbed will kick in and convert that link into a nice and pretty embedded image. Same for YouTube videos. Or maybe somebody is using a gallery and there’s lots of pictures on the resulting page, but the only thing in the post_content is the gallery shortcode.

In order to get those images from the content, SFC has to do apply_filters(‘the_content’,$post_content). This makes all the other plugins and all the other bits of the system process that $post_content and return the straight HTML. Then it can go and look for images, look for video, even make a pretty 1000 character excerpt to send to Facebook.

But SFC can’t possibly know that doing apply_filters(‘the_content’,…) will cause some other plugin to go and send a freakin’ email. That’s totally unexpected. It’s just trying to filter some content. That would be like calling the strrev() function and having it make a phone call. Totally crazy.

Shortcodes

Shortcodes are a type of filter. They take in content from the shortcode, they return replacement content of some sort. They are filters, by definition. Always, always keep that in mind.

Also keep in mind that shortcodes are supposed to return the replacement content, not just echo it out.

Conclusion

So plugin authors, please, please, I’m begging you, learn this lesson well.

Filters are supposed to filter. Actions are supposed to take action.

When you mix the two up, then you cause pain for the rest of the world trying to interact with your code. My desk is starting to get covered in dents from me repeatedly banging my head into it because of this.

Just upgraded to the beta of 3.2. I like the new admin interface overall. Really, I do. But relatively minor things tend to bug me sometimes.

For example, I don’t much care for the Site Title being so tiny and hidden at the top of the admin screens. I like the site’s name to be big and prominent, as it’s a link to the front end of the site. On multi-site, it’s awfully nice to see at a glance what site I’m on. I often click that link to go to the front end of the site easily. So trying to navigate to the front end became difficult and hit or miss with this title being so tiny.

I also don’t like seeing the Page Title being so big and having a big ol’ icon there beside it. The Page Title strikes me as kinda useless. I mean, I know what screen I’m on.

So I wrote a quick tweak plugin to fix it. I’m posting it in case it bugs you as much as it bugs me. On a side note, it’s a quick little demo of how to modify the WordPress admin CSS quickly and easily.

<?php
/*
Plugin Name: Embiggen Site Title for WordPress 3.2 beta
Description: Embiggen the Site Title in wp-admin. Debiggen the Page headers. Ditch the useless icon.
*/
add_action('admin_print_styles', 'big_site_title');
function big_site_title() {
?>
<style>
.wp-admin #wphead {
	height: 42px;
}
.wp-admin #wphead h1 {
	font-size: 28px;
	#font-family: "HelveticaNeue-Light","Helvetica Neue Light","Helvetica Neue",Helvetica,Arial,sans-serif; #uncomment this if you want to go to the sans-serif font
}
.wp-admin #header-logo {
	background-image: url("images/logo.gif");
	background-size:32px 32px;
	width:32px;
	height:32px;
}
.wp-admin .wrap h2 {
	font-size:16px;
	padding-top: 1px;
	padding-bottom: 0px;
	height:20px;
}
.wp-admin .icon32 {
	display:none;
}
</style>
<?php
}

Feel free to tweak further as desired. Also, WordPress might change further before 3.2 is released, so this may stop working or need further tweaking.

I recently had an exchange with a commercial theme developer who changed his terms away from the GPL because of an experience with some rude person who was redistributing his themes for free. Ultimately, I wasn’t able to convince him to stick with it, but there was a clear misunderstanding of the GPL in the first place there (I suspect that language differences played some part), and I thought this might make for an interesting blog post.

(Note that I’m talking about themes, but this all applies to commercial plugins as well as any other code you’re selling online.)

It’s All About Redistribution

The main barrier to the GPL that a lot of theme developers have expressed is the right of redistribution. That is to say that if you sell me a GPL’d theme, then I can turn around and give that theme to anybody I want, for free, and you have no recourse.

This viewpoint is entirely correct, however it’s missing the big picture, I feel.

Why Would I Do That?

First off, why would I take something I paid for and then give it away to everybody else for free? I mean, it’s one thing to give a copy of something to a friend of mine for his use, but it’s wholly another to go to the effort of setting up a website to distribute your theme as some kind of “screw you” policy. Did you anger me in some way? What level of maliciousness would be necessary for me to want to do that? Seems a bit overboard, and most people are ultimately reasonable.

However, this ignores the existence of John Gabriel’s Greater Internet Fuckwad Theory. Which is to say that some people are just trolling bastards who will screw with you just because they can. So let’s say that somebody gets a copy of your themes, posts them online, then refuses to take them down despite your polite requests, and waves the GPL in your face for his right to redistribute them.

Technically, this sort of person is correct, he does have the right of redistribution. But that doesn’t really matter.

What Are You Selling, Anyway?

Let’s say I made a piece of code and sold it. No GPL, no license, just me selling code to people for their own use. They have no rights to the code whatsoever. So, somebody posts that code online, for free, at some pirate site. Somebody else downloads it, and uses it, without paying me. Straightforward software “piracy”.

What have I lost here? Well, I lost the cash that I could have made from an extra sale, true, assuming that said person would have bought the code instead of pirating it. If you know people who habitually pirate code, then you know that that is a rather dubious claim, at best.

More importantly, I’ve lost a contact point between me and the user of the code. When I sell something to somebody, then I now have a relationship with that person. I get their email address. They may contact me for support. Even paid support. I may have forums for purchasers of my software to talk amongst each other in a community support system. They may buy other things I wrote.

This is the real benefit to selling code, that relationship between me as a developer and them as a purchaser of what I develop. And I’m missing that connection, until they want support from me for my product. Then I may say “well, you’re using a pirated copy of my product, if you want to join my support forums and my community and get my help, then you have to buy the product from me”. Take note of the many times that software companies have offered “clemency” sales and such, to turn pirated copies into legitimate ones.

What it comes down to is simple:

You Can’t Stop Piracy, So Don’t Try.

Think about it, you’re selling a digital file here. Files can be copied. If I buy a copy of your software, strip out any identifying marks, then post it to a thousand torrent sites, what exactly can you do to stop me from doing that?

No matter what your terms and conditions are, people still can copy your files, distribute them, edit them, do whatever they want. Unless you’re actually enforcing your terms with (potentially expensive) legal actions, then your terms are really quite meaningless. Technical measures to stop piracy don’t work, as many game companies have found out over the years. DRM doesn’t (and technically cannot) work.

Instead of viewing people redistributing your code as a bad thing, view it as an opportunity. If somebody downloads a “pirated” copy of your code, and uses it, then clearly they have a use for it. And at some point, they’re going to want upgrades. They’re going to want support. They’re going to want modifications. So make sure that you are the person they come to, and then you have an opportunity to convert that pirated download into a real sale.

The GPL doesn’t screw the developer by allowing others to share his work. The GPL enables the developer to get more contacts (and potentially more sales) by allowing others to share his work along with his name, contact information, website, etc.

Don’t fight against the right of redistribution, make it work for you instead.

There’s been a lot of articles on this topic over the years (I even wrote one). But I’m going to tackle this from a different angle, one that I’m not used to: A non-technical one.

Fixing a website “hack” is actually a fairly heavy technical thing to do. Most bloggers are not webmasters. They are not really technical people. They’re probably people who simply purchased a web hosting account, maybe set up WordPress using a one-click install, and started blogging. In an ideal world, this sort of setup would be perfectly secure. The fact that it’s usually not is really a problem for web hosts to figure out.

But often I find that the emails/posts I see that read “help me my site was hacked what do I do” or similar don’t get a lot of help. There’s a reason for this. People who are asking this question are not usually the type of people who are technically capable of actually fixing the problem. Guiding somebody through this process is non-trivial. Frankly, it’s kind of a pain in the ass. So those of us capable of fixing such a site (and there are plenty) are reluctant to try to help and basically offer our services for free. The amount of work is high, the frustration is equally high, and there’s not a lot of benefit in it.

So, with that in mind..

Step One: Regain control of the site

By “control”, I basically mean to get the passwords back and change them. Tell your webhost to do it if you have to, and read this codex article on how to change your WordPress password even when you can’t get into WordPress. Also, change your web hosting account password, your FTP password, the database password… Any password you have even remotely related to your site: change it. Note that doing this will very likely break the site. That’s okay, down is down, and it would be better to be down than showing hacked spammy crap to the world.

And that’s another point: take the site down, immediately. Unexpected downtime sucks, but if you’re showing spam to the world, then Google is sure to notice. If you’re down for a time, then Google understands and can cope, but if you’re showing bad things, then Google will think you’re a bad person. And you don’t want that.

The idea here is to stop the bleeding. Until you do that, you haven’t done anything at all.

Step Two: Don’t do a damn thing else

Once you have the passwords and the site is offline, leave it like that.

Seriously, don’t erase anything, don’t restore from backup, don’t do anything until you do what follows next…

Anything you do at this point destroys vital information. I cannot stress this enough.

Step Three: Hire a technically competent person to fix it for you

If you know me, then you know I rarely recommend this sort of thing. I tend to offer technical knowledge and try to help people do-it-themselves. But hey, for some people, there are times when it’s just a hell of a lot to take in. Webserver security is a complex subject, with a lot of aspects to it. There is a lot of background knowledge you need to know.

If you’re reading this and you don’t know how a webserver works, or config files, or you don’t know arcane SQL commands, or you don’t understand how the PHP code connects to the database and uses templates to generate HTML, then trust me when I tell you that you are not going to fix your website. Not really. Sure, you could probably get it running again, but you can’t fix it to where it won’t get hacked again.

So, find a website tech person. Somebody who knows what they’re doing.

(BTW, not me. Seriously, I’ve got enough to do as is. Just don’t even ask.)

How, you ask? I dunno. Look on the googles. How do you find anybody to do anything? There’s several sites out there for offering short-term jobs to tech wizards. There is the WordPress Jobs site, but note that I said you need a website person, not necessarily a WordPress person. A lot of people who know WordPress don’t know websites and security… Although many of them do and this is not an indictment on the community, it’s more a recognition of the fact that working with servers and websites in general is not really the same thing as working with WordPress. WP knowledge is useful, but generic server admin experience is much, much better in this situation.

And yes, I said HIRE. Seriously, pay up. This is a lot of work that requires special knowledge. I know that a lot of people try to run their websites cheaply and such… Look here, if you’re paying less than $300 a year to run a website, then why bother? How serious are you about your website anyway? Quality web hosting should cost you more than that, hiring a specialist for a short term day-job is going to run you a fair amount of money. Expect that and don’t give him too much hassle about it. Feel free to try to argue on the price, but please don’t be insulting. Offering $50 to fix your site is unfair, as that’s less than an hour’s pay for most consultants, and you need one with special skills here. This is a minimum of a day’s work, probably longer if your site is at all complicated. Just getting it running again without doing everything that needs to be done is probably a 4 hour job. Sure, somebody can hack together a fix in half an hour, but do you ask your automotive guy to just throw the oil at the engine until it runs? Have some respect for the fact that knowledge and skill is valuable, in any profession.

Basically, here’s what the website guy will be doing, if he knows his business.

First, he’ll probably backup the site. This includes the files, the databases, any logs that are available, everything. The idea is to grab a copy of the whole blamed thing, as it stands. This is a “cover-your-ass” scenario; he’s going to be making large scale changes to the site, so having a backup is a good idea, even if it is a hacked one. The person will need all of the relevant passwords, but don’t give them out in advance. He’ll ask for what he needs from you.

Second, if you already have regular backups (please, start making regular backups… VaultPress is invaluable in this situation and can help the process out immensely), then he’ll probably want to restore to a backup from before the hack. And yes, you very likely WILL lose content in this restoration. However, since there is a backup, the content can be recovered later, if it’s worth the trouble.

(Note, if you don’t have any backups, then he’ll try to remove the hack manually. This is error prone and difficult to do. It also takes longer and has a much lower chance of succeeding. It’s also difficult to know that you got everything out of the site. If anything is left behind, then the site can be re-hacked through hidden backdoors. This is why regular backups are critically important to have.)

Third, he’ll update everything to the latest versions and perform a security audit of the site. This means looking at all the plugins, themes, permissions on the files, the files themselves, everything. This is to make sure all the main security bases are covered and that it doesn’t get rehacked while he does the next step. They may talk about “hardening” the site.

Fourth, from that backup he made earlier, he’ll likely try to trace where the hack started from. Logs help here, as do the files themselves. This is kind of an art form. You’re looking at a static picture of a dynamic system. And unfortunately, he may not even be able to tell you what happened or how the attackers got in. Attackers often hide their traces, especially automated tools that do hacking of sites. With any luck, the basic upgrades to the system will be enough to prevent them getting in again, and a security audit by a knowing eye will eliminate the most common ways of attackers getting in. That often is enough.

Step Four: Prevention

Once your site is fixed, then you need to take steps to prevent it from happening again. The rules here are the same rules as any other technical system.

• Regular backups. I can’t recommend VaultPress enough. After my site went offline for a day due to some issues with my webhost (not a hack), I lost some data. VaultPress had it and restoring it was easy. There’s other good backup solutions too, if you can’t afford $20 a month (seriously, don’t cheap out on your website folks!).
• Security auditing. There’s some good plugins out there to do automatic scans of your site on a regular basis and warn you about changes. There’s good plugins to do security checks on your sites files. There’s good tools to check for issues that may be invisible to you. Use them, regularly. Or at least install them and let them run and warn you of possible threats.
• Virus scanning. My website got hacked one time only. How? A trojan made it onto my computer and stole my FTP password, then an automated tool tied to that trojan tried to upload bad things to my site. It got stopped halfway (and I found and eliminated the trojan), but the point is that even tech-ninjas like me can slip up every once in a while. Have good security on your home computer as well.
• Strong passwords. There is no longer any reason to use the same password everywhere. There is no longer any excuse for using a password that doesn’t look like total gibberish. Seriously, with recent hacks making this sort of thing obvious, everybody should be using a password storage solution. I tried several and settled on LastPass. Other people I know use 1Password. This sort of thing is a requirement for secure computing, and everybody should be using something like it.

These are some basic thoughts on the subject, and there’s probably others I haven’t considered. Security is an ever changing thing. The person you hire may make suggestions, and if they’re good ones, it may be worth retaining him for future work. If your site is valuable to you, then it may be worth it to invest in its future.

And yes, anybody can learn how to do this sort of thing. Probably on their own. The documentation is out there, the knowledge is freely available, and many tutorials exist. But sometimes you need to ask yourself, is this the right time for me to learn how to DIY? If you need quick action, then it might just be worth paying a pro.

I have been trading email with several people recently, talking them through some webhosting stuff, and I just discovered how prevalent this practice was. I should have guessed it when I wrote a post about it earlier, but I didn’t know everybody was doing it this way. Most people I talked to didn’t realize there was any other way.

So it’s worth another look, I think.

Note that this post covers some basic fundamentals to start with. If you already grok DNS, you can skip ahead to the “How to Point a Domain at a Webhost” bit. For now, I’m going to use the word “server” a lot.

Why DNS is Important

So you bought a domain name for a few bucks. That’s great. What nobody told you: A domain name by itself is useless.

Really. Computers cannot connect to domain names. Computers on the internet can only connect to IP addresses. So you have to have a way to convert that domain name into an IP address. The way that happens is through DNS.

DNS? How does it work?

DNS works as a decentralized system. There’s thousands (millions?) of DNS servers in the world, all talking to each other all the time. One way to think of it is as a big tree, with connections coming from the root servers all the way up through to other servers. This is the traditional approach. But a better way to think of it is as a cloud, with connections branching every which way. DNS servers talk to other DNS servers and they don’t much care where they are on the “tree”, generally speaking.

When I make a request for my site, ottopress.com, then a few things happen.

First, my computer checks its memory to see if I’ve done this recently. I probably have, in my case, so it just uses that information if it’s pretty recent. This is known as DNS Caching, and all modern systems do it.

Next, if I don’t know the address, then I know who to ask. I ask my own DNS server. Pop open a command prompt and type ipconfig /all (or ifconfig -a) . You’ll get a big listing of your IP configuration info, and some of those are your DNS servers. Those are provided by whatever gave your computer an IP address. It might be your home router, or it might be your ISP, or maybe you entered them manually. The point is that that DNS IP is where the computer connects to in order to ask it “hey, where is ottopress.com?”.

Now, my DNS server may already know the answer because it has it in memory (DNS cache again). If not, then it knows how to find out.

Firstly, it looks at the name itself. In this case, the name ends in “.com”. That’s important. This is the “Top Level Domain” (TLD), and every TLD has its own set of servers dedicated to it. Actually, there’s a set of servers called the “root nameservers“. They live at root-servers.net. They are a set of 13 servers world wide which distribute the TLD information. (Actually, there’s a lot more computers than “servers”, since each server is separated geographically. The J server, for example, lives in 70 different places. You can see all about them at root-servers.org.)

They deliver a file called the “root zone” file. In fact, this file is rather small (it will even fit on an old-school single sided 5.25″ floppy!), but it contains some critical information that describes the functioning of the DNS system. Specifically, it specifies where things like .com and .org and all the other TLDs can be serviced from. Every DNS server on the planet needs this information, and usually has it cached for a long, long, long time. The thing rarely changes.

So, my DNS server looks at the root zone file and discovers that “.com” domains are handled by some other set of servers, so it goes to those and asks it “where can I get the info for ottopress.com?”

This is an opportune moment to talk about authority.

Authoritative Responses and What They Mean

Every domain name on the internet has to have somebody in control of it. This person is considered to be the “authority” on that domain. He in turn delegates that authority to some DNS server. That server is the only one on the whole internet who knows, for a fact, what IP addresses are connected to his names.

When I get something out of the cache of any server, the result is “non-authoritative”. That is, the DNS server gave me an answer, but it cannot guarantee that the answer is the right one. A non-authoritative answer is the fast one.

Those root servers I talked about are the authorities for the TLDs. They give out the root zone file, which says, among other things, who is the authority for all “com” domains. That server, in turn, doesn’t have the faintest clue what IP address connects to ottopress.com, but it does have information on what nameserver is the authority for ottopress.com.

So my DNS server goes and talks to this new server which the .com servers have told it is the authority. And finally, THAT server says “yes, I know for a fact that ottopress.com lives at 64.202.163.10″.

So, now that it has an answer, my DNS server relays this back to me. It also caches the information, because I’m probably going to ask it again soon, and it’s quicker if it doesn’t have to go through all that again.

How to Point a Domain at a Webhost

So, when you signed up for your webhost, if you got the domain somewhere else, then they very likely told you to “point your domain’s nameservers to X and Y”.  What does this mean, exactly?

Previously, I explained how my DNS lookup went to the .com authoritative nameservers to get the nameserver information. Well, when I change my domain’s nameservers, then what I’m actually doing is changing the information on those .com servers. I’m telling them that these new nameservers are the authorities for all DNS lookups involving ottopress.com. I’m delegating my authority to those nameservers. When I do that, what I’m saying is that those nameservers are now in control over all requests on the internet that involve my domain.

Now, this normally isn’t a bad thing. Running nameservers is difficult and tricky. The syntax is arcane and strange (albeit well worth learning for your toolbox). Plus, you’re probably not in possession of all the information. After all, you hired this web hosting company to host your website for you, and they might change IPs around and such. Better for them to manage it, yes?

No.

There’s a lot of good reasons to manage your DNS yourself. For one thing, you have total control. If you want to do some tricky DNS stuff, or set up email to the domain with MX records, or things like that, then you can do so yourself. Just the ability to edit your own CNAMEs and TXT records easily is well worth it. Heck, maybe you want to get Jabber working on your domain. Who knows?

On the other hand, you have total control, and that includes total freedom to screw it up. And anyway, most web hosts have some kind of easy interface to let you add and remove specific entries yourself, so you still have some control over it.

But now we get back to the main problem, which I was talking about in that previous post. Vendor lock-in.

DNS Propagation Delay and TTL

Remember what I mentioned earlier, when your webhost said to ”point your domain’s nameservers to X and Y”? That’s the root of the problem.

DNS lives and dies by a setting called “Time-To-Live” (TTL). The time-to-live is the caching factor I mentioned several times before. When a DNS server gets some new information and stores it in its memory, it also stores the TTL, which it also receives from the other server. The TTL is a time limit on how long it can cache that information. Most DNS servers obey this value extremely well. If the TTL says to cache it for 2 hours, then it caches it for 2 hours and not a second longer.

Well, that nameserver lookup from the .com servers has a TTL too, only it’s a very LONG one. See, those second-level servers are way overloaded. Think about it, every lookup of every .com domain name goes through one server (which is actually a whole bunch of computers geographically spread out too). There’s millions, probably billions, of these lookups a day. So they offload a lot of the information. Where to? Why into everybody else’s caches, of course. The nameserver results tend to have a very long TTL, on the order of a day to a week or so (mean time is about 48 hours). Even then, many DNS servers are configured, by default, to hold these results even longer. Sometimes weeks.

This is because while the IP address corresponding to a domain name might change a lot, the nameservers for one actually rarely change. You don’t switch hosts every week, for example. But your IP might change a lot, if you’re using dynamic addressing or something along those lines.

So what happens when I change that information? Well, basically, all the other servers on the internet that have my information cached will be wrong for some period of time. That period of time is call the propagation delay, because it takes that long for my change to propagate out to the rest of the world. Those caches have to expire and all the DNS systems out there then have to ask me for the new information, assuming somebody asks them for it.

So if I change my IP, it takes a couple of hours for it to get out there, because my TTL is 2 hours. The downside to this is that when your nameserver changes, it takes a friggin’ long time to take effect.

Solving the Problem

The solution is simple: Never change your nameservers.

By that, I mean to keep your nameserver in the same place for as long as you possibly can. And this means, if at all possible, don’t delegate your authority to your web host. Instead, a better option is delegate it to your domain name provider.

I use GoDaddy for my domain names. With purchase of domain, they offer free DNS. It’s not the best interface in the world (actually it’s downright clumsy), but it works well enough. I can point my A record (that’s an “address” record, which connects names to IP addresses) to anywhere I want with relative ease. I can set my own TTL on that lookup (currently it’s 2 hours). If I were to change web hosts, my outage time would be 2 hours instead of 2 days. Why? Because all I have to do is to point my domain name at my new host, after they told me what IP address to point it to. If I instead tried to change my nameservers to theirs, then my outage would be 2 days, at least, because it usually takes at least that long for a change to the .com servers to take effect everywhere. And in some parts of the internet, that outage would be a week, at least. Minimum.

There’s also other options for owning your DNS. ZoneEdit offers both free and paid services for DNS, allowing you to point your domain to them and then controlling it all you like. This allows you to take your domain with you from one registrar to another, without having to worry about your registrar not providing DNS anymore.

Or you can even run your own DNS. That’s a super advanced topic though. Even I wouldn’t attempt that without some serious resources.

Summing up

But the point is that you want your DNS to be somewhere that it’s never going to move. Or, at least, that it’s going to move so rarely that you never have to worry about it. If I changed web hosts, it’s complex, but a simple enough matter that I could do it myself. But seriously, when am I going to move my domain names between registrars? How often does that really happen? Most people pick their registrar and stick with them forever. Unless they seriously raised the rates or something, it’s unlikely I’d ever switch them off GoDaddy.

Also, you want your DNS somewhere that you have a reasonable assurance that nobody’s going to screw with it. You own your domain, but the DNS controls where your domain goes. He who controls the DNS controls the domain, and that’s what ownership is, really. Control. Owning your DNS is the ability to control your own domains. It takes some learning, but seriously, it’s way easier than you think. More interesting too.

There’s been a lot of talk about custom post types, and I know many people are looking forward to it. Unfortunately, I think some (perhaps many) of those people are going to be disappointed. Custom Post Types might not be what you think they are.

I blame the naming, really. “Custom Post Types” makes the implication that these are “Posts”. They’re not. “Post Type” is really referring to the internal structure of WordPress. See, all the main content in WordPress is stored in a table called “wp_posts”. It has a post_type column, and until now, that column has had two main values in it: “post” and “page”. And there’s the big secret:

“Custom Post Types” are really Pages.

Sorta.

For a long time in the early days of WordPress, it just had Posts. But hey, no big deal, because it was just running a big Blog anyway, right? The Posts appeared on the Blog page (and in the Feed) in reverse chronological order. Each Post could appear on its own URL, using the Permalink structure.

Pages came along and changed that.

• Pages don’t appear on the Blog. Or in the Feed.
• Pages don’t even really have dates and times on them that usually get displayed.
• Pages have their own URL at the root of the website, outside the Permalink rules.
• Pages even have hierarchy in their URLs, if they want.

Pages, however, do live in the wp_posts table. So post_type exists to handle that. When WordPress is building the Blog, it looks for post_type = “post”.

Bring on the “Custom”.

Now we have these Custom Post Types. Or rather, custom post_types. Instead of “page” or “post”, we can have “custom”. Or “fred”. Whatever we like.

But how do these new post types get displayed? What do their URLs look like?

Well, these are custom, and they can be customized. You can give them their own space on the website. So if I want them to live at /custom/page-name, then I can. If I want them to have hierarchy, then I can do so. Justin Tadlock explains how they can be made to do this quite well.

But they are still not Posts.
They do not show up on the Blog.
They do not appear in the Feed.

This is a matter of definitions, really. See, the Blog is a reverse chronological order of the Posts. That it what it is defined to be. The Feed is basically the same thing, in feed form.

So all of you thinking of a custom “Podcast” post type, you’re in for a disappointment.

So what’s the big deal?

Well, all that said, custom types can have their own systems of doing things. They are custom, and as such, they are customizable.

If, for example, you wanted to have them appear on their own “blog” area, or in their own “feed”, then sure, that’s entirely doable. You can make a function to produce your custom feed. You can then call “add_feed” to add your feed. You can create single-type.php templates in your theme that will be used for your custom type. You could even make a “blog” out of your custom type.

And doing it the other way is possible too. You can adjust the “Blog” to show your type. You could change the “Feed” to show your type as well.

But these things are NOT the default way of doing things. There’s no code in there to do that, and there’s very likely not going to be. If you want your type in the Blog, in the Feed, then you have to do it yourself. The URL is NOT easy to customize and play around with. The rewrite system is unforgiving, and you have to stick within a set of rules for things to work well.

However, should you? Let’s say you make a “Podcast” custom type. You can go to the effort of putting them in the feeds and making them show special on the blog… but you could already do that with a “podcast” category. And it’s much easier to do a category and customize categories than custom types will ever be.

Something like 80% of the uses I’ve seen for “custom types” would be better served by making normal posts and using some existing method to separate them or to otherwise mark them as special.

So what are they good for?

What if you could install a forum on your site? bbPress is pretty good. But it could get all complicated to set up and such. Well, plugins are pretty easy. But all those forum posts have to go somewhere…

Custom Post Types is a way for plugins to define types of content for themselves.

A bbPress forum could store every post in the forum as its own custom post type quite easily.Or a wiki plugin could store each of its own pages as a custom post type. Things like that.

See, they’d get their own URL handling automatically, and they wouldn’t need weird database handling tricks.. It makes things much simpler and easier for those plugins to do their thing when they have the backend support for it in the core.

Some of you are thinking “Okay, so plugin authors can make better use of them. I won’t have to write a lick of code, I’ll just install a plugin that makes my type and handles the stuff for me.” And yeah, you can do that.

But then you’re wedded to that plugin. WordPress doesn’t know about your custom posts. If you remove the plugin, your custom posts are still there, but now they’re completely invisible. Can’t be pulled up, seen in the admin, the URLs all stop working…

Wrap it up, son…

Using custom post types right now is, for most people, a bad idea. Only specialized usages really exist for them… for now.

For the long term, WordPress will probably use them a lot more extensively. And plugins can make great use of them for all sorts of things. But you, as a user, probably don’t need to be messing with them. Not if you’re just creating a website or writing a blog. Not right now. Wait for the plugin and core development to catch up to the potential. Using them early leaves you open for a world of confusion and grief.

Never thought I’d say this… But my recommendation for people thinking about upgrading from a single-user WordPress 2.9 installation to WordPress 3.0: Don’t do it… yet.

WordPress 3.0 is such a major update, that for 95% of the single-user blogs out there, I would recommend putting it off and not upgrading at all. Not until the issues are worked out.

See, everybody is talking about the features of 3.0, and those are indeed many and varied. But not many people are talking about the problems of 3.0. And while it is only in beta, it’s not too early to consider some of the design choices here and think about them in a larger scope.

Theming

Firstly, understand that a lot of the new features require theme support. Meaning that your existing theme, while it will work, won’t give you the new menuing system, it won’t have the comment form enhancement, the new editor styling tricks won’t work, etc…

So if you’re going to upgrade to 3.0 without modifying your theme as well, you’re not going to get the full experience.

The new Twenty Ten theme, while it is neat and shows off what can be done, is very, very complicated (and IMO, it also does a lot of things very badly). It’s somewhat difficult for even an experienced theme editor and developer to understand, so expecting a normal blogger to read this as an example and then change their own theme as needed is somewhat nutty. So if you want these new features, you’ll probably need professional assistance to get it all up and working.

Custom Post Types

They’re neat, they’re cool, and they’re insanely difficult to use properly. What’s going to happen here is that people will use them badly at first. Incredibly badly. Some of the examples I’ve seen thrown around are surprising just for the sheer crazy. Yes, you can make a “Podcast” post type, but do you really want to? Does it really make sense in the context of what you’re doing? The answer is probably not, actually.

And using them changes so much internally to the system that things start behaving in ways you totally don’t expect (or see). For example, custom post types don’t show up in feeds by default. That might make your podcasting a little bit, shall we say, broken?

Now, custom post types have to be enabled by plugins and such, so those plugins might indeed take care of this sort of thing properly. But frankly, I wouldn’t want to bet on it. People are going to have all sorts of weird problems with this until they work out that they really didn’t need custom post types after all.

IMO, only a very limited subset of people need this, or think they do, and those people are very likely already using them in some manner.

Plugin incompatibility

Any plugin that deals with posts being published is likely to be affected by custom post types. And this won’t be limited to your custom posts.

I’ve already had to edit 4 different plugins I use (2 of them are mine, admittedly) because of the new menu system. It stores the menu items in it as posts with custom post types of “nav-menu-item”. So before I fixed it, making a new menu item would cause the name of that menu item to appear on my Twitter feed. Simple Twitter Connect was seeing a new post get created, and it dutifully published that fact. It simply didn’t expect a “post” to be a “menu item”.

I’ve currently hardcoded the plugins to limit them to seeing actual posts and pages, but that seems a poor solution to me. What if somebody wants to make that “podcast” post type? How is a plugin supposed to know what is really a post and what is not? Overloading the wp_posts table for storage of “not-posts” in this way is confusing and strange and it’s going to break a lot of plugins.

So at the very least, don’t upgrade until your plugins explicitly support 3.0.

Menus

The new menu system is clever, but ultimately very limited. I tried it, but I eventually opted to not use it at all.

The problem is that it’s wholly static. Every menu item is a name and a URL, basically. There’s nothing there to make dynamic menus from your content. Like my WordPress Plugins dropdown at the top of the page there. That’s generated by a call to wp_list_pages. Can’t do that with the menu system. And generating a dropdown menu of a given internal list seems, to me, to be a strangely missing piece of the whole thing.

You can make that same menu manually, but if you add a new page, you have to go and manually add it to the menu as well. And that’s all well and good for people who want to micro-manage their site. I’m sure they’ll love it. But I can’t say that I do.

Now, I have been having this argument on the wp-hackers list, so it’s entirely possible that the final release will address more than a few of my above objections. So plugins might be created to fix this issue. Hell, I might create a few of them myself. But in the end, I still find that the underlying design is fundamentally flawed. The system stores menu items as metadata attached to fake posts. In my opinion, that’s just nine kinds of crazy. They should have leveraged the existing widgets system instead, and perhaps have made a new table to hold widget and menu item data together (thus solving the widget data problem and having a place to put menu-items all in one shot). Not everything should be a post.

Multi-Site

Okay, yeah, Multi-Site is damn cool, for those of us that run more than one site. But it’s got issues too. Mainly, it’s just complicated.

It’s complicated in that there’s several types of choices to be done. You have to know server configuration. You have to understand DNS and static IP addressing. Knowledge of Apache and VHOSTing helps. And if you’re using multiple domains, which seems like a rather common setup, then you’re into mu-plugin territory, which is wholly new to anybody familiar only with WordPress and not WordPress MU.

Setting up Multi-Site for my two domains required the following steps:
1. Move WordPress to the root of my domain (it really doesn’t work in a subdirectory. Just trust me on this).
2. Enable multisite by editing wp-config.
3. Enable it in the interface, making choices that I didn’t understand. The difference between a subdomain and a subdirectory installation is not immediately apparent, and later turns out to be wholly irrelevant when you use the Domain Mapping plugin anyway. Answer for everybody else: Subdirectory is simpler and requires less configuration, subdomain only works if you have more server control than the average cheap hosting account gives you (static IP, wildcard DNS, VHOST, etc).
4. Copy and paste a whole bunch of stuff that WP spits out into my wp-config and htaccess files.
5. Install the Domain Mapping plugin (manually install, you can’t do this through the happy plugin install interface, because it requires putting files into various directories).
6. Configure the mapping. This is confusing at first, because after you get it working and give it the server IP, you have to actually go to each site’s individual wp-admin in order to map it to a domain. Not hard, but very unclear. Oh, and before you map the domain, make sure that the domain is actually pointing to your server IP, because the mapping takes effect instantly, with no way to undo it. I had to manually edit my database to undo it after I screwed this up the first time.

After all that, there’s still a few bugs. Minor stuff though. The links on dashboard on the main site aren’t quite right. My main site shows individual posts in the /blog directory, with no real way to remove it (it’s hardcoded and deep in the heart of things there’s probably a good reason for it, but it’s still annoying). There’s some other limitations which are too boring to go into.

BTW, if you’re already running MU, then go nuts. This upgrade is perfect for you. It’ll get you onto the main line and that is more important than anything I’m talking about here.

Note that I’m not sure that this is fixable. Multi-Site is complicated by its very nature. Integration of Domain Mapping into the core would help make this a lot simpler and would have the side benefit of eliminating the unnecessary subdomain/subdirectory choice. But ultimately, you do have to have some server-side config to make this sort of thing work, and that’s never going to change.

Not everything is bad

Don’t get me wrong, there’s lots and lots of good stuff here. The Shortlinks API is great. The plugin and theme updaters have been enhanced and moved around proper. A lot of the new theme stuff like the header trickery and the automatic-feed-links and such are very cool.

I like the direction WordPress is heading. I just think that this particular stop on the tracks is not a great one. Too much still unfinished and only halfway thought-out, IMO.

And again, I realize that this is beta code, and I’m not criticizing any of the developers or talented individuals working on it. I get that WP 3.0 is unfinished as of this writing. I’m just trying to look at this from a perspective of an end-user. What’s in this upgrade for the end-user? Ultimately, not very much.

So while 3.0 is a very, very good step in the right direction, it’s a step that that end-users might want to skip over for now. If you’re a WordPress hacker, then go nuts. You’ll be fine with 3.0. But if not, then you might want to hold up a while and wait for the next release instead.

Note that this won’t stop me from upgrading, nor from posting tips/tricks for 3.0 users. Just saying.