I’m switching all my sites over to a single 3.0 installation, with the new MultiSite capabilities. So the sites might be fruity for a while. In the process, I also expect to lose some things, such as the email subscriptions. Sorry about that, I’ll restore stuff like that later.
Sorry about the STC and SFC errors
Sorry about that, folks. An inadvertent early check-in made it so some bugs crept into the releases I had scheduled today. I didn’t mean for those to get released when they did, and I didn’t notice it for a couple hours. So some people may have upgraded earlier than I wanted them to.
Versions 0.16 of Simple Facebook Connect and 0.6 of Simple Twitter Connect should not be used. Wait for the 0.16.1 and 0.6.1 releases to hit the repository. Those will work without the same sorts of errors.
If you are already having the major fatal error with Simple Twitter Connect, then delete the stc-comments.php and stc-publish.php files to make your site work again. Then upgrade to 0.6.1 and the working files will be restored.
Plugin Programming Tip: Your Users Don't Read.
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.
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.
How Not To Let DNS Bite You In The Ass
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:
- I ask my nameserver for example.com.
- It doesn’t know, so it goes and ask the root nameservers “Hey, who is the nameserver for example.com?”
- 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.”
- So my name server now goes and asks dns1.somebody.com, “Hey, do you know the IP for example.com?”
- 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.
Simple Twitter Connect 0.5
If you subscribe to the Twitter account that is hooked up to my blog entries, then you might have saw a test tweet earlier. That’s because I was testing. Now I’m not, and I just pushed Simple Twitter Connect 0.5 out for release.
New features:
– Made the comments plugin smarter. The Settings page allows the “Send to Twitter” button on comments to be disabled. Just leave the field blank and voila, no more checkbox.
– The Tweetmeme script now uses HTML comments properly. This prevents the tweetmeme javascript stuff from showing up in weird places, like in the feed and in the Simple Facebook Connect Publish/Share sections.
– And the big one: Automatic Tweeting on Post Publish. It supports auto-tweeting to an alternate Twitter account than your own (useful if you have a multi-user blog). Manual publishing will be coming soon, but I suspect it will not support the alternate account functionality, for simplicity. It would be confusing and hard to use.
Note: that last one is a bit beta. Don’t be surprised by bugs and odd behavior. Don’t rely on it working every time, because it probably won’t. But when it does work, it works great. Here’s this post, auto-tweeted: http://twitter.com/ottodestruct/status/10934354229 🙂
Minimum WordPress Theme Requirements
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 trick
For you people who do your own theme work:
<?php if (function_exists('wp_get_shortlink')) { ?> <div><span class="post-shortlink">Shortlink: <input type='text' value='<?php echo wp_get_shortlink(get_the_ID()); ?>' onclick='this.focus(); this.select();' /> </span></div> <?php } ?>
Basically that adds a little Shortlink: input box with the shortlink in it. Click the box, and the shortlink becomes selected for easy copy and paste.
It’ll also work with any shortlink plugin that uses the “get_shortlink” filter to override the shortlink properly (like WordPress.com Stats).
Put it somewhere in The Loop or on the Single Post pages or what have you.
Simple Twitter Connect 0.4
I updated Simple Twitter Connect to version 0.4. New stuff:
Login message
The Login plugin now correctly displays an error message when somebody attempts to login as a user that isn’t recognized yet. This should prevent confusion about why “login doesn’t work” after activating the plugin.
Tweetmeme button
New Tweetmeme button plugin added. STC was already perfectly compatible with the existing TweetMeme plugins, but for completeness (and because it was easy), I added this. It’s much like the SFC Share plugin, really.
Note: In the future, an actual STC Share plugin will be created, which will send tweets directly from your own Twitter Application, instead of through TweetMeme. That will be a sorta replacement for this, in that it will have the same basic functionality.
Shortlink support (or lack thereof)
I made the plugin give more information about shortlinks and how they work. Basically, I’m not going to support shortlinks directly. There’s just too many of them. Instead, I have put in support for generic shortlink plugins. The idea here is that anybody can make a plugin to do some form of shortlink support, and this plugin can then use it automatically.
How this idea works:
1. A shortlink plugin author implements this function: “get_shortlink($post_id)”.
2. That’s it. Do that and the plugin will use it.
Any plugin author creating a shortlink plugin should be able to easily do this. In fact, one already has. If you use the WordPress.com Stats plugin, then you automatically get “wp.me” style shortlinks. STC will use them because they implement this function in a pluggable way.
This is also the best solution for people who prefer to implement their own shortlinks in some custom manner. All they need to do is to create a get_shortlink function that returns the shortlink string, and voila, it’ll be used.
So, there you go. Enjoy.
First Post
Welcome, visitor! You’ve found my new spot on the web, where I plan to put all my WordPress related posts and plugins and thoughts and rants and such from now on.
What can I say, all the WordPress stuff was cluttering up my main site. 🙂
Anyway, I’ll be migrating a few of my older posts to here over the next few weeks, so if you were following me over there, you may see some repeat content. Sorry about that. I won’t be changing the feeds and such to redirects until I’ve got something new to post, so hopefully this will minimize the transition for any people reading my little rants.
Enjoy!
Don’t include wp-load, please.
Originally published here: http://ottodestruct.com/blog/2010/dont-include-wp-load-please/
Note: There is a followup post to this one, which details an even better way than the two given below: http://ottopress.com/2010/passing-parameters-from-php-to-javascripts-in-plugins/
Time for Otto’s general griping: WordPress plugin programming edition.
Here’s a practice I see in plugins far too often:
- Plugin.php file adds something like this to the wp_head:
<script src='http://example.com/wp-content/plugins/my-plugin/script.js.php'>
- Script.js.php has code like the following:
<?php include "../../../wp-load.php"; ?> ... javascript code ...
The reason for this sort of thing is that there’s some option or code or something that the javascript needs from the database or from WordPress or whatever. This PHP file is, basically, generating the javascript on the fly.
Usually, the case for this turns out to be something minor. The code needs the value from an option, or some flag to turn it on or off. Or whatever.
Problem is that finding wp-load.php can be a bit of a chore. I’ve seen extreme efforts to find and load that file in plugins before, including searching for it, examining the directory structure to make decent guesses, etc. This sort of thing has existed even before wp-load.php came around, with people trying to load wp-config.php themselves and such.
But the real problem is simpler: This is always the wrong way to do it.
Continue reading ‘Don’t include wp-load, please.’ »