For plugin developers like myself, it’s a pain in the @!+ as I’m now seeing users run into this problem on a daily basis for a few weeks now, and it has become obvious that the problem in every case is the forced loading of jQuery library files from CDNs, particularly Google.

The aim of loading jQuery libraries from external sources is to speed up page loading time, so no wonder why theme makers jump at this quick speed upgrade.

However, whilst there’s nothing wrong with doing this theoretically, they way they’re going about it couldn’t be more wrong! The various misleading posts circulating the web are most likely the cause of such a widespread problem, and now we’re starting to see the consequences as time passes.

Why is this wrong?

As I mentioned above, there’s nothing wrong with loading files from a CDN, however, there’s two major things themes do wrong:

The first major issue is that I have yet to see a theme that does this load the latest jQuery version used by WordPress! This presents a load of problems because other plugins that rely on the jQuery library are forced to use outdated libraries which may conflict with some of the code written with later library versions in mind.

The second major mistake is that they’re taking it upon themselves to do this in the first place. My opinion is that themes have no place in messing with the jQuery libraries and WordPress dependencies. Themes should must take into account that plugins will be installed, and these plugins should have access to the standard libraries provided by WordPress.

How can I check if I have this problem?

The major browsers these days all have their own code viewers which makes it easy to check which scripts are loaded. The screenshots below show how this is done in Google Chrome, which is also similar to doing this with FireFox and the Firebug extension.

To bring up the developer window, right click anywhere on the webpage and the click on ‘Inspect Element’. You’ll see a window appear similar to the one below, click the Sources (in FireBug it’s Scripts) tab, and look at your scripts there:

As you can see, the location of the jquery.js file is on the Google server, and clicking on that file shows you the contents which includes the version number (it’s also usually in the URL). In this case, the theme is loading jQuery 1.4.4.

Where does my theme do this, and how do I fix it?

This is the most common question I get these days, which is what inspired this post. Thankfully, the approaches taken by most theme are the same, or similar therefore easy to identify. Unfortunately, not all will be so lucky.

In either case, when trying to find the location of where this is done, you’ll need to use search functions in your text editors.

Typical – functions.php

This is the usual situation.

wp_deregister_script('jquery');
wp_register_script('jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js', false, '1.4.4');
wp_enqueue_script('jquery');

The solution is easy though, just delete it! WordPress will then start loading its own copy of the jQuery library.

Worse – header.php

Less often, but astoundingly too often, some themes go ahead and hard-code the jQuery file with pure html similar to:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js" />

This is worse because it goes against the whole dependency system WordPress uses to load the right scripts during the wp_head() function executed usually within the header.php file.

The fix involves one to three steps (depending on how many mistakes your theme maker made):

Step 1 - Remove the line above.

Step 2 (if step 1 fails) – Your theme may be doing something even naughtier which is failing to include the wp_head() PHP function in your document head, meaning plugins like Events Manager can’t include its own javascript files. Try replacing the line you just deleted with this:

<?php wp_head(); ?>

Step 3 (if Step 2 fails) - If you had to add wp_head(), chances are you’ll need to add wp_footer() too, which is done within your footer.php file above the body closing HTML tag.

The upside once you fix this is that your theme will now work with more plugins. However, if you had to do step 2 or 3, you may want to reconsider where you get your themes from (if you made it yourself, lesson learnt i hope!).

Worst of all – unknown

Your theme maker decided to get uber fancy and demonstrate their skills by making this modification somewhere in the myriad of custom included files. Your best bet is to use a search tool and look at all your theme files for words like jquery or google.com. Chances are if the mod isn’t done in your header.php file, they used the method for the function.php file.

If your theme has found another ingenious way of doing this… I’d say your theme is too smart to be used on WordPress, save yourself the headache and move on.

The ‘Right Way’ to host external libraries

Whilst there’s more ways than one to do this, the two most sensible ways to do this are:

• Use a plugin that does this for you, such as Use Google Libraries and makes sure the right jQuery version is loaded according to your WP version.
• Host all your javascript, css, image and other files on a CDN such as Amazon S3 or CloudFront. It’s cheap and effective. Caching plugins such as Super Cache or W3 Total Cache make this very easy to set up and are well documented.

Between the two, if you can make use of minify functions (W3TC has this function) to merge all js files into one cached file, then the best choice is the second one if your end goal is increasing your page speeds and/or reducing your server load. However, if you’re on a budget, or you’re having issues minifying your scripts with caching plugins then Use Google Libraries will still help a lot and is highly recommended.

As you can see, these have nothing to do with your theme, as it should be!

It has gotten to the point that it made sense to split my posts from any company blogs and move it over to a personal space. I hope to find the time to write more, particularly tidbits, tips and tricks on my day to day work with web technologies, along with the possibility of a rant or two about something or other.

So… I’m almost starting from scratch. All my posts on netweblogic.com have been moved over. I may have lost some comments in the process (which is why you shouldn’t go with plugins like Disqus), but if more content is produced as a result this move, then it will be worth it.

Under the Hood

I’m a fan of simplicity, as well as not re-inventing the wheel (especially when you can improve it!), so I’ve gone with the lovely Elegant Themes Modest theme with some minimal CSS changes, which does what it says in the box, and will allow more focus to be placed on the content. I may even take it a step further and simplify it even more by removing unnecessary scripts, fonts, etc.

Welcome to my new online home. Don’t expect regular posts anytime soon, but hey, that’s the goal and this is the first step

Fortunately, wordpress makes this sort of customization easy with its amazing API. These four lines of code are all that’s needed:

function my_wp_admin_ban(){
	if( !current_user_can('activate_plugins') ){
		wp_redirect( get_bloginfo('wpurl') );
		exit;
	}
}
add_action('admin_init','my_wp_admin_ban');

You can get this working in two ways:

1. Copy the contents above into a file named wp-admin-ban.php (put them between ) and move it to wp-contents/mu-plugins folder. If the mu-plugins folder doesn’t exist, create it. This will be available across any theme on your site.
2. Copy the code to your theme’s functions.php file, which restricts functionality to that theme.

If you can think of a good membership plugin on the wordpress repo that does the trick, feel free to drop me a line!

On that note, here’s two plugins you might find useful:

• My own ajax login plugin so users can log in and register with smooth ajax effects from the front of your site!
• Membership Plugin If you’re looking for a good premium membership plugin with great support (personally recommended, tried a few others before it). They also have a lite free version for you to try out.

This was inspired by David Walsh’s MooTools implementation. Check out his demo to see functionality, it’s the same thing except you can control the fade speed and cursor image, as long with start/end dates for special occasions.

Activate it for Valentines Day for a special surprise, if that’s today you’ll know what I mean

Download it here!

Installation

Download the zip file, and either:

• Unzip and upload the cursor-tril folder to your plugins directory, then activate in your plugins page.
• Upload via the add new plugin feature in your admin area.

I came across a problem like this where a custom theme I made needed to accommodate the multilingual capabilities of qTranslate for some small snippets of text here and there which could be added in the theme options page (e.g. address, slogans etc.). The amount of work that would be required to make a multilingual options page was not justifiable for the project. So…. I came up with a pretty simple solution which I’m sure others can easily use in their plugins and themes:

Basically, if used, you can pass along text wrapped in curly bracket tags, much like html except the tags use curly brackets and the tag names are the language code(e.g. en_US, de_DE, fr_FR). The result is that you could add this to a text box:

{en_US}english text{/en_US}{fr_FR}french text{/fr_FR}

With the above string the function will choose the correct language based on the current wordpress locale, and if that doesn’t exist, revert to the first language in the string. This is also compatible with non-translated strings. Whilst not ideal for a whole post, this would definitely come in handy for smaller snippets of text, such as widget titles, theme texts, etc. where fully fledged translation functionality is not needed.

Without further ado, here is the function:

/**
 * Separates a string by {lang_code}{/lang_code} 
 * style wrappers and returns the desired locale. If the locale 
 * parameter is empty, function will use default locale (e.g. en_US).
 * If no local is matched, the first language is used. If no brackets 
 * are enclosed, the $string param is returned as is.
 * @param $string
 * @param $locale
 * @return string
 */
function ml_string($string, $locale = ''){
	$locale = ($locale == '') ? get_locale():$locale;
	//Do a regex and extract all text within braces
	$matches = array();
	preg_match_all('/{([a-zA-Z_]{5})}([^{]+){/[a-zA-Z_]{5}}/', $string, $matches);
	if( count($matches[0]) > 0 ){
		//Check if the language we want exists, if not we take the first language there
		foreach($matches[1] as $key => $lang){
			if ($lang == $locale) {
				return $matches[2][$key];
			}
		}
		return $matches[2][0];
	}
	return $string;
}

If you’d like to add or remove a specific filetype that can be uploaded to wordpress via the media library, you can insert this PHP code in your theme functions.php file:

function my_myme_types($mime_types){
	//Adjust the $mime_types, which is an associative array where the key is extension and value is mime type.
	return $mime_types;
}
add_filter('upload_mimes', 'my_myme_types', 1, 1);

Here is an example of what you can do to add and remove a new filetype (in this example, I’m adding an extension that already exists, but the concept is the same):

function my_myme_types($mime_types){
	$mime_types['avi'] = 'video/avi'; //Adding avi extension
	unset($mime_types['pdf']); //Removing the pdf extension
	return $mime_types;
}
add_filter('upload_mimes', 'my_myme_types', 1, 1);

You can also reset the allowed filetypes by creating a new array within the function and returning these values:

function my_myme_types($mime_types){
	//Creating a new array will reset the allowed filetypes
	$mime_types = array(
		'jpg|jpeg|jpe' => 'image/jpeg',
		'gif' => 'image/gif',
		'png' => 'image/png',
		'bmp' => 'image/bmp',
		'tif|tiff' => 'image/tiff'
	);
	return $mime_types;
}
add_filter('upload_mimes', 'my_myme_types', 1, 1);

If you’d like to see what filetypes are currently supported by wordpress, check out the function get_allowed_mime_types located in the wp-includes/functions.php file.

This becomes especially important when considering the crucial and complex plugins that make your site work the way you need, as finding a replacement in the future may be prove to be much more laborious than doing a little due diligence beforehand. Imagine, for example, if your photo gallery stopped working when you upgrade to the latest version of WordPress!

Due to this, it’s important to take certain things into consideration when choosing a plugin, and if keep these in mind you’ll probably find that your selected plugins get updated with the new WP releases and are regularly improved. There’s lots of factors that you need to consider when choosing a plugin. Below are some of the major things to think about:

How times has this plugin been downloaded?

Check the stats tab on the plugin page (or see the downloads number when searching through plugin lists). This is important because popular plugins are more likely to be maintained and updated by the author if it’s popular. Do remember to look and see if the plugin is new, as quality plugins are created regularly and that may explain lower download numbers.

How many ratings does it have?

Ratings lower than 4 need to be examined carefully, as there might be something wrong with the plugin. Keep in mind that some plugins may be very good but a disgruntled and impatient user may have given it a bad rating and lowered the average overall rating to give it the impression of being a terrible plugin. As a developer of plugins myself, I can sympathize with that! Don’t let a low number of ratings fool you though, usually a plugin has to be very popular to get many feedbacks.

What version of wordpress does it support?

If the plugin author doesn’t update the plugin for a long time, it will be outdated and might not work with the latest versions of wordpress. Generally, if a plugin works with version 2.8 onwards there is a high probability it works with the current versions of wordpress (3.0 at time of writing). Note that often a plugin works perfectly well on the latest version, but the author never updated the plugin details to reflect this (can be time consuming if you author many plugins).

When was it last updated?

If it’s not updated recently, it may be that the author won’t improve it further and in the long term it might not work anymore. If you see a plugin hasn’t been updated for over a year, you can probably assume that it’s not being maintained anymore and there’s a good chance it won’t continue working on WordPress for much longer (if it doesn’t already break your site). As I said previously though, plugins that work in 2.8 and up have a high chance of still working, especially the less complex ones.

What are people saying in the support forums?

On the plugin page you’ll see on the bottom of the right sidebar recent forum posts, if people have problems they might post a complaint there. Popular plugins may often have their own support forums too, so check there as well. It’s also good indicator if the author responds to the complaints and feedback, that means they’re listening and have interest in maintaining the plugin.

Does the plugin author have a dedicated plugin page?

If the plugin has a dedicated page on another website, there is usually a higher chance of the plugin being supported regularly by the author.

Has the author produced any other quality plugins?

This is especially important when you are considering a new plugin. If the author has other plugins that are popular and well received, chances are their new plugin will be of similar quality.

Keep in mind that a plugin isn’t necessarily bad if it doesn’t meet all these criteria, but from my experience,  plugins that fulfill more of the criteria above have a higher chance of being a great plugin. However, that doesn’t mean that every plugin must meet these…. as I said, these plugins are provided for free by hard-working developers. I strive to maintain all my plugins, but it’s not uncommon for me to not update a plugin’s list of supported WP versions for example.

If you think about it, what stops someone from logging in locally to your server and grabbing your passwords stored on file? The answer is a secure data center. I recently read a confession on reddit (can’t remember the link) where a convicted hacker goes “public” and shares some of his experiences. One thing that really hit home is that when he prepares to attack a high value target, he often gets in by accessing an insecure pc of a user that has access to the actual target. See…. security is relative.

So when you think about website security, don’t just think about the website itself, think about other entry points too, online and offline. Unnecessary open ports, public phpMyAdmin access and so many other factors can leave you open to attacks.

The point of this post is just to show some support to the WP team for doing such a great job, and highlight that should your blog ever get hacked don’t jump to conclusions. NetworkSolutions did and are now looking pretty silly for doing so. By the way, they haven’t admitted being at fault in their blog, which ironically is powered by guess what?!

Compromised security could be due to a plethora of possibilities; insecure file permissions, an old server OS not updated to fix security loopholes, packet sniffers for unencrypted logins or even something as simple as leaving yourself logged in at a public PC. I’m not saying WordPress is perfect and there are no potential security holes, but then again you can’t say that for any piece of software, so give them a break and the benefit of the doubt!

• Most significant – merge with WordPress MU, which means everyone (with the right hosting setup) will be able to host more than one blog instance off one installation. More on that soon….
• Installation
  • Admin passwords are now set during installation.
• Add/Edit Post/Page Improvements
  • Ability to add a featured image to a post or page
  • Post Types : you can now “categorize” your posts even further by giving them post type attributes and adding further meta data on top of that via taxonomies. Currently, WP3.0 Beta 1 does not offer a UI for this, but have a look at the Custom Post Type UI plugin and watch the video on that page for a good grasp of what’s possible.
• Themes
  • Menu management. You can now completely sort your menu including adding category pages, external links. If you’d like something to make your menu sorting easy for 2.x page menus, try out pageMash (only allows sorting of your pages, but has a similar concept to the 3.0 functionality).
  • New default theme, Twenty Ten, which is now the only bundled theme. Old themes still available from the built in theme installer.
  • Custom templates for post types and individual authors.
• Plugins
  • When adding a plugin, the list of plugins now has a details and install now link on the right hand side. Previously, this was one link that went to the author plugin page. Nice for us plugin developers but not very intuitive for users (and power users like myself)

All I can say about 3.0 is so far so good! I look forward to further Betas