Artisteer is the first and only Web design automation product that instantly creates fantastic looking, unique website templates and blog themes.
Wednesday, February 9, 2011
Sunday, January 9, 2011
5 Points you should know about JQuery
jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. jQuery is designed to change the way that you write JavaScript.This article describe five useful features of jQuery that you might not know about.
1. You don't have to use $(document).ready() anymore, though you'll still see plenty of code out there that does. If you want to run a function when the document is ready to be manipulated, just pass that function directly to $().
2. You probably already know that you can pass a tagname to $() to create an element of that type, and that you can pass (as a second argument) an object of attributes to be set on the newly created element. This second argument can be any object that you would pass to the attr() method, but in addition, if any of the properties have the same name as the event registration methods, the property value is taken as a handler function and is registered as a handler for the named event type. Similarly, if any of the properties has the name “css”, “val”, “html”, “text”, “data”, “width”, “height”, or “offset”, then the value of that property is passed to the method with the same name as the property. The following code, for example, creates a new element, sets three HTML attributes of it, registers an event handler for it, and sets a CSS style attribute on it:
var image = $("", {
src: image_url,
alt: image_description,
className: "translucent_image",
click: function() {$(this).css("opacity", "50%");},
css: { border: "dotted red 3px" }
});
3. jQuery defines simple methods like click() and change() for registering event handlers and also defines a more general event handler registration method named bind(). An important feature of bind() is that it allows you to specify a namespace (or namespaces) for your event handlers when you register them. This allows you to define groups of handlers, which comes in handy if you later want to trigger or de-register all the handlers in a particular group. Handler namespaces are especially useful for programmers who are writing libraries or modules of reusable jQuery code. Event namespaces look like CSS class selectors. To bind an event handler in a namespace, add a period and the namespace name to the event type string:
// Bind f as a mouseover handler in namespace "myMod"
$('a').bind('mouseover.myMod', f);
If your module registered all event handlers using a namespace, you can easily use unbind() to de-register them all:
// Unbind all mouseover and mouseout handlers
// in the "myMod" namespace
$('a').unbind("mouseover.myMod mouseout.myMod");
// Unbind handlers for any event in the myMod namespace
$('a').unbind(".myMod");
4. jQuery defines simple animation functions like fadeIn(), and also defines a general-purpose animation method named animate(). The queue property of the options object you pass to animate() specifies whether the animation should be placed on a queue and deferred until pending and previously queued animations have completed. By default, animations are queued, but you can disable this by setting the queue property to false. Unqueued animations start immediately. Subsequent queued animations are not deferred for unqueued animations. Consider the following code:
$("img").fadeIn(500)
.animate({"width":"+=100"},
{queue:false, duration:1000})
.fadeOut(500);
The fadeIn() and fadeOut() effects are queued, but the call to animate() (which animates the width property for 1000ms) is not queued. The width animation begins at the same time the fadeIn() effect begins. The fadeOut() effect begins as soon as the fadeIn() effect ends—it does not wait for the width animation to complete.
5. jQuery fires events of type “ajaxStart” and “ajaxStop” to indicate the start and stop of Ajax-related network activity. When jQuery is not performing any Ajax requests and a new request is initiated, it fires an “ajaxStart” event. If other requests begin before this first one ends, those new requests do not cause a new “ajaxStart” event. The “ajaxStop” event is triggered when the last pending Ajax request is completed and jQuery is no longer performing any network activity. This pair of events can be useful to show and hide a “Loading...” animation or network activity icon. For example:
$("#loading_animation").bind({
ajaxStart: function() { $(this).show(); },
ajaxStop: function() { $(this).hide(); }
});
These “ajaxStart” and “ajaxStop” event handlers can be bound to any document element: jQuery triggers them globally rather than on any one particular element.
1. You don't have to use $(document).ready() anymore, though you'll still see plenty of code out there that does. If you want to run a function when the document is ready to be manipulated, just pass that function directly to $().
2. You probably already know that you can pass a tagname to $() to create an element of that type, and that you can pass (as a second argument) an object of attributes to be set on the newly created element. This second argument can be any object that you would pass to the attr() method, but in addition, if any of the properties have the same name as the event registration methods, the property value is taken as a handler function and is registered as a handler for the named event type. Similarly, if any of the properties has the name “css”, “val”, “html”, “text”, “data”, “width”, “height”, or “offset”, then the value of that property is passed to the method with the same name as the property. The following code, for example, creates a new element, sets three HTML attributes of it, registers an event handler for it, and sets a CSS style attribute on it:
var image = $("", {
src: image_url,
alt: image_description,
className: "translucent_image",
click: function() {$(this).css("opacity", "50%");},
css: { border: "dotted red 3px" }
});
3. jQuery defines simple methods like click() and change() for registering event handlers and also defines a more general event handler registration method named bind(). An important feature of bind() is that it allows you to specify a namespace (or namespaces) for your event handlers when you register them. This allows you to define groups of handlers, which comes in handy if you later want to trigger or de-register all the handlers in a particular group. Handler namespaces are especially useful for programmers who are writing libraries or modules of reusable jQuery code. Event namespaces look like CSS class selectors. To bind an event handler in a namespace, add a period and the namespace name to the event type string:
// Bind f as a mouseover handler in namespace "myMod"
$('a').bind('mouseover.myMod', f);
If your module registered all event handlers using a namespace, you can easily use unbind() to de-register them all:
// Unbind all mouseover and mouseout handlers
// in the "myMod" namespace
$('a').unbind("mouseover.myMod mouseout.myMod");
// Unbind handlers for any event in the myMod namespace
$('a').unbind(".myMod");
4. jQuery defines simple animation functions like fadeIn(), and also defines a general-purpose animation method named animate(). The queue property of the options object you pass to animate() specifies whether the animation should be placed on a queue and deferred until pending and previously queued animations have completed. By default, animations are queued, but you can disable this by setting the queue property to false. Unqueued animations start immediately. Subsequent queued animations are not deferred for unqueued animations. Consider the following code:
$("img").fadeIn(500)
.animate({"width":"+=100"},
{queue:false, duration:1000})
.fadeOut(500);
The fadeIn() and fadeOut() effects are queued, but the call to animate() (which animates the width property for 1000ms) is not queued. The width animation begins at the same time the fadeIn() effect begins. The fadeOut() effect begins as soon as the fadeIn() effect ends—it does not wait for the width animation to complete.
5. jQuery fires events of type “ajaxStart” and “ajaxStop” to indicate the start and stop of Ajax-related network activity. When jQuery is not performing any Ajax requests and a new request is initiated, it fires an “ajaxStart” event. If other requests begin before this first one ends, those new requests do not cause a new “ajaxStart” event. The “ajaxStop” event is triggered when the last pending Ajax request is completed and jQuery is no longer performing any network activity. This pair of events can be useful to show and hide a “Loading...” animation or network activity icon. For example:
$("#loading_animation").bind({
ajaxStart: function() { $(this).show(); },
ajaxStop: function() { $(this).hide(); }
});
These “ajaxStart” and “ajaxStop” event handlers can be bound to any document element: jQuery triggers them globally rather than on any one particular element.
Friday, January 7, 2011
14 Tips to optimize your Drupal Site.
Following are some best practices i used to optimize my drupal sites, Developers can have a look and get benefits out of it.
1.Correctly configure Block Visibility settings
Drupal's block system allows you to place content in specific theme regions. But beware: even if you do not output a block in your theme, it will still be generated by the Drupal stack! That's because any enabled block's generation is determined by the block's visibility settings, not by the theme's region output. For example, if you have a page.tpl.php file and a custom page-front.tpl.php file with a custom $myregion for the frontpage where you output a complex block, then this block is also generated on every other page.tpl.php page! Even if you don't output the $myregion in page.tpl.php, the block is still generated based on its visibility settings. To solve this problem, dive into your blocks' settings and correctly configure the block visibility settings. If you only want to show a block on the homepage, then enter under 'Only show on the following pages'. A helpful module is the Block Node Visibiltiy module, which offers a UI to quickly select content types where you want to show the block.
Advantages
* Avoid unnecessary block generations on pages you do not output the block's region
2.Disable the statistics module
Drupal's statistics module has a disadvantage: extra MySQL queries per page load. Even when using the Boost module, boost_stats.php can still call these MySQL queries. Of course, it is up to you whether you need these Drupal stats. Most people will use Google Analytics as an alternative.
Other alternatives are server tools like Munin or Cacti.
Advantage
* Reduce MySQL requests per page
Disadvantage
* Live without drupal stats; install Google Analytics
References:
Download Google Analytics (module)
3.Enable core caching features
Often overlooked by Drupal beginners, but still worth mentioning: do not forget to enable core caching at Administer > Site Configuration > Performance (/admin/settings/performance). To avoid issues with Drupal modules, simply select Cache Mode: Normal. And enable Page Compression.
Here you can also enable bandwidth optimizations and block cache. We will come back to that later.
References:
Drupal caching, speed and performance
Caching modules that make Drupal scale
4.Enable native module caches (e.g. Views, Panels, Feeds)
Several Drupal modules bring their own caching system and caching tables. For example: Views, Panels and SWF Tools. Each have their own configuration options. On production servers, it is wise to enable them.
Views Cache
The Views module cache is hidden as an option on the Edit View page: Caching... And lets you choose cache by time for query results and rendered output. I usually select the same time length for both. The Views module is content-unaware, but there is a module for that: Views Content Cache.
5.Install ImageCache to generate thumbnails
ImageCache is a module that can generate image thumbnails on the fly, to exactly fit your dimensions. The thumbnails is only generate once, so should not influence performance. The benefit however is to the end user: visitors will download smaller images instead of the full unscaled version.
In the earlier days of the internet often people would upload huge images scaled by setting HTML width and height. Images looked small, but took ages to download. ImageCache fixed this problem. Use ImageCache in combination with various tools, including inside node.tpl.php and page.tpl.php.
Advantages
* Smaller images, reduced bandwidth
* Allows extra compression options
References:
Download ImageCache (module)
ImageCache and Lighttpd
6.Increase minimum cache lifetime on high traffic sites
Drupal's core caching system allows to set minimum cache lifetimes. This means content will not be refreshed until after a certain time. For example, on busy sites, you would set the Minimum Cache Life to 1 hour. That means visitors do not see changes on your site more often than 1 hour. But it greatly helps to improve cache-efficiency and reduces your server load.
Advantages
* Improved cache-efficiency
* Reduced server load
Disadvantages
* Vistors see less frequent content changes
7.Install the CSS Gzip module
Install the CSS Gzip module
Drupal handles separate CSS files per module. This way module maintainers can provide their custom CSS. But the disadvantage is you get a lot of CSS files. Each file requires a separate HTTP request. The CSS Gzip module extends Drupal's core CSS handling.
Drupal can automatically optimize external resources like CSS and JavaScript, which can reduce both the size and number of requests made to your website. CSS files can be aggregated and compressed into a single file, while JavaScript files are aggregated (but not compressed). These optional optimizations may reduce server load, bandwidth requirements, and page loading times.
Advantages
* Faster than mod_deflate
* Faster user-end load times
Disadvantages
* Requires clean URLs to be enabled
* Requires public download method
References:
Download CSS Gzip
8.Install the DB Maintenance module
The DB maintenance module periodically optimizes your MySQL database tables. It runs the SQL statements OPTIMIZE to make sure the integrity of your tables is kept sane.
Advantages
* Avoid table corruption, optimize database table structures
* Faster table access
9.Install the Javascript Aggregator module
Drupal 6.x has a built-in JavaScript compression tool at Administer > Site Configuration > Performance, near Bandwith Optimizations. However, end-user performance can be taken one step further by minifying that file. The Drupal JavaScript Aggregator module provides that option. Files are minified once, and refreshed when needed.
Advantages
* Minifies the JavaScript files before compression
* Reduces end-user load times and server bandwidth
References:
Download Javascript Aggregator
JSMin, the JavaScript minifier
10.Install the Update Status Advanced Settings module
I recommend turning the Update Status module on for production servers. It informs you when to update critical security patches. But the core module does not let you control how often should be checked for updates.
Enter the Update status advanced settings module. This lets you check once per day, or once per week, and also lets you disable checking for specific modules.
Advantages
* Check for module updates less frequently, i.e. only once per day or week
References:
Download Update Status Advanced Settings (module)
11.Uninstall unnecessary Drupal modules
Does it really matter how many modules you run? According to 2Bits more modules means more RAM and CPU usage. Each time the Drupal stack is fired it needs to read all module files. Adding more modules means:
* Higher CPU usage;
* Higher RAM usage;
* More opportunity for bugs to slup in;
* More (MySQL) database hits;
* Higher chance of a module with slow database queries;
* More maintenance!
All of them are good reasons to avoid an open buffet of Drupal modules. Only use what you need.
Advantages
* Free up server, PHP, MySQL and Drupal resources
References:
2Bits: Drupal modules: Less is more
12.Avoid calls to node_load() where possible, use fields
Drupal's node_load() function fires a great deal of queries and functions. The more module you use, the more node hooks will be involved in this call. Wherever possible it is advised to avoid calls to node_load(). Instead, try to fetch the specific fields you need directly. Best example: Views. Using the Views module you can build a page that lists all nodes. Each item requires a node_load() call. To avoid this, switch to using Fields in Views instead and call the fields that you really need. Then use custom Views theming to output the data.
Advantages
* Reduce the load on the Drupal stack
Disadvantages
* Requires more work, more fore-thought of what you need
References:
Drupal API: node_load()
13.Avoid calls to taxonomy_get_tree()
Drupal's taxonomy system, to categorize and tag content, has one bad function taxonomy_get_tree(). It works fine on small sites with few tags. But on large sites with over tens of thousands of taxonomy terms, you should avoid it at all cost. The function namely stores all terms into the PHP RAM memory, quickly blocking further PHP execution.
Drupal core uses the function on several pages, such as the admin/content/node page and others. A solution is to use the Views Bulk Operations module (VBO) to replace that page with a custom view.
Advantages
* Free PHP memory consumption by avoiding heavy taxonomy_get_tree() calls
References:
Download Views Bulk Operations (module)
Drupal API: taxonomy_get_tree()
14.Avoid using the PHP input filter
Drupal provides a PHP input filter out of the box. It lets you use custom PHP inside nodes and blocks. The downside is that this PHP code is stored in the database. Upon a new page request this code must be retrieved from the database and executed through PHP's eval() function.
But the biggest drawback is this: the PHP input filter is not cached. The solution is to write a custom Drupal module to do the task.
Advantages
* Custom modules are cached, PHP input filter is not
Disadvantages
* You must learn to write your custom Drupal modules (but it's really fun!)
1.Correctly configure Block Visibility settings
Drupal's block system allows you to place content in specific theme regions. But beware: even if you do not output a block in your theme, it will still be generated by the Drupal stack! That's because any enabled block's generation is determined by the block's visibility settings, not by the theme's region output. For example, if you have a page.tpl.php file and a custom page-front.tpl.php file with a custom $myregion for the frontpage where you output a complex block, then this block is also generated on every other page.tpl.php page! Even if you don't output the $myregion in page.tpl.php, the block is still generated based on its visibility settings. To solve this problem, dive into your blocks' settings and correctly configure the block visibility settings. If you only want to show a block on the homepage, then enter
Advantages
* Avoid unnecessary block generations on pages you do not output the block's region
2.Disable the statistics module
Drupal's statistics module has a disadvantage: extra MySQL queries per page load. Even when using the Boost module, boost_stats.php can still call these MySQL queries. Of course, it is up to you whether you need these Drupal stats. Most people will use Google Analytics as an alternative.
Other alternatives are server tools like Munin or Cacti.
Advantage
* Reduce MySQL requests per page
Disadvantage
* Live without drupal stats; install Google Analytics
References:
Download Google Analytics (module)
3.Enable core caching features
Often overlooked by Drupal beginners, but still worth mentioning: do not forget to enable core caching at Administer > Site Configuration > Performance (/admin/settings/performance). To avoid issues with Drupal modules, simply select Cache Mode: Normal. And enable Page Compression.
Here you can also enable bandwidth optimizations and block cache. We will come back to that later.
References:
Drupal caching, speed and performance
Caching modules that make Drupal scale
4.Enable native module caches (e.g. Views, Panels, Feeds)
Several Drupal modules bring their own caching system and caching tables. For example: Views, Panels and SWF Tools. Each have their own configuration options. On production servers, it is wise to enable them.
Views Cache
The Views module cache is hidden as an option on the Edit View page: Caching... And lets you choose cache by time for query results and rendered output. I usually select the same time length for both. The Views module is content-unaware, but there is a module for that: Views Content Cache.
5.Install ImageCache to generate thumbnails
ImageCache is a module that can generate image thumbnails on the fly, to exactly fit your dimensions. The thumbnails is only generate once, so should not influence performance. The benefit however is to the end user: visitors will download smaller images instead of the full unscaled version.
In the earlier days of the internet often people would upload huge images scaled by setting HTML width and height. Images looked small, but took ages to download. ImageCache fixed this problem. Use ImageCache in combination with various tools, including inside node.tpl.php and page.tpl.php.
Advantages
* Smaller images, reduced bandwidth
* Allows extra compression options
References:
Download ImageCache (module)
ImageCache and Lighttpd
6.Increase minimum cache lifetime on high traffic sites
Drupal's core caching system allows to set minimum cache lifetimes. This means content will not be refreshed until after a certain time. For example, on busy sites, you would set the Minimum Cache Life to 1 hour. That means visitors do not see changes on your site more often than 1 hour. But it greatly helps to improve cache-efficiency and reduces your server load.
Advantages
* Improved cache-efficiency
* Reduced server load
Disadvantages
* Vistors see less frequent content changes
7.Install the CSS Gzip module
Install the CSS Gzip module
Drupal handles separate CSS files per module. This way module maintainers can provide their custom CSS. But the disadvantage is you get a lot of CSS files. Each file requires a separate HTTP request. The CSS Gzip module extends Drupal's core CSS handling.
Drupal can automatically optimize external resources like CSS and JavaScript, which can reduce both the size and number of requests made to your website. CSS files can be aggregated and compressed into a single file, while JavaScript files are aggregated (but not compressed). These optional optimizations may reduce server load, bandwidth requirements, and page loading times.
Advantages
* Faster than mod_deflate
* Faster user-end load times
Disadvantages
* Requires clean URLs to be enabled
* Requires public download method
References:
Download CSS Gzip
8.Install the DB Maintenance module
The DB maintenance module periodically optimizes your MySQL database tables. It runs the SQL statements OPTIMIZE to make sure the integrity of your tables is kept sane.
Advantages
* Avoid table corruption, optimize database table structures
* Faster table access
9.Install the Javascript Aggregator module
Drupal 6.x has a built-in JavaScript compression tool at Administer > Site Configuration > Performance, near Bandwith Optimizations. However, end-user performance can be taken one step further by minifying that file. The Drupal JavaScript Aggregator module provides that option. Files are minified once, and refreshed when needed.
Advantages
* Minifies the JavaScript files before compression
* Reduces end-user load times and server bandwidth
References:
Download Javascript Aggregator
JSMin, the JavaScript minifier
10.Install the Update Status Advanced Settings module
I recommend turning the Update Status module on for production servers. It informs you when to update critical security patches. But the core module does not let you control how often should be checked for updates.
Enter the Update status advanced settings module. This lets you check once per day, or once per week, and also lets you disable checking for specific modules.
Advantages
* Check for module updates less frequently, i.e. only once per day or week
References:
Download Update Status Advanced Settings (module)
11.Uninstall unnecessary Drupal modules
Does it really matter how many modules you run? According to 2Bits more modules means more RAM and CPU usage. Each time the Drupal stack is fired it needs to read all module files. Adding more modules means:
* Higher CPU usage;
* Higher RAM usage;
* More opportunity for bugs to slup in;
* More (MySQL) database hits;
* Higher chance of a module with slow database queries;
* More maintenance!
All of them are good reasons to avoid an open buffet of Drupal modules. Only use what you need.
Advantages
* Free up server, PHP, MySQL and Drupal resources
References:
2Bits: Drupal modules: Less is more
12.Avoid calls to node_load() where possible, use fields
Drupal's node_load() function fires a great deal of queries and functions. The more module you use, the more node hooks will be involved in this call. Wherever possible it is advised to avoid calls to node_load(). Instead, try to fetch the specific fields you need directly. Best example: Views. Using the Views module you can build a page that lists all nodes. Each item requires a node_load() call. To avoid this, switch to using Fields in Views instead and call the fields that you really need. Then use custom Views theming to output the data.
Advantages
* Reduce the load on the Drupal stack
Disadvantages
* Requires more work, more fore-thought of what you need
References:
Drupal API: node_load()
13.Avoid calls to taxonomy_get_tree()
Drupal's taxonomy system, to categorize and tag content, has one bad function taxonomy_get_tree(). It works fine on small sites with few tags. But on large sites with over tens of thousands of taxonomy terms, you should avoid it at all cost. The function namely stores all terms into the PHP RAM memory, quickly blocking further PHP execution.
Drupal core uses the function on several pages, such as the admin/content/node page and others. A solution is to use the Views Bulk Operations module (VBO) to replace that page with a custom view.
Advantages
* Free PHP memory consumption by avoiding heavy taxonomy_get_tree() calls
References:
Download Views Bulk Operations (module)
Drupal API: taxonomy_get_tree()
14.Avoid using the PHP input filter
Drupal provides a PHP input filter out of the box. It lets you use custom PHP inside nodes and blocks. The downside is that this PHP code is stored in the database. Upon a new page request this code must be retrieved from the database and executed through PHP's eval() function.
But the biggest drawback is this: the PHP input filter is not cached. The solution is to write a custom Drupal module to do the task.
Advantages
* Custom modules are cached, PHP input filter is not
Disadvantages
* You must learn to write your custom Drupal modules (but it's really fun!)
Subscribe to:
Posts (Atom)