HoverIntent in WordPress

Whenever you’re working on a new WordPress theme that includes hover (mouseover) effects, especially dropdown or flyout menus, you might want to include hoverIntent. HoverIntent is a term that describes a concept through which you delay a hover action until a certain amount of time has passed, in order to make sure that the user really intended to trigger that action.

We’ve all been on websites with dropdown menus that tend to get in the way of the content, and pop open as soon as your mouse touches even a small portion of them, and we’ve most likely all been annoyed by it. The idea behind hoverIntent is to measure the speed of the mouse movement, attempting to determine whether the user actually intended to stop on the item or not. If the mouse just moves over an item with a hover effect, but doesn’t stop on it, the hover effect should not be triggered; if, however, the user’s mouse does slow down enough or stop on the item, the hover effect should be triggered.

Using jQueryUI in WordPress

With the update to WordPress 3.3.x, the WordPress core now includes the entire jQueryUI suite packaged in the download. No longer do plugin and theme developers have to include their own custom builds of jQueryUI elements (hopefully they never did include custom builds of the elements, but there are quite a few plugins and themes that did). Instead, you simply need to enqueue the existing scripts.

Following is a full list of the jQueryUI elements included in WordPress, along with their “handles” for use with the wp_enqueue_script() function.

A Quick Lesson in WordPress Semantics

As much as I love WordPress, there are quite a few elements and functions in the system that can be a bit confusing, and even ambiguous. In this article, I’m going to try to explain and unravel a few of these items.

What’s the difference between the “home” page and the “front page”?

To many users, the terms “home” page and “front page” might seem like the same thing. However, in WordPress, they’re treated as two different elements. The “home” page is the main page that shows blog posts. If you install WordPress and don’t change any of the settings, this will be your site’s front page. However, if you modify the “Settings -> Reading -> Front page displays” setting to select “A static page (see below)”, and you choose a page for the “Front page” and a page for the “Posts page”, the “home” page is no longer the first page on your site. Instead, the first page on your site is the “front page”, now.

Zeus and WordPress Part 3: SSL Issues

While working to get WordPress functioning properly on a Zeus Web server, one of the issues I came across was the fact that I couldn’t seem to get any SSL functions working properly. I tried 2 or 3 different plugins, and all of them started causing infinite redirect loops as soon as they were activated.

Eventually, after quite a bit of investigating and testing, I found the cause of the issue: that particular server (and, presumably, all Zeus servers) doesn’t use any of the same indicators that SSL is being used that apache does. On apache servers, PHP usually has a handful of indicators that SSL is currently being used to serve the page. For instance, there’s a server global variable called “HTTPS” that gets set to “on” for many PHP configurations; SSL is generally served over port 443 instead of port 80; etc.

Zeus and WordPress Part 2: Fixing Query Strings

If you’re trying to get WordPress working on a Zeus Web server, and you’ve gotten as far as using a good rewrite script to make permalinks work properly, you might have noticed that query strings don’t work at the ends of your permalinks. At first, it seemed like this wouldn’t be too big of an issue; it just meant that users wouldn’t be able to preview posts/pages, and there would be one or two other issues they’d have to live with. However, after using the site that way for a little while, we started coming across more and more issues that this caused, and it finally reached a tipping point.

To solve the issue, I wrote a simple function that runs any time a 404 error occurs on the site. Essentially, it parses the path of the requested page, cuts off the query string temporarily, and then searches the database for a post or page that has the slug at the end of the path.

You may be wondering why I didn’t just parse the request/get variables sent with the page. The problem is, those were empty in each of the cases I tested.

WordPress and Zeus Part 1: Getting Permalinks Working

For those of you that might not know (and I was one of you about a month ago), Zeus is a Web server package that’s used instead of apache by some Web hosts. If you’re planning to use WordPress, and you have a choice between apache and Zeus, I would definitely recommend choosing apache. However, sometimes you don’t have a choice in the matter; and you have to do what you can to make things work.

WordPress will work out of the box with Zeus, but a lot of things won’t behave the way you might expect. One of those things is the permalink structure.

Instead of getting nice, clean URLs like “http://example.com/blog/2012/01/my-first-blog-post/”, you get “index.php” shoved in there (like “http://example.com/index.php/blog/2012/01/my-first-blog-post/”). You can correct this issue, but it’s not quite as simple as updating an .htaccess file (in fact, without some jiggery-pokery by your Web host, Zeus doesn’t support .htaccess at all). Instead, you have to apply a rewrite script to your server configuration.

After quite a bit of searching and trial & error, I finally found a working rewrite script configuration for WordPress. A hosting company called ZipHosting posted the scripts below in their knowledgebase. The first script is set up for you to use if WordPress is hosted in a subdirectory, and the second is for use with WordPress in the root directory.

Developer Resources