darkcanuck

Yes, in either case (whether you filter on ‘the_excerpt’ or ‘get_the_excerpt’) the function wp_trim_excerpt() will create the excerpt based on the content. To do this it will first apply the filter ‘the_content’.

Ugh, the excerpt filter path is a weird one. Take a look at the code used to generate the excerpt and you’ll see that the filter the_content also gets involved *if* there is no excerpt saved in the database.

Check out Michel Fortin’s analysis for more details.

Maybe injinuity is referring to the “Get Firefox” icon/link at the bottom of all the admin pages? Just a guess…

angsuman,
you can have multiple indices into a table and they can be either single or multi-column. In general, a query will be faster if all of the fields used by WHERE clauses are indexed (separately or, even better, all together).

So if the most significant WHERE clause uses the date, the query will execute much faster if the date is indexed.

This is a bit of a simplification of course, query optimization is a fairly complex topic.

Karel,
You need to add the SAVEQUERIES line to the *real* index.php, not the one in your theme. Look in your site’s root directory (normally where you installed WordPress).

<code>wp_footer(); does the same thing as <code>do_action('wp_footer'); – I’m just used to the old style so that’s my error. I’ve updated the instructions.

hooopla:

Upon closer inspection, it looks like queries [2]-[6] are being added by the plugin ([7] onwards seems to match more closely with [2]+ in the non-plugin version). Either the plugin is executing these queries directly or else it is forcing WordPress to do another pass through “the loop”. The latter is where I would start.

The second loop ([7]+) appears more normal and uses your setting of 10 posts per page.

My guess is that the plugin hijacks the first pass through “the loop” to count the number of posts available. Then it starts a second pass with the settings back to normal for output to the user. If that’s all wp-paginate needs, a better approach would be to do a single query to count the posts rather than forcing the loop to do it.

Oh my…

The query to look at is [3] (as ugly as [4] and [5] look, [3] is the real troublemaker):
– in the no plugin version, the query is limited to the first 10 posts
– with plugins activated, the query grabs all posts every time.

Besides the extra query time, this may cause WP to try to preprocess all of the posts returned.

(someone’s got to make those next/previous page links a little more obvious… and fix the thread feed links)

trevorturk, make sure you enable SAVEQUERIES as pointed out by hooopla. If it could be turned on in the plugin I would have done it, but alas this is not possible.

LoneBoat et al, you’re very welcome. This plugin doesn’t do very much, but I’m glad that you find it useful.

Here’s a quick plugin to do the above: jeromes-query-diagnostics

Note that the plugin can’t set the SAVEQUERIES constant itself, you have to do it manually (see plugin file for details). No JS required.

Podz, I don’t think you can set SAVEQUERIES from a plugin early enough to catch *all* queries. I can look into making a quick plugin.

For what it’s worth, if you want to do diagnostics, add the following to your index.php (before the wp-blog-header.php include):
define('SAVEQUERIES', 1);

And add this code somewhere in your site’s footer:
echo "
<div class=\"stats\">
{$wpdb->num_queries} queries, ";
timer_stop(1);
echo " seconds.
</div>
";

if (SAVEQUERIES)
{
echo "<!--";
print_r($wpdb->queries);
echo "-->";
}

Folks, take a step back for a second to consider the problem rather than engaging in a my-db-is-better-than-your-db argument.

There are 2 possible causes for the slowdown on hooopla’s site:

1) Poor scaling in the posts loop due to query ineffeciency, badly structured db schema or poor db engine performance.

2) Poor scaling in other queries executed by WordPress.

While there may be some cause to examine the first, the likely culprit is the second one. Does the site list links for categories or archives? Those queries are more complicated than you think and will degrade in performance as the database grows in size. How many plugins are in use on the site? Many plugins run inefficient queries and add unnecessary processing time.

If you really want to know what’s going on, try turning on SAVEQUERIES and dump the value of $wpdb->queries at the bottom of the page. You’ll see what WordPress is trying to do and how long each query takes to execute.

I think so and I’ve seen other complaints about it too. But others claim it’s a feature. It all depends on your point of view, I suppose…

Your template may be showing the excerpt instead of the post content. The excerpt is automatically created and always gets cut off to a certain length.

If you only have one post in the database, WordPress may go into single post mode. It’s silly, but that’s what happens.

Looks like it’s working now with the second post added…

What setting did you use for permalinks? (go to Options » Permalinks in the admin menu)
If it shows /index.php/, clear the value and resave.

The <!--more--> tag won’t be used when viewing a single post, only when looking at the index or archives. If you want to do paging within a post you can use <!--nextpage--> instead (but your template may need to be changed to support this).