Archive for the ‘Rants’ Category.

Next Entries »

April 7, 2010, 10:27 am

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:
Category: Rants  |  21 Comments

April 1, 2010, 11:25 am

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:
Tags: , , , , , ,
Category: Rants, WordPress  |  8 Comments

March 23, 2010, 4:48 pm

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:
Tags: , ,
Category: Other, Rants  |  16 Comments

March 17, 2010, 12:07 pm

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:
Tags: , , ,
Category: Rants, WordPress  |  5 Comments

February 9, 2010, 4:22 pm

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:

  1. Plugin.php file adds something like this to the wp_head: 
    <script src='http://example.com/wp-content/plugins/my-plugin/script.js.php'>
  2. 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.’ »

Shortlink:
Tags: , , ,
Category: Code, Rants, WordPress  |  57 Comments

September 21, 2009, 4:27 pm

Originally posted here: http://ottodestruct.com/blog/2009/hacked-wordpress-backdoors/

Over here, Jorge Escobar is writing about how he got hacked with the latest version of WordPress. After some minor back and forth on FriendFeed, I got him to do a search which found a malicious backdoor he might not otherwise have found.

In so doing, it occurred to me that most people don’t keep up with the world of WordPress in the way I do, and so have not seen nearly as many hack attempts. So I figured I’d post my little contribution, and show people how to find hidden backdoors when cleaning up their hacked sites.

Non-technical users can safely ignore this post. 🙂
Continue reading ‘How to find a backdoor in a hacked WordPress’ »

Shortlink:
Tags: ,
Category: Rants, WordPress  |  103 Comments
Next Entries »