Archive for the ‘Rants’ Category.

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.

Shortlink:

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.

Shortlink:

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.

Shortlink:

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. :)

Shortlink:

Over on my Simple Facebook Connect page, there’s lots of comments from users with problems. Having answered these for a while now, via there and via email, I’ve come to the conclusion that people don’t search for answers to their problems.

The “How to fix the Email Domain” problem is answered on that one page no less than 6 times, for example. Almost all the rest of the problems given come from the “wrong connect URL setup” issue.

So if you don’t want to do support all the time, I think you have to make your plugin smarter. Take the most common issues you see and make the plugin auto-detect the problems. That’s what I’ve done with SFC version 0.16, for example.

Error Messages

Error messages now show up when the user configured something wrong on Facebook.

The plugin now can detect these two major causes of problems and will display an error message. It also provides a link to the right place on Facebook to go and correct these problems. It can’t actually fix the problems directly (though that is possible… small steps), but I hope this will eliminate the need for me to continually have to answer the same questions over and over again.

So my tip for the day for plugin programmers: For robustness, make your plugin check for commonplace issues. And the issues that you think will be commonplace may not be the ones you expect, so figure on having to add more and more checks every time.

Shortlink:

Recently, a site I frequent went down for an extended period. I waited patiently for it to return (it said it was upgrading). A week later, I hopped on Twitter and asked the author WTF? I learn that the site has been back up for days. Only I, and probably half of the internet, had no idea. Why? DNS. Done wrong, it’s a bitch.

I think there’s an object lesson here.

So, let’s say that you’ve decided that your webhost sucks rocks, and you want to change hosts for your domain from your existing server called junkhost to a much better and new fangled one called goodrack.

How To Do DNS The Wrong Way

(or why the site is currently totally missing from the internet as I see it)

Step 1: Your domain’s nameservers are currently set to dns1.junkhost.com and dns2.junkhost.com.

Step 2: Your new hosting company tells you to set them to dns1.goodrack.com and dns2.goodrack.com. You do so.

Step 3: You wait a day or two or possibly flush your home router’s DNS and voila, your host is now visible to you.

Why this is the wrong way: DNS is a caching system. When I try to lookup the IP address for yoursite, then I don’t ask your nameserver for it. I ask my nameserver for it. My nameserver then asks you, but only if it doesn’t already know.

See, you communicate with your site regularly. So you are doing lots of queries and flushing the DNS on a regular basis. Home router DNS systems tend to flush a lot, as do cable modems and cable companies, etc. So you might see that nameserver switch in just a day or so. Maybe less.

Me, on the other hand, am sitting here at BigCompany, which has weird fiber and satellite links to all sorts of places. If my DNS has your nameservers cached, it could be cached for weeks. And you don’t have a whole hell of a lot of control over what is called “TTL”, or “Time-To-Live”.

Time-To-Live is what tells DNS caching servers when to drop the info and get fresh data. If the TTL for, say, a normal DNS lookup is 2 hours, then my nameserver isn’t constantly querying yours whenever I look at your site. It only queries it once every two hours, tops. More or less.

Sitting here looking at the thing in debug mode, I see that there’s another 46 hours left to go before the old data I now know exists gets flushed out of the DNS server. By then, I won’t have been able to access his site for a bit under 2 weeks. And I’m not the only one.

How To Do DNS The Right Way

(or why I can change hosts in under a couple hours)

Step 1: My domain’s nameservers are currently set to dns1.myregistrar.com and dns2.myregistrar.com. My registrar offers DNS hosting for free, as part of my having bought my domain through them. If they didn’t, I could use a free service like ZoneEdit, or similar.

Step 2: My new hosting company tells me to set the nameservers to dns1.goodrack.com and dns2.goodrack.com. I look them right in the eye, tell them to “get bent”, and ask what the IP address of my new server will be. If they put up a fight, I tell them I can always find a better web host. That usually shuts them up.

Step 2 (alternate): I say “sure, whatever you say”, then do the following at a command line:

C:\otto\>nslookup
Default Server:  dns.mycompany.com
Address:  1.2.3.4

> server dns1.goodrack.com
Default Server:  dns1.goodrack.com
Address:  5.6.7.8

> set type=any
> mydomain.com
Server:  dns1.goodrack.com
Address:  5.6.7.8

mydomain.com      internet address = 111.222.111.222
(root)  nameserver = dns1.goodrack.com
(root)  nameserver = dns2.goodrack.com
dns1.goodrack.com    internet address = 5.6.7.8
dns1.goodrack.com    internet address = 5.6.7.9

Now I know my new server’s IP address from there (it’s 111.222.111.222).

Step 3: I go to myregistrar.com’s site, edit my DNS settings (specifically, I change the A record for mydomain.com to point to that new IP address), and then I wait for a couple hours or so, max (since my registrar lets me set my own TTL, I can do what I like with it. Two hours is a decent tradeoff of time vs. functionality). Within 2 hours, every site on the whole blamed internet sees my new host.

Why is this better? Well, note that my nameservers never actually changed. Nameservers are set in the root domain lookup systems. Changes there not only take a while to propagate, but those servers are overloaded so caching values for nameservers are usually quite high. Individual host lookups though, not so much.

How a DNS request works:

  1. I ask my nameserver for example.com.
  2. It doesn’t know, so it goes and ask the root nameservers “Hey, who is the nameserver for example.com?”
  3. One of the 13 root nameservers says “Yes, example.com is serviced by dns1.somebody.com and dns2.somebody.com and here’s their IP address’s. Now leave me alone, I’m busy.”
  4. So my name server now goes and asks dns1.somebody.com, “Hey, do you know the IP for example.com?”
  5. And then dns1.somebody.com says “Sure, it’s 1.2.3.4″.

Lot of work. But note that my nameserver talked to TWO nameservers here. The root, and the actual nameserver for example.com. The TTL on the root lookup is not something I can adjust, usually. Or if I can, then it’s very difficult to do for most people. The TTL on the second is not nearly as hard, and doesn’t require all the root nameservers to be updated.

If you own a domain, then you need to own your DNS. Use a nameserver that you have control over, and which you will almost never change. You can change the addresses, you can change the MX records (for email), you can add TEXT records for SPF, and other DNS tricks all you want. But keep the nameserver location itself unchanged for as long as possible. Because when you do change it, the internet takes a long, long time to adjust to that fact. And you are then “offline” for quite a while.

To think of it another way: He who controls the DNS, controls the domain, as least for a while. Well, you’re going to change hosts a lot more often than you change domain names, right? So don’t give them your DNS control. No webhost should ever have your nameserver pointed to them unless you bought the domain name from them in the first place.

Shortlink:

Too often I see themes missing the absolute minimum requirements to make the theme actually work properly. So I figured I’d make a list of things that ALL WordPress themes need to have in them, every time. These are WordPress theme-specific things. I’m not including obvious stuff like HTML and such.

Note: These are my opinions. You may not agree with every one of these. My opinion in that case is that you’re wrong, so there’s little point in arguing with me unless you have a rock-solid reason for disagreeing with me. In other words, I’m not trying to start a flame war, nor am I interested in one. This is just a checklist that I hope theme authors will start following more often. It would make me happy if all themes had these. :)

  • wp_head() in the HEAD section.
  • wp_footer() just before the /BODY tag. (So many themes forget this simple little thing…)
  • language_attributes() in the opening HTML tag.
  • body_class() in the BODY tag.
  • post_class() in whatever surrounds each individual post (probably a DIV).
  • Use of get_header(), get_sidebar, and get_footer inside every appropriate page template.
  • The Loop inside every page template (exception: very Custom Page Templates).
  • Proper use of widgets on the sidebars (dynamic_sidebar, register_sidebar, etc).
  • A special image.php template. Image attachments can have their own template and make theme’s have built in nice gallery-like support. You should make a special one of these to fit your layout.
  • Comments must use wp_list_comments(). Preferably without using a customized callback. But if you must make a callback, be sure to support threading properly! This is tricky without also having an end-callback. And you should use a List to do it (unordered or ordered, it doesn’t really matter). If you’re using DIVs, you’re doing it wrong.
  • The Comments Reply form should have id=”commentform”. If you change this, you’re breaking plugins.
  • Similarly, you need to include do_action(‘comment_form’, $post->ID); on your comment form too.
  • A couple of useful Custom Page templates. Like a no-sidebar one, or one that has a different number of columns. Just generic ones to let your user have a few built in options.
  • New to 2.9: Thumbnail support. Come on, this is cool stuff, every theme needs to have it.
  • New to 3.0: Forget doing your own comment form at all. Just make the call to comment_form(). Then adjust it through styling or filters or what have you. Plugin authors will love you for doing this.
  • New to 3.0: Nav-menu support. It’s cool. Your users will love you for supporting it.
  • New to 3.0: add_theme_support( ‘automatic-feed-links’ ); in the function.php. This will make it do the feed links in the head for you, automagically.

This list is by no means complete. It’s just off the top of my head for now. But honestly, too many themes don’t have even the basic ones, and I’d like to see that fixed. If you’re a theme author, help everybody out, let’s make a list of standards and adhere to them. Users hate editing their themes to support their favorite plugins, and with standards like these, we could make it so that they didn’t have to.

Shortlink: