a {
    background: url('http://kovshenin.com/core/wp-content/themes/publish/images/external-link.png') right center no-repeat;
    padding-right: 14px;
}

a[href^="http://kovshenin.com"], a[href^="/"], a[href^="#"] {
    background: none;
    padding-right: inherit;
}

The first one selects all the links on the page, gives them the external link icon and a padding on the right. The second selector fetches all links that begin with my domain name, relative links and empty links and then removes the background and padding set by the first selector.

This solution might need a few tweaks depending on your linking structure and perhaps a fallback stylesheet for browsers with no CSS3 support. Another option can be jQuery, somewhere in your head section after jQuery has been loaded:

jQuery(document).ready(function($) {
    $.expr[':'].external = function(obj) {
        return !obj.href.match(/^mailto:/) && (obj.hostname != location.hostname);
    };
    $('a:external').addClass('external');
});

Which would add an external class name to all links where hosts don’t match the current host, and then use the a.external selector to style your external links as shown in the example earlier. This solution will “blink” though because jQuery has to first load and initialize before it can read all the contents of your page. It’s a matter of milliseconds so most people won’t mind. Enjoy!

As shown in the video, the styles editor pops out as a dialog box which you can move around the page. The dialog itself contains a select box where you get to pick a certain style (like headings, menu anchors, etc) and the actual properties below. An “element picker” might also be introduced, but has to be very well implemented in order to work.

So yeh, editing WordPress themes on the fly is possible, the parameters are saved when the save button is clicked via a short AJAX call and the next page will contain the modified CSS. Next up is column widths, probably the most dangerous thing to mess around with ;)

One of my first experiments is the color wheel and there are plenty of jQuery plugins and code snippets that could do that. With a few more research about colors and their hex codes, I found a way to determine a color darker or lighter than the chosen once, enabling me to do the gradient fill, drop-down menu colors. The HSL values returned by the color wheel let me switch the font color, so that the text appears white on a dark background and black on a light one.

As you can see the color wheel not only affects the website header, but also the links on the page, giving them a darker color than the one chosen, giving a better contrast. Of course it is not perfect, but I’ll get there eventually ;)

add_filter( 'script_loader_src', 'my_script_loader_src', 10, 2 );
function my_script_loader_src( $src, $handle ) {
    if ( $handle == "jquery" )
        return "http://code.jquery.com/jquery-1.5.min.js";
    return $src;
}

And that’s it! Now every call to wp_enqueue_script jquery will pass through this filter and load up 1.5 instead of the one shipped with your WordPress bundle. Feel free to change the URL of the jQuery script to different CDNs including Microsoft’s and Google’s.

I guess this post will be outdated upon the next WordPress release, but it still may be valuable, since the same trick is used to run jQuery and other libraries shipped with WordPress from different sources like Google or Amazon CloudFront.

Check out the qrTip Demo and hover over the links to feel the taste of what it’s like.

Why would you ever need this? Well mainly be cause it’s cool, and with this plugin you can provide a link to a mobile version of your website, so that people could hover, scan the QR code using their mobile and fire up the link on their device! Yeah, a little bit inspired by the Chrome to Phone extension which is quite awesome but not yet compatible with all browsers and devices out there.

Here’s a quote from the behind the scenes of this plugin section if you’re into development:

Well, I basically took the ColorTip jQuery plugin and wrote a little bit of extra code inside that injects images inside the tooltips. The actual images are coming from the Google Charts API! I also use the js-uri to get the relative links right.

You can download the sources in an archive or use git to grab it directly from my github account:

$ git clone http://github.com/kovshenin/qrtip.git

That’s all there is to it! Hope you like the plugin and find it useful in some way. You might want to tweet it too! I would also appreciate if you commented on bugs under Windows and Mac browsers. I didn’t test it on anything but Chromium on Ubuntu ;) Cheers!

The problem with Facebox is the lightbox placement. The dialog itself is placed in the center of the page horizontally with a preset margin from the top, which looks good, but what I did notice is that the box containing the loading icon is being placed somewhere to the left part of the page. Well at least on Firefox 3.5.7.

I couldn’t help but noticing that FamSpam and StaffTool are using a different set of functions and styles for the lightbox placement and copying them into my code solved the issue.

The two functions are called getPageScroll() and getPageHeight() and are marked as quirksmode.com inside the code. The #facebox style in the CSS lacked a width: 100% which seems to have solved the issue for now. There’s also a certain overlay in the original version which includes an interesting IE6 hack:

height: expression(document.body.scrollHeight > document.body.offsetHeight ?
	document.body.scrollHeight : document.body.offsetHeight + 'px');

The versions at Stafftool and FamSpam however don’t mention any overlays in there code. Pretty messy, huh? Well, other than that, the plugin is very lightweight and cross-browser, works well in IE and closes the popup when pressing Esc, which unfortunately has to be hand-coded in other versions of the Facebook-style dialog boxes.

Grab the code at GitHub and enjoy: Facebox for jQuery.

Pager is nothing but a few links next to your cycling block with page numbers, which switch the cycle upon click. It’s very useful when you have to create, say a list of services a company provides, with sweet lightboxes (don’t confuse with the Lightbox plugin), perhaps with some images, cycling through their descriptions, yet we’d like our visitors to be able to switch through the services manually, without having to wait. This is exactly what the Pager transition does, but hey, who the hell would want page numbers instead of their services names?

This is where pageAnchorBuilder comes in, and it’s not quite obvious what has to be done to make this work. According to the jQuery Cycle documentation it’s:

pageAnchorBuilder – callback function for building anchor links: function(index, DOMelement)

So here’s a demonstration of how this would work. Let’s setup a quick cycle, with a few options. Perhaps you’ll need more than I listed below ;)

jQuery('#fade').before('<div id="nav" class="nav"></div>').cycle({
	pager: '#nav',
	pagerAnchorBuilder: paginate
});

So paginate is a callback function which takes two arguments, the index and the DOM element. Using the index will work just fine. Let’s see how this works with text:

function paginate(ind, el) {
	if (ind == 0) return '<span>Service One</span>';
	else if (ind == 1) return '<span>Service Two</span>';
	// and so on
}

I think that’s pretty straightforward once you understand how it works. Let’s try some images:

function paginate(ind, el) {
	return '<img src="http://whatever.com/services/service' + ind + '.jpg" />';
}

So name your images service0.jpg, service1.jpg, etc. And my favourite, CSS classes:

function paginate(ind, el) {
	return '<div class="service' + ind + '"></div>';
}

Then just add a few .service0, .service1, etc. classes in your stylesheet, voila! Hope that helps, and don’t forget about the other useful options. Cheers!

A Handwritten WordPress Plugin is a huge set of files, with hundreds of duplicate lines of code and tonnes of commented code. The MVC/MVP models are usually transformed into the AIO (All-In-One) model. The only version control systems used are the “Copy & Paste” and “Undo & Redo”. The Core Upgrade process does not involve reading the changelog, backing up, etc.

Okay this is not a very smart thing to do, but sometimes you just need to, especially when you’re in a hurry (duh!). I’m not going to go in detail about the plugins, because you wouldn’t understand it anyway (no offence, I don’t understand most of it either), but let’s just say that I was using the Post Tags interface that you see in your “Edit Posts” admin interface. The sweet little box where you can type some tags or choose from the most used ones. All I did was copy the HTML contents of that little box onto my page, and it used to work (in 2.7 and 2.8), but as soon as I upgraded to 2.9, bang! It suddenly stopped. The javascript bindings were gone!

I figured out that the bindings were all made in the post.js so I took a look at the diff between 2.8 and 2.9 – completely different. The major change was the jQuery selector from span#ajaxtag to div.ajaxtag (line 99 in post.dev.js) which prevented all the other bindings. A few more ids have changed to include the tax name, and some other minor changes which I didn’t figure out yet. Although what’s the point in figuring it out? Wait until 3.0 is released and rewrite the plugin again, meh!

I did a lot of thinking here. This was not the only interface that broke, and rewriting everything on every core upgrade would be pretty difficult. People talk a lot about WordPress upgrades, plugins compatibility, etc. But most of the time they refer to plugins developed by other people, which sooner or later will get an upgrade. So waiting for a few weeks before launching the core upgrade generally does the job. But what if it’s a completely different page with a completely customized admin interface?

I worked a lot with WordPress metaboxes a few weeks before the upgrade and today I figured out that the best and easiest way of building WordPress admin interfaces would be, that’s right, metaboxing. The standard components used in the edit posts/pages interface (tags, publishing, categories, custom fields, etc) are simple metaboxes. So why copy HTML if you could simply use the predefined ones? And when a change is on its way, you’d sleep tight. Unless of course you’re interacting with the standard components from your customized ones, which involves using certain selectors for ids and classes. In that case you’ll just have to read the changelog, tickets (over 500 for WordPress 2.9) and of course code diffs.

Creating your own custom metaboxes is not as difficult as it is at first sight (yet I still haven’t figured out how to save their positions via AJAX, but I will). You will get the hang of it after your third or fourth metabox ;)

P.S. Have you noticed the new post thumbnails here? They used to be wide images, now they’re h2 text and small thumbnail. I love WordPress shortcodes ;)

You know I browse the web a lot – StumbleUpon, Digg, Twitter, etc. I go through tonnes of content, so today I made a short list of a few interesting jQuery and Javascript links that made my day! For rookies and for pros, check them out (ordered randomly):

• 23 Best jQuery Facebook Style Plugins
• Process XML in the browser using jQuery
• Dynamically Create Charts Using jQuery Flot and Google Analytics
• jQuery Sticky Tooltip Script
• Making a Cool Spotlight Effect with jQuery
• How To Create Simple, Stylish and Swappable Image Captions
• Creating a Simple Photo Tagging System
• Beautiful Slide Out Navigation: A CSS and jQuery Tutorial
• iPhone Scrolling Experience in Your Browser with jQuery Plugin

Now you tell me – who needs Flash when you have Javascript? ;) Oh and by the way, if you’ve anything to add to the list (preferably articles published in late 2009) feel free to suggest via comments. If you’re looking for even more jQuery love, follow the real-time search results for the #jQuery tag on Twitter. Cheers!

All the problem with WordPress is script dependancies, and this applies not only to jQuery but to all the other predefined javascript libraries (prototype, scriptaculous, thickbox, see wp_enqueue_script for more info). It’s all about the handles and plugins that use jQuery will probably use the jquery handle in their dependency lists, which will automatically make WordPress include the standard jQuery from its wp-includes directory. This means that using the code:

wp_enqueue_script("my-handle", "http://s.kovshenin.com/jquery.js");

You might end up including two instances of the jQuery library, one from your CDN (s.kovshenin.com) and another one from the WordPress wp-includes directory, which will end up in a total mess. Strange though, that you cannot redefine an already known handle, such as jquery like this:

wp_enqueue_script("jquery", "http://s.kovshenin.com/jquery.js");

The javascript library will still be loaded from the default location (wp-includes on your local web server). So the right way to do it is with a little hack in your functions.php file (in case you’re doing it within your theme) or any other plugin file (in case you’re doing it within your plugin):

add_filter('script_loader_src', 'my_script_loader_src', 10, 2);
function my_script_loader_src($src, $handle) {
	if ($handle == "jquery")
		return "http://s.kovshenin.com/js/jquery.1.3.2.min.js";

	return $src;
}

Then any call to wp_enqueue_script with the jquery handler will output the correct path to your CDN version of jQuery. Oh and please, try not to use generic function names like my_script_loader_src, I used that just as an example, we don’t want any function name conflicts and can’t expect other plugin/theme developers to use non-generic names ;)