Customising the AJAX output of WordPress plugins can often be a breeze, when the authors oblige other developers by peppering their code with action and filter hooks. But if they don’t, you can always fall back on hacking the plugin’s AJAX action.
I indent with tabs. There, I said it. Viewing my code (and that of other tab indenters) on GitHub, Gist, or Bitbucket can be annoying because the default tab size in the browser is equivalent to 8 spaces. Modern browsers let you change that through CSS, and here’s some bookmarklets that do just that.
WordPress has a good API for adding admin menu items. Unfortunately, it doesn’t allow you to specify a direct link to something, only a “slug” that links your menu item to a callback function to run when your menu item is selected. But fortunately, there’s a hack.
The Opera browser persistently refuses to honour “return false” in an onclick handler, and is quite possibly the only web browser that does this. Because I don’t usually add event handlers inline any more, I haven’t noticed this defect until now, but it just bit me today.
Probably the best thing about WordPress, from my perspective as a developer, is its hooks. It has filter and action hooks for nearly everything, which means I can easily customise a WordPress website to meet pretty much any requirements thrown at me. Well, nearly any. Except widgets.
The best thing about WordPress, besides the fact that nearly anyone can edit a website built with it, is hooks. Filter and action hooks allow developers like me to customise a WordPress website in myriad ways. Many good plugins provide hooks too. But inevitably, you’ll run up against a problem where you’d like a plugin to have a hook that it just doesn’t have. You can ask the plugin author nicely to add that hook, and maybe they’ll add it sometime soon, maybe even on time for your deadline. But what if your deadline comes before they add it?
It’s quite common to use WordPress as the host for an online shop, and that often means having an order page that needs to be encrypted via SSL. You don’t want your customers providing credit card details or other sensitive information over an unencrypted connection! But many WordPress plugins don’t take SSL into account, and merrily load scripts and stylesheets without encryption. Here’s a couple of ways to fix this problem.
CSS drop-down menus are very popular on sites with a hierarchy of pages. They let you get to where you want to go without having to navigate the pages in that hierarchy. But pure-CSS menus suffer a problem: touch devices often can’t show the drop-down, because they don’t have “hover” and clicking on the top level link goes there. This snippet offers a way around that.
Apparently, Internet Explorer 7 is stupid. I mean, it lets you create a form input element dynamically, and add it to a form, but the form doesn’t know it by name. And I only just found this out!
Pretty much all web developers should know by now that browser sniffing is evil. If you don’t know why, you should definitely read Richard Cornford’s excellent treatise Browser Detection (and What to Do Instead). Feature detection, where you look for the specific feature you want to use, is much safer; taken to the extreme, it can end up like the rather clever Modernizr project. But what if you really do just want to know if your code has the misfortune to be running on IE7?
CSS3 has been tempting me with linear gradients for a while now. They don’t work in Internet Explorer, but there are ways and means with a little script magic. Now that Opera has finally joined the party, I figured it was time to ditch those ever pervasive linear gradient background images and start using CSS3 for linear gradients. But it’s not all rosy, especially when you need to position your background.