Make WordPress Core

Opened 18 years ago

Closed 15 years ago

Last modified 9 years ago

#1595 closed enhancement (invalid)

Post Content Prerendering

Reported by: markjaquith's profile markjaquith Owned by: markjaquith's profile markjaquith
Milestone: Priority: normal
Severity: normal Version: 2.1.2
Component: Optimization Keywords: 2nd-opinion dev-feedback
Focuses: Cc:


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.

Attachments (3)

prerendering__functions.php.diff (1.3 KB) - added by markjaquith 18 years ago.
for WP 1.6 SVN
prerendering__functions-post.php.diff (3.1 KB) - added by markjaquith 18 years ago.
for WP 1.6 SVN
prerendering__default-filters.php.diff (990 bytes) - added by markjaquith 18 years ago.
for WP 1.6 SVN

Download all attachments as: .zip

Change History (18)

18 years ago

for WP 1.6 SVN

#1 @matt
18 years ago

  • Milestone changed from 1.6 to 2.1

#2 @davidhouse
18 years ago

  • Keywords bg|has-patch added

#3 @matt
17 years ago

  • Milestone changed from 2.1 to 2.2

#4 @rob1n
17 years ago

  • Keywords bg|2nd-opinion bg|has-patch removed
  • Milestone 2.2 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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?

#5 @masquerade
17 years ago

  • Keywords bg|2nd-opinion bg|has-patch added
  • Milestone set to 2.2
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Version changed from 1.6 to 2.1.2

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.

#6 @rob1n
17 years ago

  • Keywords 2nd-opinion dev-feedback added; bg|2nd-opinion bg|has-patch removed

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

#7 @westi
17 years ago

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.


#8 @markjaquith
17 years ago

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.

#9 @foolswisdom
17 years ago

  • Milestone changed from 2.2 to 2.3

#10 @foolswisdom
16 years ago

  • Milestone changed from 2.3 to 2.4 (next)

#11 @pishmishy
16 years ago

  • Milestone changed from 2.5 to 2.6

Bumping milestone for feature freeze.

#12 @DD32
15 years ago

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

#13 @Denis-de-Bernardy
15 years ago

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

#14 @Denis-de-Bernardy
15 years ago

  • Milestone changed from 2.9 to 2.8
  • Resolution set to invalid
  • Status changed from reopened to closed

#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


  • 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

#15 @DrewAPicture
9 years ago

  • Milestone 2.8 deleted
Note: See TracTickets for help on using tickets.