Comments on: Don't include wp-load, please.

By: Interview with Ronald Huereca - WordPress Tavern Forum

Interview with Ronald Huereca - WordPress Tavern Forum — Sun, 21 Mar 2010 00:56:24 +0000

[...] are Ronald's opinions on Otto's recent blog post regarding use of wp-load.php: http://ottodestruct.com/blog/2010/do…p-load-please/ Personal blog | Twitter Menu plugin | CSS Generator | Premium Support | New plugin: Code [...]

By: Otto on WordPress » Blog Archive » Don’t include wp-load, please.

Thu, 04 Mar 2010 22:22:25 +0000

[...] Don’t include wp-load, please. March 4, 2010, 4:22 pm Originally published here: http://ottodestruct.com/blog/2010/dont-include-wp-load-please/ [...]

By: Otto

Otto — Fri, 19 Feb 2010 14:36:34 +0000

I have a plugin which stores custom CSS whole in the database in the same way. Currently, I output it like this. Right at the top of the plugin:

if ($_GET['trigger'] == 1) { ?>
$options = get_option(‘plugin_options’);
header( ‘Content-Type: text/css; charset=utf-8′ );
echo $options['custom_css'];
exit;
}

This is the fastest way I can find to output the data without actually writing it to a static file. This stops WordPress as early as possible, right at the plugin loading, minimizing the impact on the system. Still not ideal, of course, but it works. And in my case, the custom CSS is being read by a third party which does static caching separately from me, it’s not being read by the browser directly, so it’s fairly minimal to begin with.

By: Ryan

Ryan — Thu, 18 Feb 2010 23:58:00 +0000

In the past I stored the CSS whole inside the WP database, then outputted it via a file which loaded wp-load.php. I’m now caching that in a static file, with a fall-back to wp-load.php when the static file does not exist. It seems to be working well so far.

By: Ryan

Ryan — Wed, 17 Feb 2010 02:27:36 +0000

Yes that works, I use that method myself. Unfortunately it of course only works when people visit one of your pages a second time

By: Otto

Otto — Mon, 15 Feb 2010 22:07:25 +0000

I have used the second method I detailed above for CSS before. I’m not proud of that, but it was necessary in the given context.

For speed reasons alone, I would recommend generating the CSS whole, storing it all in a single place, then merely outputting it on demand, instead of generating it fresh from options each and every time.

By: Hikari

Hikari — Sun, 14 Feb 2010 03:52:53 +0000

Hey Otto very nice tutorial tnx!

I’ve seen a plugin use some HTTP header calls to set cache settings, is that possible?

By: Ryan

Ryan — Sun, 14 Feb 2010 01:52:43 +0000

I spoke too soon. I just saw your comment above about AJAX and it seems this is not the correct way to handle those either …. back to the drawing board for me :p

By: Ryan

Ryan — Sun, 14 Feb 2010 01:43:40 +0000

You said “Really, really, bad idea. That’s a cross-site-scripting hole just waiting to be exploited.”

http://www.wptavern.com/forum/plugins-hacks/1105-sending-settings-javascript-files.html

Admittedly I wasn’t validating my data very well in my example code there. I should have used more explicit checks for specific values or for integers.

By: Ryan

Ryan — Sun, 14 Feb 2010 01:38:46 +0000

I agree on that now for scripts, however there are other uses, including dynamically created CSS for when you can’t write to the WP installation to cache the CSS file statically and so using this technique is the only option to use without loading the CSS directly into each page. In my experience, the difference in page load times is too small to measure on most servers, but on some servers it totally blows out the load times really badly.

I assume the exact same techinque would be used for processing AJAX data too.