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.
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.
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.
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.
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.
After a long break, I am hopefully back to blogging somewhat regularly again. I needed to take some serious time off to re-balance my priorities in life, and to get a solid grasp on all of the things I need to do on a daily basis.
At least at the start, I’m not planning to try to blog every 2 or 3 days the way I had been doing; but I am hoping to post a new article once each week.
I apologize to anyone that actually reads my blog posts. I didn’t initially intention to disappear for quite so long.