Post Content Prerendering

[markjaquith]

This is a first effort on building post content prerendering, as was discussed on wp-hackers.

The new hook is "the_content_filtered" and is stored in the already existing post_content_filtered column.

It involves a modification to the wp_insert_post() function that handles the prerendering on post publish/save. Several global variables are called in, so as to "recreate" the environment (the $post object and $id, namely.) This is because some "the_content" filters need to use these values and modify the post content accordingly.

For display, setup_postdata() has been modified. If the post_content_filtered column is blank and the post_content column is NOT, the post_content_filtered data will be filtered right then, and inserted into the database. This eliminates the need to do "rebuilding" as the "rebuilding" is done on the fly.

"the_content" filter will function as before. I have moved WP's default "the_content" filters to "the_content_filtered" and the idea is that when WP 1.6 comes out, we can educate plugin authors about the new hook, so they can make a decision for their plugin (most filters can be run ahead of time, but a few, like Google Hilight, need to be dynamic). The real speed boost will come when users have many plugins installed that use the new hook, especially on the front page, or category/month archives. Think textile2, acronym, multiple search/replace plugins, etc. I'd had this stuff max out PHP's memory when run on the front page! This is going to be much more efficient.

This is a first try, and I did this rather quickly, but it seems to work. Paging is working too, which is good.

[markjaquith]

for WP 1.6 SVN

[markjaquith]

for WP 1.6 SVN

[markjaquith]

for WP 1.6 SVN

[rob1n]

I don't think this is feasible. Filters change by the second, and if you want pre-rendering might as well use something like WP-Cache to pre-render the whole page?

[masquerade]

Filters don't really change by the second. Theoretically, they could I suppose, however most filters, especially the defaults, things like abbr tag plugins, etc. etc. are fairly constant.

Prerendering the post I think is useful for those who don't want to cache the whole page, because it might have other dynamic content on the page, especially in the sidebar. Not having to run the filters on the post each time saves a considerable amount of processor time. It is also possible that, to ease your fears and to make everything better for everyone, that along with the prerendered content, an array of the filters which are applied to it is stored, and when displaying, compare the list of currently applied filters with the ones that are prerendered, and update accordingly.

+1 for this idea.

[rob1n]

I don't think the current patches apply. Feel free to prove me wrong, though.

[westi]

For me pre-rendering is a very good idea.

The more code that we can remove from needing to run when a post / page is displayed the better.

+1

[markjaquith]

My original suggestion was that we keep the_content running live for 100% backwards compat, and implement a new the_content_filtered hook that'll run on the pre-filtered content (i.e. after the_content). That way plugin authors can update at their leisure and once they do, the full speed benefits will be realized.

the other option is making the new hook the "live" option that is run every time. This will break any plugins that need to run live (few do), but it'd give us the maximum immediate speed boost.

We'd also need to make sure that the prerendered content expires whenever plugins are enabled or disabled. We'd want to functionize that so that other plugins could call it. For instance, say you have a plugin activated that alters the_content, and you change an option in that plugin. You'd want the prerendered content to expire so it could be updated.

We might eventually have Manage > Cache with built-in HTML output cache management that would allow you to manually flush the HTML + content prerendering caches.

[pishmishy]

Bumping milestone for feature freeze.

[DD32]

I personally think that the caching Plugins such as WP-Cache and others have probably removed the need for this, the core seems to be pretty fast in the rendering of most items, I have a feeling that loading the shear amount of code probably uses more time..

[Denis-de-Bernardy]

a caching plugin could easily deal with this if someone bothers to commit #6284...

[Denis-de-Bernardy]

#6284 has been fixed -- this can now be done by a plugin:

on loop start, find the last hook on the_content

on the_post action, if pre-rendered content exists then:

• disable all the hooks on the_content
• set post_content to its pre-rendered value

else:

• restore the_content hooks
• proceed as normal

on loop_start, find the last hook on the_content, add a store_cache() function after it

on post save:

• delete pre-rendered content for that post

on activate plugin:

• delete all pre-rendered content