Here are some discussions and mentions around the web:

• an article on Weblog Tools Collection
• a forum post on WP Tavern
• twitter retweets

Sure, there are drawbacks to this method and it does require some more processing on the backend and it's not for everyone, which is why we should always strive for an even better solution.

I stand by my point of view that, for instance, my dedicated gallery shouldn't load for people who will never even go see my photos.

I think an ideal solution would be for WP core developers, who had a lot of experience designing WordPress' internals and who know what can work and what can't, perhaps Matt included, to get together and think about a better solution really hard.

Conditional loading similar to the one discussed here is already possible in the admin area, which creates dynamic hooks by appending page ids to 'admin_print_styles' and 'admin_print_scripts'. It is, however, still not good enough to be used more generically because those hooks rely on the page you are on, rather than the content of that page.

Another possibility is using a PHP technique called output buffering (ob_start(), ob_flush(), etc) that grants second chances to data that had already been echoed. It intercepts all echo and print calls and redirects them into a memory buffer, so instead of printing data to the page right away, you can now modify the header even if it had already been processed. It's like giving it a second chance.

Would it work for WordPress? I am not sure but I sure could use your feedback, devs.

• [WordPress Plugin Development] How To Include CSS and JavaScript Conditionally And Only When Needed By The Posts
• Swapping Column Values in MySQL
• How To Dynamically Increase Memory Limits When Interfacing With WordPress Using XML-RPC (Windows Live Writer, Etc)
• How To Remove Inline Hardcoded Recent Comments Sidebar Widget Style From Your WordPress Theme
• How To Fix Incomplete WordPress (WXR) Exports

If you follow web design at all, you probably see 5 billion top NN posts on a daily basis mentioning site and blog designs, fonts, icons, etc.

However, nobody seems to be paying attention to these little but important guys: comment forms.

If you have an appealing comment box, you are more likely to receive comments (this is based on days of scientific research that I imagined I did in my head) and your content is more likely to be re-shared, voted up, and saved.

I really do feel that way when I visit blogs, especially when an otherwise aesthetically pleasing site has a plain vanilla comment box.

Let's Go

So here we go. I have looked through hundreds of sites to make this collection, go ahead and let me know if you like it (yeah, I know, my comment box is not as spiffy as theirs).

I've also included my notes with the parts that I liked.

1. blog.spoongraphics.co.uk 

• interesting submit button
• fun background
• great font
• grungy
• border glow
• normal:

• focused:

2. springydevelopment.co.uk

• 2 column
• wide submit button

3. css-tricks.com

• Chris Coyier doesn't mess around with crappy designs – his website is superb in general
• normal:

• focused:

• internal disappearing labels
• dimming labels
• interesting submit button
• custom images

4. net.tutsplus.com

• tongue:

• internal disappearing labels
• appealing default avatar

5. smashingmagazine.com

• simplistic
• appealing submit button
• absence of author website – less spam

6. branded07.com

• fading
• interesting background

7. depcore.com

• simplistic
• unconventional – looks like a pad of paper or a letter
• contains an anti-spam measure

8. marcofolio.net

• notify/don't notify option (for the first time the design is cohesive – not some random checkbox under the submit button)
• lots of formatting buttons
• smilies

9. jankoatwarpspeed.com

• handy and appealing formatting buttons
• flag next to the country – it then shows up next to each commenter, kind of cool:

10. dezinerfolio.com

• highlight the field with focus – concentrate attention on one spot
• large padding
• by the way, they have an amazing header. I couldn't resist:

11. sohtanaka.com

• I love it
• custom submit button
• hovering quote
• very polished look

12. productivedreams.com

• the comment box actually sits *above* the comments – a radical, yet interesting approach
• custom icons
• really nice custom highlight on hover effect:

• usability and UX at their best

13. kevadamson.com

• grungy, sloppy – looks great!

14. line25.com

• clean
• side by side
• symmetrical, exact
• I love it

15. markforrester.co.za

• colorful, crayon-like (though it looks better on the site itself – you need to see it in its natural habitat)
• internal disappearing labels

16. jrvelasco.com

• simple, and yet sophisticated

17. gizmodo.com

• very simple from the UX perspective:
  • single line box, without the need to login first
  • expands on focus
  • no need to login even then, unless you want to – just enter your email

18. instantshift.com

• this is one of my favorites
• I love, love, love the way the comments look, especially the way the author ones stand out:

19. koodoz.com.au

• internal disappearing labels
• the design itself, while seemingly not too special, mashes with comment list very well. Check it out – I think the curvy lines are very creative:

20. elliotjaystocks.com

• click the image – it's bigger than it looks
• if you can't tell (), the elements are MASSIVE, which makes this comment box pretty unique

Conclusion

If you liked this post, you might also enjoy

• BlogDesignBlog with 37 more comment form designs (though they're not as exciting).
• 1stwebdesigner with 77 comment form designs.
• Queness with 20 stylish web form designs.

So, what did you think? The comment box you're looking for is at the bottom of the page.

• Thoughts on Google Chrome
• Enable A Twitter Retweet (RT) Button That Lets You Add Comments Before Retweeting
• How *Not* To Implement A Web Application That Handles External Authentication, Using BeTwittered.com As An Example
• How To Fight Clickjacking (Using The Recent Twitter Hijacking As An Example)
• [Updated x3] Goodbye Outlook, I Don't Need You Anymore – Gmail Now Lets You Paste Images Directly From Clipboard

In this tutorial, I am going to introduce a WordPress technique that I believe was unpublished until I raised the question a few days ago on the WordPress forums.

In short, the problem I was trying to solve was plugins unnecessarily loading their JavaScript and CSS on *every* page of the blog, even when doing so would achieve absolutely nothing and the plugin wouldn't do any work.

Let me explain using this example:

• a code formatter plugin only does something useful when it sees a [code] shortcode in any post on the page.
• most of your posts do not contain the [code] shortcode as you don't include code snippets that often or you only started using this particular plugin recently.
• the plugin, however, loads the CSS and JS (which are most likely GeSHi and take up loads of space) on every page.
• these CSS and JS do absolutely nothing on most page loads.
• bandwidth is wasted, extra DNS and HTTP requests are processed, the browser is slowed down, and for what? For no good reason, other than the plugin author didn't know how to achieve this conditional loading.

If you think about it, there are many plugins that only do something once in a blue moon. Table of contents, text manipulators, galleries, sliders, etc, etc. If only they loaded their frontend code strictly when necessary, most page loads would suddenly become much lighter.

So what can we do to solve this? Let's look at a few techniques.

Loading CSS And JS In Place?

Here's one, albeit pretty bad, solution - only print the CSS and JS includes if and when you determine somewhere in the middle of loading the posts that the scripts and styles are indeed needed, then set a flag to avoid printing them again. In our example, that would be when the plugin detects the [code] shortcode.

This, however, is a mediocre solution because, while it's not a bad idea to load Javascript in the footer, CSS should be loaded in the header, otherwise the page might look unformatted until the CSS is reached.

Additionally, it's not the cleanest and most robust solution because you shouldn't be writing <script> and <style> tags manually but rather using wp_enqueue_style() and wp_enqueue_script() functions.

What's This About wp_enqueue_FOO?

Now, you might say: "What's this about wp_enqueue_style(), wp_enqueue_script(), and then hooking into 'wp_print_scripts', 'wp_print_styles', 'admin_print_scripts', and 'admin_print_styles' hooks"? You know about these, right? Right??

Allow me to explain this, in my opinion, greatest and most underused WordPress paradigm in a short refresher:

Enqueuing Alone Is Not Enough

Enqueuing is great for loading your JS and CSS but using it alone doesn't achieve the conditional behavior that we are looking for here.

This is a classic case of Chicken or the Egg, because WordPress makes only one pass through all of the content.

You see, since the header needs to be printed before the content, wp_print_scripts and wp_print_styles hooks are triggered before you even get to the posts. If you enqueue a script or style from within the 'the_content' hook, for example, the queued up scripts and styles will never get printed. It's too late to print them then anyway, as you're already in the middle of printing the posts.

The Solution

What we need to do is take a step back, before even printing the header, and then peek ahead.

Sure, this adds an extra pass over some data, but since no filters are applied during this process and if you avoid regular expressions (using stripos(), for example), this extra pass should be quite negligible.

The upside, however, can be potentially very substantial.

Credit goes to @white_shadow for the idea.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

add_filter('the_posts', 'conditionally_add_scripts_and_styles'); // the_posts gets triggered before wp_head
function conditionally_add_scripts_and_styles($posts){
	if (empty($posts)) return $posts;
 
	$shortcode_found = false; // use this flag to see if styles and scripts need to be enqueued
	foreach ($posts as $post) {
		if (stripos($post->post_content, '[code]') !== false) {
			$shortcode_found = true; // bingo!
			break;
		}
	}
 
	if ($shortcode_found) {
		// enqueue here
		wp_enqueue_style('my-style', '/style.css');
		wp_enqueue_script('my-script', '/script.js');
	}
 
	return $posts;
}

This simple function fires before the header gets printed, as it's attached to the 'the_posts' hook. However, this time it has full access to the posts' content.

I have tested this method and it works really well - if you have heavy scripts in your plugin, please do us, users, a favor and incorporate this logic into it.

Conclusion

In this tutorial, you have seen a method of loading scripts and styles for you plugin conditionally. This technique allows for less bloated pages and faster page loads.

Plugin developers, what is your take on this solution? Do you use another method? Please share in the comments.

• Follow-up To Loading CSS And JS Conditionally
• How To Remove Inline Hardcoded Recent Comments Sidebar Widget Style From Your WordPress Theme
• How To Dynamically Increase Memory Limits When Interfacing With WordPress Using XML-RPC (Windows Live Writer, Etc)
• How To Diagnose And Fix Incorrect Post Comment Counts In WordPress
• How To View A Specific SVN Revision In Your Browser

Here's where Firebug comes in with its JavaScript debugger. I'm used to using a debugger in every language I deal with, so using Firebug is a no brainer. Since it supports breakpoints, stopping execution and inspecting local variables and the rest of the scope generally beats alerts and console.logs for me.

Here's what a typical breakpoint looks like in Firebug:

It's easy to set breakpoints in static scripts – just open the Scripts tab, select a JavaScript file from the dropdown menu, and click to the left of the wanted line number.

Then, when the page is reloaded, if your breakpoints are triggered, Firebug will pause script execution and transfer the control to you.

In most cases, the method above is the only method of setting breakpoints you will ever need to use.

The Problem With Dynamic JavaScript

However, what if the JavaScript file where you need to set breakpoints is not static but instead dynamic (generated on the fly). If you set a breakpoint in this case and reload the page, the breakpoint will most likely disappear, especially if the JavaScript url is generated uniquely every time.

The Solution

If you have access to the source, the solution comes in the form of the

debugger;

keyword. Just add it to your dynamic JavaScript generator or into any JavaScript file you have access to exactly where you want Firebug to break, and voila – it does.

More so, this method also works in Google Chrome and IE (if you have Microsoft Script Debugger). Here is a screenshot of my Chrome Beta 4.0.266.0 triggering:

I consider this feature relatively unpublished and therefore awesome because:

• it's hard to search for this specific meaning of the keyword "debugger" when Firebug itself is a debugger and it's a very popular word
• nobody really reads documentation for Firebug, and even if they do, I haven't actually seen the debugger keyword mentioned
• I didn't know about it until recently, even though I've been using Firebug for years

Of course, you need access to the code for this to work, so it's not going to work if you're trying to debug someone else's JavaScript.

And finally, don't forget to remove any traces of 'debugger' from your code when you go live or your users will rightfully hunt you down.

Credits And References:

• suggested by a co-worker from Plaxo – Russ. Thanks Russ!
• some more interesting info at StackOverflow and Infragistics.

Happy debugging!

(*) – if your project works 100% on the first pass, you must be either a magician or Jon Skeet (Jon Skeet Facts – a-la Chuck Norris, a must read).

• [WordPress Plugin Development] How To Include CSS and JavaScript Conditionally And Only When Needed By The Posts
• [Updated for 2012] Here's An Exclusive 10% Off NuSphere PHPEd Discount Coupon Code (Also Includes NuCoder And PHPDoc)
• How To Make Your Site Lightning Fast* By Compressing (deflate/gzip) Your HTML, Javascript, CSS, XML, etc In Apache
• How To Dynamically Increase Memory Limits When Interfacing With WordPress Using XML-RPC (Windows Live Writer, Etc)
• How To Fix Incomplete WordPress (WXR) Exports

StackOverflow is an amazing site for coding questions. It was created by Joel Spolsky of joelonsoftware.com, Jeff Atwood of codinghorror.com, and some other incredibly smart guys who truly care about user experience. I have been a total fan of SO since it went mainstream and it's now a borderline addiction (you can see my StackOverflow badge on the right sidebar).

The Story

So, one day someone at StackOverflow started a "Hidden features of" post about a famous language (I don't feel like finding out which one was first exactly), and it turned out to be so popular that other posts in the same series started popping up.

Such questions were quickly turned into community wikis, for the purposes of harvesting and organizing information coming from the best developers on the planet and voted by users of the site. There are literally hundreds of answers, sorted by votes.

Hidden Features Of

Programming Languages

Hidden features of ActionScript3 / Flex

Hidden features of ASP.NET

Hidden features of x86 assembly

Hidden features of C

Hidden features of C++

Hidden features of C#

Hidden features of ColdFusion

Hidden features of D

Hidden features of Delphi

Hidden features of Erlang

Hidden features of F#

Hidden features of Flash development, Flash language (AS2/3), and Flash IDE

Hidden features of Java

Hidden features of JavaScript

Hidden features of Haskell

Hidden features of Lisp

Hidden features of Lua

Hidden features of Objective-C

Hidden features of Perl

Hidden features of PHP

Hidden features of Python

Hidden features of R

Hidden features of Ruby

Hidden features of Ruby on Rails

Hidden features of Scala

Hidden features of Silverlight

Hidden features and Dark Corners of STL?

Hidden features of TCL/TK

Hidden features of VB.Net

Hidden features of VBA

Databases

Hidden features of MySQL

Hidden features of Oracle

Hidden features of PL/SQL

Hidden features of PostgreSQL

Hidden features of SQL Server

Mobile

Hidden features of Android development

Other

Hidden features of Bash – also see my bash cheatsheet.

Hidden features of CSS

Hidden features of Django

Hidden features of Eclipse

Hidden features of Emacs

Hidden features of Grails

Hidden features of Greasemonkey

Hidden features of HTML

Hidden features of HTTP

Hidden features of jQuery

Hidden features of mod_rewrite

Hidden features of Qt

Hidden features of RegEx

Hidden features of Spring framework

Hidden features of VHDL

Hidden features of Visual Studio (2005-2008)

Hidden features of Windows.Forms

Hidden features of WPF and XAML

Hidden features of Xpath+Xslt

I will try to maintain this list, adding new languages that join the series as I find them. Now go learn something new!

• StackOverflow.com, SuperUser.com, ServerFault.com Fan? Here's A Greasemonkey Script To Keep Track Of All Your Accounts
• Comparison Between Solr And Sphinx Search Servers (Solr Vs Sphinx – Fight!)
• Twitter.com Autocomplete, Auto URL Expansion, Auto URL Shortener, RT Button, Nested Replies, Inline Media Embed, Search Tabs, And More
• WordPress Developers – How Do You Make A Living [Poll + Discussion]?
• Delicious.com [Quietly] Rolls Out Domain And Url Searching/Filtering. Finally!

Introduction

Whether you are a web developer or a self-hosting business owner, the only excuse for not activating compression capabilities of your web server can be that you didn't know about it. And now that you are reading this, there is no excuse left at all.

Here is how big a single page of this blog was before compression was enabled on CSS and Javascript files (computed by YSlow):

And here it is after compression:

As you see, the difference is quite substantial – almost 30% savings.

Compressing your HTML, XML, Javascript, CSS, etc pages will mean less data transferred between the server and the client which:

• reduces the bandwidth usage.
• provides faster page rendering which in turn leads to less user frustration, higher conversion rates, lower bounce rate, etc etc etc.

Compression is especially important for users with slow connections as every kilobyte of your code is that much more painful to them.

Compression can be very effective – you can easily shrink your text, code (HTML, XML, Javascript, CSS, etc) to 10% of the original size (of course, your mileage may vary). 100KB page that needs only 10KB to transfer? Sign me up!

So, before I talk about the solution, let me describe what exactly happens when compression is turned on and how it affects older browsers that don't support it.

Compression Mechanism Explained

In order for compression to work in the first place, the web server (Apache in my example) needs to support it. This is achieved by enabling one of Apache modules called mod_deflate. The server will then be able to compress the data to the DEFLATE standard using either the zlib (also known as deflate) or gzip implementations. Yeah, DEFLATE is both the standard the one of its implementations, for those confused. I know I was. This is best described in this Wikipedia article.

The following mechanism is used:

• the server with a compression extension enabled is able to serve either compressed (smaller) or uncompressed (larger) pages, depending on what the client supports.
• the client (that is, your browser) sends a special header called "Accept-Encoding" listing the DEFLATE implementations it's capable of decompressing. For example "gzip,deflate".
• the server picks the best compression supported by the client (if any), compresses the files, and sends them over to the client.
• the client receives the compressed files and decompresses them.

Are Your Pages Already Compressed? Test Them!

If you are not sure whether you are already serving compressed pages or not, test them! My favorite way is by using Charles HTTP Debugger. Another option is by downloading Firebug for Firefox and installing Yahoo's YSlow or Google's Page Speed. Just look at the response headers to see if compression is on (look for the Content-Encoding header). Here are some before and after examples:

Theme CSS

Before:

After:

jQuery

Before:

After:

Solution

Create a .htaccess file in the top directory of your site with the following contents:

1
2
3
4
5
6
7
8

# DEFLATE by type - html, text, css, xml
AddOutputFilterByType DEFLATE text/html text/plain text/css text/xml
 
# DEFLATE by type - javascript
AddOutputFilterByType DEFLATE application/x-javascript application/javascript text/javascript text/x-js text/x-javascript
 
# DEFLATE by extension
AddOutputFilter DEFLATE js css htm html xml

Alternatively, you could put these lines into your Apache config within the Directory directive.

The AddOutputFilterByType directive adds DEFLATE filters to certain MIME types. I tried to assemble some of the common ones but feel free to add more, as each server may be configured differently and give out MIME types different from mine.

The AddOutputFilter directive binds the DEFLATE filter to specific file extensions, just in case they are not served with a proper MIME type. Feel free to add to this list as well.

Caveats

1. In order to use this whole compression/deflate/gzip business, your Apache server must first have mod_deflate enabled. Without it, you will get the HTTP 500 error (Internal Server error). You can check which mods you already have enabled by checking with the output of phpinfo() function.

In order to enable mod_deflate, uncomment the line with "deflate_module" in your Apache config file. The location of this config file is highly dependant on your system. Some examples include

• /etc/apache2/httpd.conf
• /etc/httpd/conf/httpd.conf
• c:\wamp\bin\apache\Apache2.2.11\conf\httpd.conf
• some other place where your system stores Apache config files (read the special note below for OpenSUSE).

Here's what you should have:

LoadModule deflate_module modules/mod_deflate.so

On OpenSUSE, you actually enable modules a bit differently. Go to /etc/sysconfig/apache2 and look for APACHE_MODULES=. Then add "deflate" to the list, if it's not already there.

Now, restart Apache and check the output of phpinfo() again.

2. Adding AddOutputFilter and AddOutputFilterByType to .htaccess requires such overrides to be authorized by the main Apache configuration for that directory, otherwise it will return error 500 as well. The option you are looking for is called "AllowOverride" and mine was set to "AllowOverride AuthConfig" which wasn't enough. Changing it to

AllowOverride AuthConfig FileInfo

or just

AllowOverride All

fixes the problem. You can find more info about AllowOverride here.

3. In WordPress, if you are using Google Gears (Turbo mode) for caching some core WordPress files, they will not show up compressed. That is because they're not served by the remote server but rather reside locally (think of it as permanent cache). I was very confused at first when I didn't see jQuery.js in the HTTP log and YSlow reported it uncompressed.

Are you a WordPress user?

If you are a WordPress user, don't assume WordPress is going to automatically compress your pages. In fact, as you install more and more plugins, the payload becomes larger and larger with those additional CSS and Javascript files.

You owe it to yourself and to your users to immediately enable compression on your blog.

Here is what happened after I enabled compression on this blog.

Before:

After:

Bonus – WP Minify

For even better results, I suggest you have a look at my good friend and talented WordPress master Thaya's plugin called WP Minify. It preprocesses and aggregates all or most of your CSS and Javascript into just 2 files, thus saving on the number of HTTP requests. It also minifies content to achieve smaller size.

My blog before WP Minify:

After WP Minify:

That's all folks. Let me know if something was unclear and I'll be glad to clarify it.

A few references that pointed me in the right direction and allowed me to provide a more complete solution:

• http://brightscape.net/compress-jquery-even-further/
• http://brightscape.net/compress-your-web-pages-with-mod_deflate/

• Beer Planet Upgraded To WordPress 2.5
• [WordPress Plugin Development] How To Include CSS and JavaScript Conditionally And Only When Needed By The Posts
• Hidden Features Of Perl, PHP, Javascript, C, C++, C#, Java, Ruby, Python, And Others [Collection Of Incredibly Useful Lists]
• Rendr – a Live Awesome CSS/HTML Rendering Tool
• cpan – The Perl Module Manager