My Review

I don't usually buy technical books; I'm more of a hands-on learner and the books that I've purchased in the past just collect dust. It's one of the reasons why I'm so impressed with jQuery Enlightenment. Besides being an eBook (and therefore can't collect dust), Cody has structured the book in a way that makes it perfect to have as a learning tool as well as a reference.

You can read the book top-down or skim through the topics, find something you're interested in, and get a detailed and easy to understand write-up on the subject. Cody takes the learning processes one step further by providing code examples, linked to JS BIN, that can be viewed and run in your browser. For someone like me, the concrete examples and ability to play with the concepts, helps reinforce the topics covered.

Whether you are a new jQuery users, or a seasoned jQuery developer, jQuery Enlightenment won't disappoint!

jQuery 1.4

The current version of jQuery Enlightenment was written for jQuery 1.3.2. I spoke to Cody about the recent release of jQuery 1.4 and his plans for an update. He is working on a new version of the book that he estimates will have twice the content (or more) and is tentatively priced at $30. Lastly, he plans to offer a limited-time discount on the update for existing jQuery Enlightenment owners. [Note from Cody: All of this information is subject to change]

Giveaway

As mentioned previously, I have 3 coupons available for free copies of jQuery Enlightenment. If you would like a chance to win, leave a comment below and on Wednesday (1/20) at 2pm PST, I will randomly select 3 people.

Winners!

The random number generator has spoken and the following people have won a coupon for a free copy of jQuery Enlightenment:

• Jim
• Sam De La Garza
• Bjorn van der Neut

I'll be sending the coupons codes out shortly. Congratulations, I know you'll enjoy the book.

SimpleModal Login handles logging into WordPress but does not handle user registration or the forgot password functions.

SimpleModal Login also supports themes, something I'm planning on adding to the SimpleModal Contact Form plugin as well.

If you have any feedback or issues, please let me know!

Download Project Page

1. Use wp_enqueue_script()

The traditional way to include jQuery in an HTML page is with the script tag. When working with WordPress, you should *never* do this. To avoid conflicts and other potential problems, you'll want to load jQuery using the following code:

function my_init() {
	if (!is_admin()) {
		wp_enqueue_script('jquery');
	}
}
add_action('init', 'my_init');

You can replace my_init with something more meaningful, but choose a unique name to avoid conflicts. For plugin development, add the code in your plugin file, otherwise, add this code to your theme's functions.php file. The is_admin() check is to prevent script queuing on your admin pages.

WordPress References:

• wp_enqueue_script()
• add_action()
• is_admin()

2. Load jQuery from the Google AJAX Library

Since WordPress includes jQuery, calling wp_enqueue_script('jquery'); will automatically load the jQuery file located in wp-includes/js/jquery/jquery.js.

If you want to load jQuery from the Google AJAX Library, you'll need to modify the code as follows:

function my_init() {
	if (!is_admin()) {
		// comment out the next two lines to load the local copy of jQuery
		wp_deregister_script('jquery');
		wp_register_script('jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js', false, '1.3.2');
		wp_enqueue_script('jquery');
	}
}
add_action('init', 'my_init');

There are a number of reasons why you would want to use the Google AJAX Library to load jQuery, but remember, Google has been down before, so be ready to comment out the first two lines if necessary.

Note: As mentioned by Milan in the comments, there are existing plugins, such as Use Google Libraries, that will do this for you.

3. Load jQuery in the footer

Using the code in the previous two tips, jQuery will, by default, be inserted into the head of your HTML page. If you would prefer to have jQuery inserted at the bottom of your page, you'll need to use the $in_footer parameter for the wp_enqueue_script() function. The modified code:

function my_init() {
	if (!is_admin()) {
		wp_deregister_script('jquery');

		// load the local copy of jQuery in the footer
		wp_register_script('jquery', '/wp-includes/js/jquery/jquery.js', false, '1.3.2', true);

		// or load the Google API copy in the footer
		//wp_register_script('jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js', false, '1.3.2', true);

		wp_enqueue_script('jquery');
	}
}
add_action('init', 'my_init');

As with the choice to use the Google AJAX Library, there are reasons why you'd want to load jQuery at the bottom of your page. Note: if a script is loaded using wp_enqeue_script() that lists jQuery as a dependency and has $in_footer set to false, WordPress will place jQuery in the head instead of the footer, regardless of the $in_footer value for jQuery.

4. Add jQuery as a dependency

You've got jQuery loading and now you want to include a script that uses it. This is where the wp_enqueue_script() function really comes in handy. By passing an array of dependencies for the $deps parameter, WordPress will automatically manage the order and placement of your script tags.

For example, if you have a JavaScript file in your theme that leveraged jQuery, the following code would ensure that your file is loaded correctly:

function my_init() {
	if (!is_admin()) {
		wp_deregister_script('jquery');
		wp_register_script('jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js', false, '1.3.2', true);
		wp_enqueue_script('jquery');

		// load a JS file from my theme: js/theme.js
		wp_enqueue_script('my_script', get_bloginfo('template_url') . '/js/theme.js', array('jquery'), '1.0', true);
	}
}
add_action('init', 'my_init');

The previous code example would load jQuery from the Google AJAX Library, place it in the footer of your page and then include your theme.js file. The $deps array allows for multiple dependencies and helps you manage the scripts that are loaded on your site.

5. Proper jQuery coding conventions

All of the previous steps are nullified if proper jQuery coding conventions aren't followed. The most common issue I see with jQuery and WordPress is the misuse of the $ variable.

It is important to know that the version of jQuery that comes with WordPress automatically calls the jQuery.noConflict(); function, which gives control of the $ variable back to whichever library first implemented it. If you are loading a different copy of jQuery, you'll need to manually call jQuery.noConflict();, if necessary, from one of your JavaScript files.

As a general rule, you should not use the $ variable for jQuery unless you have used one of the shortcuts. The following is an example of how to shortcut jQuery to safely use the $ variable:

jQuery(function ($) {
	/* You can safely use $ in this code block to reference jQuery */
});

I've actually been working on this redesign, on again, off again, for the last year or so. Although the design has been through a number of changes, the technologies I wanted to build the site with have remained the same: WordPress and jQuery.

So, I'd love to hear your thoughts on the new design - please leave a comment. If you didn't see the previous version, here's a screenshot of what it looked like:

Go ahead and say it, it's OK, the previous version was ugly. Hopefully the new design is easier on the eyes.

As a side note, I'll be starting a series or articles that will cover the redesign and development process in more detail. The articles will focus on topics such as creating a custom WordPress theme, client-side development using jQuery, and website performance. If you are interested in any of those topics, be sure to subscribe or bookmark this site.

IE7

Recap: In certain situations, jQuery’s $.browser.version will report IE 7 as version 6.

Considering the problem is due to IE 7 having an incorrect user-agent, I'm not sure that this problem was up to jQuery to solve. It would have required the user-agent parsing code to check non-user-agent properties...which is probably a bad idea.

I found out that my original code suggestions might fail in situations where IE 6 is using a 3rd party library to add XMLHttpRequest support, so here are my updated IE 6 and IE 7 detection suggestions:

Override the $.browser.version value:

jQuery.browser.version = jQuery.browser.msie &&
    parseInt(jQuery.browser.version) >= 6 &&
    typeof window['XMLHttpRequest'] == "object" ?
        "7.0" :
        jQuery.browser.version;

Add a new msie6 property:

jQuery.browser.msie6 = jQuery.browser.msie &&
    parseInt(jQuery.browser.version) == 6 &&
    typeof window['XMLHttpRequest'] != "object";

Keep in mind that $.browser is now deprecated, which means it will go away at some point in a future release. I'm not going to get into the object detection vs browser sniffing debate, but just be aware!

Opera 9.5

Recap: Opera, in an effort to follow standards, changed where it was storing the value for the viewport height.

This issue was fixed in jQuery Ticket 3117 by Ariel Flesler. If you have Opera 9.5, you can test the results on this page.

Safari 3 (Windows)

Recap: The following element would not be hidden in Safari: $("<div/>").hide().appendTo('body');

I found out that this issue also occurs in Safari 4! The original jQuery ticket I mentioned was marked as a duplicate, but the issue was fixed in ticket 1239.

Summary

Besides the problems with the IE user-agent, the jQuery developers implemented fixes for the two other browser issues that I had previously blogged about. jQuery 1.3.x has a number of new features and code improvements and continues to be, IMO, the best available JavaScript library.

I tested SimpleModal (tests and demos) with jQuery 1.3 and everything seems to be working as expected. After reading about all of the speed improvements, I thought it would be interesting to run some tests (Firebug 1.3 Profiler) comparing the SimpleModal demos with jQuery 1.2.6 and jQuery 1.3:

I haven't looked into why 1.3 has more calls for the Contact Form, but even so, the execution time (ms) has improved for each one!

Congratulations to the jQuery team and Happy Birthday!

While working on a new site design, I found an interesting bug in WordPress 2.7. I created two new pages to use as "Front page displays", one called Blog and one called Home. To create the pages, I clicked on Pages > Add New, entered a Title and clicked Publish.

I then went to my Reading Settings (Settings > Reading) and set the static Front and Posts page to the pages I just created. Going back to my site, I tested out the new static pages only to find they didn't work.

After a lot of time and troubleshooting, I noticed on the Pages screen that there were two copies of each page I had created - with one still labeled as a Draft. After even more time troubleshooting, I finally discovered the issue. Unlike the Posts page, the Publish and Save Draft buttons are not disabled during an autosave. So, when I entered the Page title and clicked Publish, the autosave and publish requests were happening at the same time.

I opened a WordPress ticket and submitted a patch. The patch was applied by azaozz, but it looks like it won't be available until WordPress 2.8. To fix this bug yourself, open /wp-includes/js/autosave.js and change all occurrences of #submitpost to .submitbox:

function autosave_enable_buttons() {
	jQuery(".submitbox :button:disabled, .submitbox :submit:disabled").attr('disabled', '');
}

function autosave_disable_buttons() {
	jQuery(".submitbox :button:enabled, .submitbox :submit:enabled").attr('disabled', 'disabled');
	setTimeout(autosave_enable_buttons, 5000); // Re-enable 5 sec later.  Just gives autosave a head start to avoid collisions.
}

Now the buttons will be disabled during an autosave, just like it does on the Posts page.

In my situation, I was looking for a selector that would allow me to do an exact search. The scenario: A user enters a value in a text box and submits. The value entered is then used to search a multiple select element for an option element with a text node that is an exact match (case-insensitive).

My solution:

jQuery.extend(jQuery.expr[':'], {
	exactIgnoreCase: "(a.textContent||a.innerText||jQuery(a).text()||'').toLowerCase() == (m[3]).toLowerCase()"
});

If you wanted a case-sensitive selector:

jQuery.extend(jQuery.expr[':'], {
	exact: "a.textContent||a.innerText||jQuery(a).text()||'' == m[3]"
});

The JavaScript implementation:

$("#detail form.find").bind("submit", function (e) {
	 // cancel the submit
	 e.preventDefault();

	// get the search value
	var q = $("#detail form.find input.query");

	// look for a match using the custom selector - only return the first one
	var result = $("#detail select.fields option:exactIgnoreCase(" + q.val() + "):first");

	// if a match was found, select that field (option). Clear the value and focus.
	// otherwise, add a visual clue that nothing was found
	if (result.length > 0) {
		result.attr("selected", true);
		q.removeClass("requiredError").val("").focus();
	}
	else {
		q.addClass("requiredError");
	}
});

Pretty cool, huh!?! Now, try it out for yourself. Here's a template that will help get you started:

jQuery.extend(jQuery.expr[':'], {
	EXPRESSION_NAME: "EXPRESSION_RULE"
});

To get samples of what goes in the EXPRESSION_RULE part, open up the jQuery source, look for "expr: {", then study all of the current expressions in the "":": {" section of the code.

Have you written any custom selectors that you'd like to share?

What was your first initial impression of the redesign?

Update: Order has been restored and the Rock Star is dead!

During the time that I've been using jQuery (about a year now), I've run into three fairly significant browser issues. Between IE, Firefox, Safari, and Opera, Firefox is the only browser that I have yet to experience any issues with (related to jQuery, of course).

IE 7

In certain situations, jQuery's $.browser.version will report IE 7 as version 6. Jamie Thompson noted one possible situation on his blog, but typically the issue is caused due to the fact that some copies of IE 7 included MSIE 6.0 within its user-agent string.

There is a jQuery Ticket open for the issue, but a solution has not been chosen. Based on some ideas that Jamie had, I came up with a possible solution by overriding the $.browser.version value:

jQuery.browser.version = jQuery.browser.msie &&
    parseInt(jQuery.browser.version) >= 6 &&
    window["XMLHttpRequest"] ?
        "7.0" :
        jQuery.browser.version;

Additionally, there are situations when I'm just looking for IE 6:

jQuery.browser.msie6 = jQuery.browser.msie &&
    parseInt(jQuery.browser.version) == 6 &&
    !window["XMLHttpRequest"];

It appears that these issues were resolved in IE 8 (at least in the beta version), but until jQuery releases a "fix", you'll have to deal with unreliable browser version detection in IE 7, or use one of the suggestions above.

Opera 9.5

I discovered an issue getting the viewport height in Opera 9.5 while testing my rewrite of SimpleModal. It turns out that Opera, in an effort to follow standards, changed where it was storing the value for the viewport height...breaking the way jQuery was getting the value. Previously, the value was stored in document.body["clientHeight"], but in 9.5 it was moved to document.documentElement["clientHeight"]. There is also a jQuery Ticket open for this issue, and a patch has been added by Ariel Flesler.

For SimpleModal, I've added code that will fix the issue until it is fixed in jQuery:

// fix a jQuery/Opera bug with determining the window height
var h = $.browser.opera && $.browser.version > "9.5" &&
    $.fn.jquery <= "1.2.6" ?
        document.documentElement["clientHeight"] :
        $(window).height();

Safari 3 (Windows)

This is the smallest of the three issues, but annoying none-the-less. Take the following example:

$("<div/>").css({
    background: "#336699",
    color: "#fff",
    padding: "8px",
    width: "200px"
}).html("Loading...").hide().appendTo("body");

In Safari, the "loading" element will be visible when the page loads. In all other browsers, it is hidden (display:none). The issue occurs because the jQuery hide() function is supposed to look for "visible" elements and set the CSS display property to 'none'. However, in Safari, it appears that an element not yet in the DOM, already has a display property of 'none'...which sounds fine, right? It's not! Since it fails the visibility test, jQuery does not explicitly set the display property to "none".

Then, once the element is added to the DOM, it appears that Safari sets the elements display property to 'block'. So even though the intention was to have it "hidden", due to a Safari quirk (and lack of a jQuery internal solution), the element will be visible.

As I'm sure you've guessed by now, there is a jQuery Ticket open, but the suggestion is to just change the way you use jQuery. One suggestion is to move the .hide() after the .appendTo("body"). My problem with this is that it introduces the possibility of a flicker on the screen as the element is added and then hidden. The workaround I am using is to manually set the display property on the element:

$("<div/>").css({
    background: "#336699",
    color: "#fff",
    display: "none",
    padding: "8px",
    width: "200px"
}).html("Loading...").appendTo("body");

That concludes my notes about three browser issues I've encountered while using jQuery. If you've run into any issues where you've had to use a workaround, or have any other suggestions for the workarounds I used, feel free to mention them below!

And the moral of the story...use Firefox! :)