Posts Tagged ‘jquery’
February 11th, 2010
I recently came across an awesome plugin for jQuery which is called Facebox. Facebox produces a clean lightbox that can be a container for popup images, text and basically any HTML layout as well as AJAX powered content.
Facebox: Creating Facebook-like Dialogs
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:
1
2
| 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.
February 9th, 2010
One very awesome and useful plugin for jQuery is jQuery Cycle, which pretty much works out of the box, but browsing through the second part of the Intermediate Demos we’ve seen a click transition called Pager, which is somewhat tricky.
Neat Transitions with the jQuery Cycle Plugin
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 ;)
1
2
3
4
| 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:
1
2
3
4
5
6
| 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:
1
2
3
4
| 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:
1
2
3
4
| 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!
December 22nd, 2009
Yup, WordPress 2.9 is finally out and I’ve seen a lot of people upgrade immediately – sweet thing to do, I did so too and hadn’t had any problems here (I’m not using too much plugins), then I switched over to the 3.0 branch, all good! The semi-square buttons in the admin interface are fixed by the way ;) Anyways, this post is not about my blog, but about something I’m working on locally in the intranet of a company. And here’s a quick reminder: do not upgrade the running instance before you checked everything on a duplicate testing one, especially if a bunch of plugins there are handwritten ;)
Upgrade to WordPress 2.9: Plugins Gone Bad
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 ;)
December 8th, 2009
Remember the “inspired” blog posts series I started back in November? Well, let’s keep playing that game and today’s topic is jQuery and Javascript. The things you can do with javascript today are pretty impressive and sometimes unbelievable. Starting from simple AJAX calls and ending up with complete rich user interfaces with sweet animation (poke Facebook for instance).
Who Needs Flash When You Have Javascript?
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):
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!
November 13th, 2009
This may seem like an easy task to do but is quite tricky in WordPress. Using a CDN these days is very popular, cheap and helps speed up your website taking the load off your web server. I personally love Amazon CloudFront! The tips at Google Code suggest you serve all your static content from different domains, preferably ones without cookies, so CDNs are perfect.
Serving Static Content From CDNs
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:
1
| 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:
1
| 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):
1
2
3
4
5
6
7
8
| 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 ;)
