Posts

Posted on

jQuery Nivo Slider has broken effects within WordPress

I’m using the jQuery Nivo Slider plugin on a WordPress project. Keep in mind that this is the free jQuery plugin version, not the WordPress plugin version, so I’m doing the integration myself into a child theme of the stock Twenty Thirteen WordPress theme.

To make it align properly with the other page entries, I used the standard WordPress classes on the wrappers…

<div class="hentry">
    <div class="entry-content">
        <div class="slider-wrapper theme-default">
            <div id="slider" class="nivoSlider">
            ....

The problem is, although the slider is nicely positioned on the page, the transition effects are broken. The slider is still working but just before each transition animation is supposed to start, you get a flicker of a tiny thumbnail in the upper-left corner and then the new slide appears… no slicing, no boxing, no wiping… nothing but sadness.

I was able to recreate my exact slider code in a jsFiddle and it worked flawlessly. After much troubleshooting, I discovered that the WordPress class `.entry-content` in the parent theme was the culprit.

However, the removal of `.entry-content` fixes Nivo slider, it also breaks the layout. By the time I figure out how to recreate the necessary parts of `.entry-content` to fix the layout, I’ve a whole bunch of unnecessarily redundant CSS.

Another look at the default CSS for the parent Twenty Thirteen theme reveals line #659…

.entry-content img {
    max-width: 100%;
}

Yes, this is it. This one CSS rule is completely breaking Nivo slider’s animation effects.

The fix is to simply un-set `max-width` to the default value of `none` by very specifically targeting the slider `img` elements. I placed this rule in my child theme’s `style.css` file.

.entry-content #slider img {
    max-width: none;
}

Since `.entry-content #slider img` is more specific than the original selector, `.entry-content img` in the parent theme, it will automatically take precedence.

Nivo slider is now working as designed.

Posted on

Over-ride the default error messages for jQuery Validate

If you’re using the jQuery Validate plugin and are constantly customizing the error messages, here’s a way you can do it all at once. Insert this code anytime after you’ve included the validate plugin.

jQuery.extend(jQuery.validator.messages, {
    required: "This field is required.",
    remote: "Please fix this field.",
    email: "Please enter a valid email address.",
    url: "Please enter a valid URL.",
    date: "Please enter a valid date.",
    dateISO: "Please enter a valid date (ISO).",
    number: "Please enter a valid number.",
    digits: "Please enter only digits.",
    creditcard: "Please enter a valid credit card number.",
    equalTo: "Please enter the same value again.",
    accept: "Please enter a value with a valid extension.",
    maxlength: jQuery.validator.format("Please enter no more than {0} characters."),
    minlength: jQuery.validator.format("Please enter at least {0} characters."),
    rangelength: jQuery.validator.format("Please enter a value between {0} and {1} characters long."),
    range: jQuery.validator.format("Please enter a value between {0} and {1}."),
    max: jQuery.validator.format("Please enter a value less than or equal to {0}."),
    min: jQuery.validator.format("Please enter a value greater than or equal to {0}.")
});
Posted on

Prevent Akismet plugin from auto-deleting comments

If you’re using the Akismet plugin on your WordPress site, you love its ability to identify spam comments and automatically block them from appearing on your blog… that’s something we all should appreciate greatly.

The little issue here is that Akismet will always automatically delete any flagged comment that’s older than 15 days. There is no option to disable or change this interval.

What’s the problem with that?

  • Nothing is perfect and false positives are a possibility; in fact, it’s already happened. This means that a legitimate comment is flagged as spam.
  • Maybe you’re being stalked or harassed and you need to keep these comments as a research aid or as evidence.

If you neglect to take action within 15 days, these flagged comments are permanently deleted by the plugin.

What’s the cause?

A function within the Akismet plugin called `akismet_delete_old` checks the age of flagged comments and just proceeds to delete anything older than 15 days.

function akismet_delete_old() {
	global $wpdb;
	$now_gmt = current_time('mysql', 1);
	$comment_ids = $wpdb->get_col("SELECT comment_id FROM $wpdb->comments WHERE DATE_SUB('$now_gmt', INTERVAL 15 DAY) > comment_date_gmt AND comment_approved = 'spam'");
	if ( empty( $comment_ids ) )
		return;
		
	$comma_comment_ids = implode( ', ', array_map('intval', $comment_ids) );

	do_action( 'delete_comment', $comment_ids );
	$wpdb->query("DELETE FROM $wpdb->comments WHERE comment_id IN ( $comma_comment_ids )");
	$wpdb->query("DELETE FROM $wpdb->commentmeta WHERE comment_id IN ( $comma_comment_ids )");
	clean_comment_cache( $comment_ids );
	$n = mt_rand(1, 5000);
	if ( apply_filters('akismet_optimize_table', ($n == 11)) ) // lucky number
		$wpdb->query("OPTIMIZE TABLE $wpdb->comments");
}

You could edit it yourself from 15 days to whatever. Or you could remove the call to this functionality entirely.

However, I don’t recommend editing plugins as every time a plugin is updated to a new version, you’ll lose your edits. That, among other reasons, makes it not a good practice.

What’s the real solution?

Use WordPress’s `remove_action()` function to remove the function in the Akismet plugin that deletes old comments.

Simply place this line in your theme’s `function.php` file…

`remove_action(‘akismet_scheduled_delete’, ‘akismet_delete_old’);`

However, any time you switch themes, you’ll also lose this custom function. Instead, you can easily break this dependance by saving the following code in a `php` file uploaded to your WordPress plugin directory. It will automatically show up in the plugins section of your WordPress Dashboard. I named mine `Akismet Keep Comment` and it’s saved in a file at `/wp-content/plugins/Akismet_keep_comment.php`. Yes, you just created a real WordPress plugin.

<?php
/*
Plugin Name: Akismet Keep Comment
Plugin URI: https://www.johnkieken.com
Description: This plugin removes any comment deletion ability of the Akismet plugin.
Author: John Kieken
Version: 1.0
Author URI: https://www.johnkieken.com
*/

remove_action('akismet_scheduled_delete', 'akismet_delete_old');

?>

What about this checkbox option in the Akismet plugin?

“Auto-delete spam submitted on posts more than a month old.”

It doesn’t mean what you might think. Upon first reading, I thought it simply meant “auto-delete blog spam that’s more than a month old”. So by leaving it un-checked, I erroneously thought no comments would ever be deleted.

Okay, so what does “Auto-delete spam submitted on posts more than a month old.” really mean?

It means that if your posting is more than a month old, spam comments will be deleted instantly (rather than being held for 15 days). This part is in parenthesis because you have to dig through the php code to determine that comments are being auto-deleted after 15 days- no matter what.

I’ve discussed this issue with the developer and the possibility of the Akismet plugin having user controlled options for comment deletion. Unfortunately, they are very adamant about not allowing the user to have any control whatsoever over this automatic comment deletion. I guess you better hope there’s never a false positive. They are concerned about your server filling up with comments. Really? Many blogs are plagued with much bigger problems like hundreds of posts and thousands of images. What bothers me the most is the total lack of disclosure or documentation explaining that flagged comments will be auto-deleted, and after only 15 days.

I firmly believe this is an issue best left to the site admin, his webmaster and hosting provider to manage. No plugin should be blindly deleting comments, even those flagged as spam, without some admin control or knowledge.

Posted on

The various ways to declare your jQuery Validate rules

The following are all acceptable methods for declaring validation rules for the jQuery Validation plugin.

1) Declared within `.validate()`

Use this when you’re trying to keep your JavaScript separate from your HTML markup.

$(document).ready(function() {
        
    $('#myform').validate({
        rules: {
            fieldName: {
                required: true
            }
        }
    });
        
});

DEMO: http://jsfiddle.net/uTt2X/2/

NOTE: If your field `name` contains special characters such as brackets or dots, you must enclose the `name` in quotes…

$(document).ready(function() {
        
    $('#myform').validate({
        rules: {
            "field.Name[234]": {
                required: true
            }
        }
    });
        
});

—–

2) Declared by `class`:

Only use this when your rules can be declared by a boolean `true` as you cannot pass any parameters.

<input name="fieldName" class="required" />

DEMO: http://jsfiddle.net/uTt2X/1/

—–

3) Declared by HTML5 validation attributes:

Use this if you already have HTML 5 validation attributes within your form. Only use this when your rules can be declared with HTML 5 validation attributes. Not all rules can be declared in this fashion.

<input name="fieldName" required="required" />

DEMO: http://jsfiddle.net/uTt2X/

—–

4) Declared using the `.rules()` method:

You must use this method if you’re dynamically creating form elements. 

$('input[name="fieldName"]').rules('add', {
    required: true
});

DEMO: http://jsfiddle.net/uTt2X/3/

However, as per the documentation, this method only applies to the first matched element. The solution is then to wrap it within a jQuery `.each()` for assigning rules to many inputs at once.

$('.myclass').each(function() {
    $(this).rules('add', {
        required: true
    });
});

DEMO: http://jsfiddle.net/uTt2X/8/

—–

5) By assigning one or more rules to your own `class` using the `.addClassRules()` method:

Use this for assigning rules to fields by their class or for creating an arbitrary `class` representing the rule. Great for creating “compound” rules. Compound rules are rules that are composed of two or more standard rules, like `required` and `email`.

$.validator.addClassRules("myClass", {
    required: true,
    email: true 
});

Then apply to your HTML:

<input name="fieldName" class="myClass" />

DEMO: http://jsfiddle.net/uTt2X/4/

Posted on

How to properly initialize the jQuery Validate plugin

Based on time spent at Stack Overflow, there seems to be a popular misconception that the `.validate()` method is how you would directly “validate” or test validity when you submit the form.  This leads to all kinds of clever over-thinking… like wrapping `.validate()` inside of `click` and `submit` handlers,  which then leads to all kinds of problems like having to click twice before validation messages appear or a form submission with no validation at all. This is because the `.validate()` method is only used for initialization of the plugin and can only be called once on DOM ready (or anytime after the form’s markup is created). Any/all subsequent calls to `.validate()` are always ignored.

The plugin works simply and it automatically captures the click of the submit button to prevent a form submission until certain validation rules are satisfied.  I mean, that’s the whole point of the plugin… if you had to create your own `click` handlers and test things manually before submitting, then you might as well not have the plugin at all.

To properly initialize this plugin, all you need to do is call the `.validate()` method within the DOM ready event handler.  This is where you would declare rules, options, or over-ride any callback functions.

$(document).ready(function() { // <- ensure DOM is ready

    $('#myform').validate({
        // your rules, options and callback functions
    });

});

Once properly initialized as above, the plugin will automatically perform validation upon various event triggers such as on `keyup` during data entry, on `focusout` of the field, and on `click` of the submit button, not to mention the events that trigger validation of the `select`, `radio` and `checkbox` elements. It’s only after all validation rules are satisfied that the form will be allowed to submit.

To programmatically check validation you would use the `.valid()` method on the entire form or a single element. For example, let’s say you want to use a link (an anchor element), `<a>`, in place of the `type=”submit”` input/button. This code is only used for illustration as the most semantically correct way to do this is to use a `type=”submit”` `<input>` or `<button>` element.

$('#myLink').on('click', function(e) {
    e.preventDefault();     // <- block the '<a>' default behavior, history, page jump on click, etc.
    $('#myform').valid(); {  // <- triggers validation test of whole form, similar to the test on a submit button click.
});

Bottom line, the `.validate()` method, most typically, only goes inside the DOM ready event handler function to be called once on page load. It only has one purpose, to initialize the plugin on your form and to declare any plugin options during that initialization.

Posted on

jQuery Validate plugin requires a name attribute

Remember that no matter how you declare your rules when using jQuery Validate, even if you target by `id` and declare with the `.rules(‘add’)` method, you must absolutely have a `name` attribute on any form element you wish to validate.

<input name=”firstName” type=”text” …

See the Markup recommendations section of the Reference docs page:

“The name attribute is ‘required’ for input elements, the validation plugin doesn’t work without it.”

Why? The `name` attribute is how the jQuery Validate plugin keeps track of the inputs internally. Even though the documentation doesn’t specify it, it only stands to reason that if this is how the plugin is keeping track of everything, you must make sure each `name` is unique.

Posted on

MailChimp form using jQuery ajax

NOTE: This posting was originally written for MailChimp API version 1 and MailChimp will stop support for API versions 1 & 2 at the end of 2016.

UPDATE:  Click HERE to view the updated solution using MailChimp API v3.0

——

I created a simple HTML page for a dynamic MailChimp sign-up form using jQuery ajax. This means that your users can signup for your MailChimp list without leaving your page. Better than that, they will signup without a page refresh, as the jQuery and `ajax()` will dynamically update the page with the response from the MailChimp API server. This means that you can use jQuery animations to fade out the form, display an animated spinner while the user waits, and then fade in the message. With jQuery, and a little imagination, the possibilities are endless.

The PHP files are “hidden” in the background where the user never sees them yet the jQuery ajax can still access them invisibly. Even when your website is static HTML, without any PHP, this solution will work so that nobody will ever see a `.php` in their URL.

1) Download the PHP 5 jQuery example here…

apidocs.mailchimp.com/downloads/mcapi-simple-subscribe-jquery.zip

2) Follow the directions in the Readme file by adding your API key and List ID to the `store-address.php` file at the proper locations.

3) You may also want to collect the user’s first & last name and/or other form information. You’ll have to add an array to the `store-address.php` file using the corresponding Merge Variables.

Here is what my `store-address.php` file looks like where I also gather the first name, last name, and email type:

<?php
    function storeAddress(){
    
    	require_once('MCAPI.class.php');  // same directory as store-address.php

    	// grab an API Key from http://admin.mailchimp.com/account/api/
    	$api = new MCAPI('123456789-us2');

        // Merge Variables
    	$merge_vars = Array( 
    		'EMAIL' => $_GET['email'],
        	'FNAME' => $_GET['fname'], 
        	'LNAME' => $_GET['lname']
        );
    	
    	// grab your List's Unique Id by going to http://admin.mailchimp.com/lists/
    	// Click the "settings" link for the list - the Unique Id is at the bottom of that page. 
    	$list_id = "123456a";
    
    	if($api->listSubscribe($list_id, $_GET['email'], $merge_vars , $_GET['emailtype']) === true) {
    		// It worked!	
    		return 'Success!&nbsp; Check your inbox or spam folder for a message containing a confirmation link.';
    	} else {
    		// An error ocurred, return error message	
    		return '<b>Error:</b>&nbsp; ' . $api->errorMessage;
    	}
    	
    }

    // If being called via ajax, autorun the function
    if($_GET['ajax']){ echo storeAddress(); }
?>

4) Create your HTML/CSS/jQuery form. It is not required to be on a PHP page.

Here is what my `index.html` file looks like. This code is contained between the `<body></body>` tags:

<form id="signup" action="index.html" method="get">
        <input type="hidden" name="ajax" value="true" />
        First Name: <input type="text" name="fname" />
        Last Name: <input type="text" name="lname" />
        email Address (required): <input type="text" name="email" />
        HTML: <input type="radio" name="emailtype" value="html" checked="checked" />
        Text: <input type="radio" name="emailtype" value="text" />
        <input type="submit" />
</form>
<div id="message"></div>

<script src="jquery.min.js" type="text/javascript"></script>
<script type="text/javascript">
    $(document).ready(function() {
        $('#signup').submit(function() {
            $("#message").html("<span class='error'>Adding your email address...</span>");
            $.ajax({
                url: 'inc/store-address.php', // proper url to your "store-address.php" file
                data: $('#signup').serialize(),
                success: function(msg) {
                    $('#message').html(msg);
                }
            });
            return false;
        });
    });
</script>

Required pieces…

– `index.html` constructed as above or similar. With jQuery, the appearance and options are endless.

– `store-address.php` file downloaded as part of PHP examples on Mailchimp site and modified with your API KEY and LIST ID. You need to add your other optional fields to the array.

– `MCAPI.class.php` file downloaded from Mailchimp site (version 1.3 for PHP 5). Place it in the same directory as your `store-address.php` file or you must update the url path within `store-address.php` file to find it.

Posted on

WordPress tags and categories cannot share slugs

There is a very frustrating bug in WordPress that seems to not allow you to use the same slug for both a Category and a Tag.

http://www.mysite.com/category/computers
http://www.mysite.com/tag/computers

When creating Categories or Tags, WordPress will automatically append a `-2` to any duplicate slug. In other words, if you try to create a Category and a Tag both named “Computers”, WordPress will make sure one of the slugs is spelled `computers-2`. If you then try to edit the slug for the Category or Tag to remove the `-2`, it will not allow it and give you an error.

Since Categories and Tags are two different things, duplication of a slug should not be an issue. If you Google search “wordpress category and tag slug”, you will find a lot of complaining going back a very long time, and a lot of closed support threads at wordpress.org without any official responses.

However, there is a workaround to this issue.

Example:

– desired Category and Tag name: “Computers”
– desired slug: `computers`

1. Make sure no Categories or Tags already exist with a slug spelled `computers`.

2. Create the “Computer” Category first and if you leave the “Slug” field blank, WordPress will automatically create the slug `computers`. You can also type “computers” into the Slug field when creating this Category. The important thing here is to make sure your slug is spelled correctly before moving on.

3. Create the “Computer” Tag. At this step, you must manually create the slug `computers` by typing “computers” into the “Slug” field. Otherwise, if you leave the “Slug” field blank, WordPress will create the slug automatically, it will be spelled `computers-2`, and WordPress will not allow you to remove the `-2` through edits. You would have to delete the Tag entirely and start over.

That’s it. There are other workarounds to this issue which involve creating Tags on the fly when the corresponding Category already exists. However, the steps I’ve outlined above are the simplest. Good luck!

Posted on

Integrate Tooltipster with jQuery Validate

Prerequisites:

– Tooltipster Plugin version 2.1 or 3.0 (The raw code for version 2.1 can be found inside the first jsFiddle below.)
– jQuery Validate Plugin

First, initialize the Tooltipster plugin (with any options) on all specific `form` elements that will display errors:

$(document).ready(function () {

        // initialize tooltipster on form input elements
        $('#myform input[type="text"]').tooltipster({ 
            trigger: 'custom', // default is 'hover' which is no good here
            onlyOne: false,    // allow multiple tips to be open at a time
            position: 'right'  // display the tips to the right of the element
        });
    
});

Second, use Tooltipster’s advanced options along with the `success:` and `errorPlacement:` callback functions built into the Validate plugin to automatically show and hide the tooltips as follows:

$(document).ready(function () {
    
        // initialize validate plugin on the form
        $('#myform').validate({
            // any other options & rules,
            errorPlacement: function (error, element) {
                $(element).tooltipster('update', $(error).text());
                $(element).tooltipster('show');
            },
            success: function (label, element) {
                $(element).tooltipster('hide');
            }
        });
    
});

Working Demo: jsfiddle.net/2DUX2

Note that this code example takes advantage of the new Tooltipster API features released in version 2.1 on 2/12/13

For Tooltipster version 3.0

The latest version of Tooltipster, version 3.0, is supposed to be working more correctly than version 2.1.

That’s fine, except that an animation flicker is now occurring on every single keystroke even when no content has changed. I suppose we could disable the default `onkeyup` option in jQuery Validate, but when multiple rules are used, the user would not be aware of his data entry violation until after leaving the field or clicking the submit button.

The workaround is to set the `updateAnimation` option to `false`.

$(document).ready(function () {

        // initialize tooltipster on form input elements
        $('#myform input[type="text"]').tooltipster({ 
            trigger: 'custom',     // default is 'hover' which is no good here
            onlyOne: false,        // allow multiple tips to be open at a time
            position: 'right',     // display the tips to the right of the element
            updateAnimation: false // stops the flicker on every keyup
        });
    
});

Demo: jsfiddle.net/2DUX2/2/

I’ve made a suggestion to the developer to simply check the new incoming content against the existing content and only run the animation when they’re different. I can see other practical applications for this… any situation where the same content is sent repeatedly but yet we still want an animation to occur when/if it changes. I’ll update this posting as the situation warrants.

UPDATE:

The Tooltipster developer made the following suggestion to preserve the message update animation in version 3.0, which works very nicely. From within the jQuery Validate plugin’s `errorPlacement` callback function, this simple code makes sure the error message is not blank and has changed before calling Tooltipster’s `show` method. This has the added benefit of greatly reducing the number of calls to Tooltipster.

$(document).ready(function () {
    
        // initialize validate plugin on the form
        $('#myform').validate({
            // any other options & rules,
            errorPlacement: function (error, element) {
                var lastError = $(element).data('lastError'), // get the last message if one exists
                    newError = $(error).text();               // set the current message
            
                $(element).data('lastError', newError);  // set "lastError" to the current message for the next time 'errorPlacement' is called
      
                if(newError !== '' && newError !== lastError){  // make sure the message is not blank and not equal to the last message before allowing the Tooltip to update itself
                    $(element).tooltipster('content', newError); // insert content into tooltip
                    $(element).tooltipster('show');              // show the tooltip
                }
            },
            success: function (label, element) {
                $(element).tooltipster('hide');  // hide tooltip when field passes validation
            }
        });
    
});

Demo: jsfiddle.net/2DUX2/3/

Posted on

404 errors (url: /a) in Google Webmaster Tools

As you may already know, I’ve been a Web Developer since 1999 and run Website Setup dot net.

I use Google Webmaster Tools for several of my and my customers’ websites. Recently, under Diagnostics > Crawl Errors, I discovered quite a few 404 (not found) errors pointing to the same non-existent location:

http://baudindentalmission.org/a

Sure, a 404 error is totally expected. After all, the “/a” directory does not exist, however, the question remains, how did the Google-bot get the idea to crawl there in the first place? Perhaps a programming error on my part or a typo?

Well, this is strange, I’m now seeing it on more than one site and I’m finding other people complaining about the same thing suddenly appearing in their Webmaster Tools Dashboards.

Let’s now examine my Dashboard’s Linked From data:

http://baudindentalmission.org/donate.html
http://baudindentalmission.org/haiti.html
http://baudindentalmission.org/about.html

Hmm, no clues there. Nothing in any of those pages link to a “/a” location.

Let’s dig further into the JavaScript Includes. Searching the first JavaScript file (which happens to be the jQuery JavaScript Library) for “/a”…

<script src="/ajax/jquery/jquery-1.5.min.js" type="text/javascript"></script>

We find this occurrence…

<a style="color: red; float: left; opacity: .55;" href="/a">a</a>

What’s that doing in there? Actually, it doesn’t matter… it’s part of jQuery and very smart programmers spend countless hours developing, troubleshooting and refining jQuery… so, for this discussion, we’ll just trust them. What’s more important is that the Googlebot is actually crawling around inside an external JavaScript file, presumably searching for content. Why? Ask Google.

Personally, I fail to see the value in this practice of crawling JavaScript. If it’s searching for malware or some SEO trickery then great, but it shouldn’t be following things it thinks (assumes) are valid links and creating 404 errors. If it’s crawling JavaScript in order to figure out your site navigation, then shame on Google for rewarding such a poor programming practice. (Your content and code should be two separate things!) Malware or some goofy JavaScript navigation system, either way, these things should be penalized with lower rankings or removed from Google altogether.

What’s even more odd is that the particular JavaScript file it’s crawling is jQuery itself. Since jQuery is part of the Google Libraries API, you’d think it would quickly realize crawling around in there is kinda pointless.

Here is a jQuery Bug Report on this very issue. According to notes in that report, this is not something they intend on fixing. I can’t say that I’d blame them for this attitude, Google should not be crawling JavaScript if it doesn’t know how to properly parse it for valid content. (Although as mentioned before, I can’t imagine how one could argue that JavaScript should contain any content at all. Best practices indicate always maintaining a separation between content and code.)

What’s the solution to all this? You don’t want a bunch of 404 errors piling up… although Google is smart enough to drop bad URL’s from their index, they can also penalize a site for this by reducing the crawl rate.

Solution 1: Redirect “/a” to your home page with a 301 in your htaccess file. This approach has two minor issues. One, that your server is doing the work by sending the Googlebot back to your home page and two, the page never existed in any Search Index, theoretically, there should be no reason to redirect it elsewhere.

Solution 2: Block this location from the Googlebot in your robots.txt file. This puts the responsibility on Google to stay out of someplace they don’t belong.

Disallow: /a/
Disallow: /a

After several weeks, you should see these erroneous 404 errors disappear. Good luck!

_________________

EDIT: In this article, I’m only assuming this is an issue for sites that host jQuery locally. I cannot imagine the google-bot trying to crawl scripts hosted on it’s own CDN!

_________________

EDIT 2: Here is an official response from a Google employee posting in Google Groups:

JohnMu
Google Employee
4/28/11 – 4:39 AM

Hi guys

Just a short note on this — yes, we are picking up the “/a” link for many sites from jQuery JavaScript. However, that generally isn’t a problem, if we see “/a” as being a 404, then that’s fine for us. As with other 404-URLs, we’ll list it as a crawl error in Webmaster Tools, but again, that’s not going to be a problem for crawling, indexing, or ranking. If you want to make sure that it doesn’t trigger a crawl error in Webmaster Tools, then I would recommend just 301 redirecting that URL to your homepage (disallowing the URL will also bring it up as a crawl error – it will be listed as a URL disallowed by robots.txt).

I would also recommend not explicitly disallowing crawling of the jQuery file. While we generally wouldn’t index it on its own, we may need to access it to generate good Instant Previews for your site.

So to sum it up: If you’re seeing “/a” in the crawl errors in Webmaster Tools, you can just leave it like that, it won’t cause any problems. If you want to have it removed there, you can do a 301 redirect to your homepage.

Cheers
John