beer planet » load http://beerpla.net where things have nothing to do with beer - tutorials, tips, how-tos, thoughts, hacks, and other techy nonsense Thu, 17 May 2012 22:50:53 +0000 en hourly 1 http://wordpress.org/?v=3.3.2 Follow-up To Loading CSS And JS Conditionallyhttp://beerpla.net/2010/01/15/follow-up-to-loading-css-and-js-conditionally/ http://beerpla.net/2010/01/15/follow-up-to-loading-css-and-js-conditionally/#comments Fri, 15 Jan 2010 20:07:40 +0000 Artem Russakovskii http://beerpla.net/2010/01/15/follow-up-to-loading-css-and-js-conditionally/ First of all, I'd like to thank everyone who read and gave their 2 cents about the [Wordpress Plugin Development] How To Include CSS and JavaScript Conditionally And Only When Needed By The Posts post. The article was well received and will hopefully spark some optimizations around loading styles and scripts.

Here are some discussions and mentions around the web:

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 ...

Read the rest of this article »

]]> First of all, I'd like to thank everyone who read and gave their 2 cents about the [Wordpress Plugin Development] How To Include CSS and JavaScript Conditionally And Only When Needed By The Posts post. The article was well received and will hopefully spark some optimizations around loading styles and scripts.

Here are some discussions and mentions around the web:

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.

Update: Scribu, a WordPress master, came up with the approach that would at least handle loading JS, as it would put it in the footer, which can be done after the posts have been parsed.

His approach doesn't handle CSS which is why I decided to seek another solution but it doesn't require an extra pass through the posts and it benefits from using the shortcode API instead of stripos() or some hacky regex you'd need to come up with.

It's a great compromise for developers who do not want to take the approach I outlined in the article linked at the top of this page.

Similar Posts:

Share

]]> http://beerpla.net/2010/01/15/follow-up-to-loading-css-and-js-conditionally/feed/ 5 [WordPress Plugin Development] How To Include CSS and JavaScript Conditionally And Only When Needed By The Postshttp://beerpla.net/2010/01/13/wordpress-plugin-development-how-to-include-css-and-javascript-conditionally-and-only-when-needed-by-the-posts/ http://beerpla.net/2010/01/13/wordpress-plugin-development-how-to-include-css-and-javascript-conditionally-and-only-when-needed-by-the-posts/#comments Wed, 13 Jan 2010 17:15:00 +0000 Artem Russakovskii http://beerpla.net/2010/01/13/wordpress-plugin-development-how-to-include-css-and-javascript-conditionally-and-only-when-needed-by-the-posts/ Introduction

wordpress logo 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.

Update #1: I have posted a follow-up in response to some comments received around the web.

Update #2: There is a solution that can be considered a compromise as it works well for loading JavaScript but doesn't handle CSS.

I briefly mentioned this approach here but but Scribu decided to expand ...

Read the rest of this article »

]]> Introduction

wordpress logo 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.

Update #1: I have posted a follow-up in response to some comments received around the web.

Update #2: There is a solution that can be considered a compromise as it works well for loading JavaScript but doesn't handle CSS.

I briefly mentioned this approach here but but Scribu decided to expand on it by providing a nice Jedi-themed tutorial. It is available here.

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:

WordPress has a great system of queuing up the scripts and styles your script will need to use and printing them all in one go, rather than hooking into wp_head and printing <style> and <script> tags manually.

This queuing system achieves 2 main goals:

  • the same scripts are not loaded multiple times, such as jQuery, scriptaculous, or any other custom script or style your plugins may share between each other or even other plugins.
  • it introduces support for establishing dependencies. You can specify that your script or style depends on another script or style, and WordPress will take care of loading them in the right order. Guaranteed.
  • oh what the hell, here's a 3rd one: elegance.

Here is the way this usually works:

  • in the beginning of your plugin you attach to wp_print_scripts and/or wp_print_styles hooks. For example:

    1
2

    add_action( 'wp_print_scripts', 'enqueue_my_scripts' );
add_action( 'wp_print_styles', 'enqueue_my_styles' );

    What this will do is call the functions in the 2nd parameter when it's time to execute any functions associated with the hooks in the 1st parameter. It is the main principle behind the WordPress plugin architecture.

  • looking at the script example, in the enqueue_my_scripts() function, you can do something like:
    1

    wp_enqueue_script( 'my_awesome_script', '/script.js', array( 'jquery' ));

    which would queue up your script to be printed later but only after jQuery.

    If you or some other plugin calls wp_enqueue_script() with the same first parameter (unique handle), it will just be ignored, rather than printed to the page twice.

  • styles are exactly the same, except you use wp_enqueue_style()

There is a variation of this functionality for the admin styles and scripts - all you have to do is change the hooks to admin_print_styles and admin_print_scripts. Ozh made a nice post on this topic here - check it out.

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.

A word of warning though: I'd rather see false positives (enqueuing when it's not needed) than false negatives (miss enqueuing when it's needed), so please do your matching wisely and test well.

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.

Our HP0-D07 study guides will help you to pass your 642-436 and 640-816 exam on first attempt guaranteed.
Similar Posts:

Share

]]> http://beerpla.net/2010/01/13/wordpress-plugin-development-how-to-include-css-and-javascript-conditionally-and-only-when-needed-by-the-posts/feed/ 58 Supercharge Your GNU Screen With A Power "Taskbar" And Never Feel Lost Againhttp://beerpla.net/2009/10/06/supercharge-your-gnu-screen-with-a-power-taskbar-and-never-feel-lost-again/ http://beerpla.net/2009/10/06/supercharge-your-gnu-screen-with-a-power-taskbar-and-never-feel-lost-again/#comments Tue, 06 Oct 2009 14:30:00 +0000 Artem Russakovskii http://beerpla.net/?p=1154 Introduction

imageScreen is awesome. Once you become comfortable navigating around it, you start using it ALL the time. No more dropped sessions, no having 10 Putty windows open at the same time, no more nohup.

However, with default screen settings I've always felt a bit lost and out of place, mostly because there was no "taskbar" with a bird's eye view of all windows. Pressing ctrl-a, " really does get annoying fast (that's the command that brings up the window selector – screenshot below).

image

So instead I modded my screen to have a "taskbar" which sits at the bottom of screen and adds:

]]> Introduction

imageScreen is awesome. Once you become comfortable navigating around it, you start using it ALL the time. No more dropped sessions, no having 10 Putty windows open at the same time, no more nohup.

However, with default screen settings I've always felt a bit lost and out of place, mostly because there was no "taskbar" with a bird's eye view of all windows. Pressing ctrl-a, " really does get annoying fast (that's the command that brings up the window selector – screenshot below).

image

So instead I modded my screen to have a "taskbar" which sits at the bottom of screen and adds:

  • the name of each window
  • a clear marking of window states, such as
    • the currently active window (* and different background)
    • last used window (-)
    • if you're sharing the current window with someone else (&)
  • the current incoming/outgoing bandwidth in bytes/sec, updating every 5 seconds
  • the current time
  • the load on the server, as reported by the uptime or w commands

Of course, all of the above is customizable to your liking, but this is what I picked for myself.

Without further ado, here's a screenshot:

screen power taskbar

Doesn't that make you feel much more homey?

Now using a shared screen session for pair programming, as suggested in a recent article posted on Hacker News, suddenly sounds even more appealing.

Did you know you could rename each individual window within screen? Just press ctrl-a A and enter a new name.

Installation

Here's what you need to get this bar on your screen:

  • download my .screenrc (0 B, downloaded 964 times) and put it in your home directory. Make sure the location of wormulon (installed in the next step) is correct. Also, specify the right network interface (eth0 in most cases).
    Here is the file, for reference:
1
2
3
4
5
6
7
8
9
10
11

# Monitor eth0 bandwidth and update every 5 s
# Assign the output of this cmd to '%1`' and use it in the below hardstatus line:
backtick 1 0 0 /usr/local/bin/wormulon -d 5 -i eth0
 
hardstatus alwayslastline "%{bw}[%H] [%?%-Lw%?%{wb}%n*%f %t%{bw}%?%+Lw%?]%=%{bw} [%1`] [%c:%s] [%l]" # modified from http://lists.gnu.org/archive/html/screen-users/2007-08/msg00008.html
 
# Set the scrollback length:
defscrollback 10000
 
# Select whether you want to see the copyright notice during startup:
startup_message off
  • download and compile wormulon (wormulon-0.1.4.tar.gz 45.3 kB, downloaded 473 times or from a mirror) – a nifty little program that shows incoming and outgoing bandwidth and is perfect for integrating with screen. You can omit this step if you don't want the bandwidth monitor. I know the name is a bit odd but it's a legit little open source utility – feel free to check out the code.
tar xvzf wormulon-0.1.4.tar.gz
cd wormulon-0.1.4/
./configure && make
sudo make install # this installs into /usr/local/bin/;
                  # alternatively, copy the wormulon binary wherever you
                  # want and update the path in .screenrc

Now restart screen and you're good to go.

Similar Posts:

Share

]]> http://beerpla.net/2009/10/06/supercharge-your-gnu-screen-with-a-power-taskbar-and-never-feel-lost-again/feed/ 1 Firefox Being Slow, Especially Switching Tabs, High CPU Load, Memory Problems? Are You Using Firecookie For Firebug?http://beerpla.net/2009/05/13/firefox-being-slow-especially-switching-tabs-high-cpu-load-memory-problems-are-you-using-firecookie-for-firebug/ http://beerpla.net/2009/05/13/firefox-being-slow-especially-switching-tabs-high-cpu-load-memory-problems-are-you-using-firecookie-for-firebug/#comments Wed, 13 May 2009 14:00:00 +0000 Artem Russakovskii http://beerpla.net/2009/05/13/firefox-being-slow-especially-switching-tabs-high-cpu-load-memory-problems-are-you-using-firecookie-for-firebug/ image The Problem

I use a lot of extensions. A LOT. They slow down my Firefox while giving something useful in return. Most of them are harmless and do not affect the speed too much but there are select few that are just CPU, memory, and performance hogs.

Until Firefox gets an extension manager that can show what the impact from each extension on time/CPU/memory is, one can resort to guessing, disabling, testing, and looking for clues to find these conniving little bastards.

Anyway, so where was I? Recently, my Firefox became increasingly unresponsive, especially when switching tabs. After some time, it was a pain to switch tabs altogether, so I had to resort to restarting the browser, only to ...

Read the rest of this article »

]]> image The Problem

I use a lot of extensions. A LOT. They slow down my Firefox while giving something useful in return. Most of them are harmless and do not affect the speed too much but there are select few that are just CPU, memory, and performance hogs.

Until Firefox gets an extension manager that can show what the impact from each extension on time/CPU/memory is, one can resort to guessing, disabling, testing, and looking for clues to find these conniving little bastards.

Anyway, so where was I? Recently, my Firefox became increasingly unresponsive, especially when switching tabs. After some time, it was a pain to switch tabs altogether, so I had to resort to restarting the browser, only to find the same problem coming back again and again. Today, I finally got a clue – a bunch of such messages came on mentioning this unresponsive sript and prompting me to stop it:

chrome://firecookie/content/fireCookie.js:2881
chrome://firecookie/content/fireCookie.js:3156
chrome://firecookie/content/fireCookie.js:3794

Firecookie (0.8 at the time of this writing). Arrr!

Quickly, I googled the problem and sure enough – other people are suffering from the same problem.

Firecookie adds support for managing cookies directly from within Firebug and is quite handy. However, not handy enough to kill my browser on a daily basis, even with cookie handling turned off within Firebug itself.

The Result

I am pleased to report that after uninstalling Firecookie, my Firefox is noticeably faster switching tabs, does not hang, and does not use as much CPU. I do not know what the developer of Firecookie is going to do about it as he does not seem to be able to reproduce the issue. Until then, goodbye frustration and hello… whatever other extensions handle cookies.

Similar Posts:

Share

]]> http://beerpla.net/2009/05/13/firefox-being-slow-especially-switching-tabs-high-cpu-load-memory-problems-are-you-using-firecookie-for-firebug/feed/ 5