Feature Request: Dynamic Fragmentation

[raamdev]

Dynamic Fragmentation would allow a site owner to specify dynamic portions of a page that should not be cached and which should always be loaded dynamically, similar to how WP Super Cache and W3TC use mfunc and mclude.

---

@jaswsinc's thoughts on this topic, forked from #56:

My issues with this feature...

• There have been a few security issues related to dynamic/fragment caching in WordPress via mfunc and mclude. It looks like WP Super Cache and W3 Total Cache were both bit by this since they are using HTML comments in the syntax parser to deal with fragment caching.

  Someone leaving a comment on the site, or posting content via bbPress (or by other means) might be able to slide a comment through; where it was possible to hack into the fragment caching parser and inject code into the site.

  The solution that seems to have done the trick, at least in the short term is to require a secret code in the comment parser; and then strip those out before rendering the document. I really do NOT like this at all. It still seems very prone to security problems.

• We could support this functionality in one way or another; but when/if it is used, it WILL degrade performance considerably. There is the need to run the dynamic function or include itself; so that's performance hit number one. Then, in order to maximize compatibility in the dynamic fragments, QC will need to delay its delivery of these fragments until after WordPress loads; otherwise any dynamic function/include will not have WordPress available to it. That's performance hit number two, and it's a big one.

---

In summary, I don't like this idea at all. I can understand why some folks might like to experiment with this functionality in other caching plugins, but IMO it's better for WordPress plugins to use JavaScript snippets when they need to circumvent a page caching plugin and deliver portions of the page dynamically.

I have not tested the Ad Rotate plugin myself, but I feel sure that there are other plugins on the market that would allow for JavaScript to be used; so that content could continue to be delivered dynamically while the remaining page content remains cached as usual. This is really the best way to pull a portion of the document out of the cache itself; in my view.

<script type="text/javascript">
     $('#banner').load('http://www.example.com/wp-content/plugins/banner-plugin/load.php');
</script>

An idea from @jaswsinc:

It seems to me that more often than not, this functionality is used together with certain Widgets, or with certain Shortcodes. It might be worth looking at a Quick Cache shortcode or Widget add-on that would allow a site owner to do something like this.

[quick_cache_exclude]
    [my_theme_shortcode /] or some other content here.
[/quick_cache_exclude]

Then, Quick Cache could work out a way to exclude that particular fragment on it's own; making it easier for a site owner to implement this themselves, by just using the shortcode provided by Quick Cache. We might also take it upon ourselves to try and standardize this across all of the caching plugins by also supporting a shortcode alias like [donotcache][/donotcache]; where other WP caching plugins might add support for it in the future.

In the case of a Widget there could be a checkbox to exclude the widget from being cached.

This would still degrade performance, but it would avoid a security issue and make it compatible with any theme/plugin that introduces a widget or provides a shortcode. For that matter, the shortcode could be used to wrap any sort of content, whether it be a shortcode itself; or not.

~ Just an idea. I think it needs further consideration.

[raamdev]

@jaswsinc Just thinking aloud here.. I wonder if it would be possible to dynamically load an entire WordPress plugin using Javascript, without changing anything about how the plugin itself works... I'm thinking something like js-plugin-loader.php that gets called via Javascript, which then does all the work of loading the plugin that WordPress would normally do...

I suppose the issue there would be that WordPress would've already loaded and stopped (as it's a server-side PHP app), which means that the js-plugin-loader.php would probably need to reload all of WordPress to get the plugin loaded... right? But maybe that's OK...

[jaswrks]

which means that the js-plugin-loader.php would probably need to reload all of WordPress to get the plugin loaded... right? But maybe that's OK...

Right. I agree that's worth considering. Another thing to consider, along the same line; is a Web Socket to achieve this. Although, in both cases we'd be loading WP a second or third or fourth time; whereas with mfunc, mclude or a shortcode; it would all occur in the same process.

[raamdev]

Although, in both cases we'd be loading WP a second or third or fourth time

In which case it would probably be faster for the site owner to just exclude that page from the cache entirely...

[jaswrks]

I was just playing a bit with this, and another problem that I see now is related to the WP query itself. Ideally, we would want to avoid allowing the WP query to take place yet again, whenever we serve the cache back out.

In other words, when we reparse the excluded portions of the page (i.e. the dynamic parts), we'd probably want to do that around the init hook at the earliest possible priority. This would maximize compatibility with whatever it is that's going to be run dynamically.

However, if whatever is running dynamically needs anything that might be directly or indirectly related to the current Post/Page/View/etc; none of that will be available as expected. In short, whatever would run in this phase would need to be independent from WP; more or less. Otherwise, QC would need to wait for all plugins to initialize, then wait for WP to make the query; and then parse back out the dynamic portions that were excluded. That would defeat the purpose of caching it to begin with. As @raamdev mentioned before, might as well just exclude the entire page in this case. Hmmm..

[jaswrks]

Referencing: https://css-tricks.com/wordpress-fragment-caching-revisited/

[DangitRick]

+1 to this feature being added

Having some sort of way to either exclude content from being cached -- or even specifying that certain content should have a shorter expiry time -- would be pretty useful for things like "random posts" (presumably you'd want this excluded from caching... or set to a short expiry time to ensure it changes often) or "top posts" widgets (which would benefit from something like a once-per-day expiry).

[ThePopularizer]

I've a site that displays relative timing (e.g. "5 min ago"). It'd be great to be able to exclude those parts from cache.

[BlanchRose]

My website use a "recent posts" and a "recent comments" widget. They need to be up-to-date ; but deleting the whole cache after each comment would create a lot of overhead.

Partial caching allowing me to exclude these widget would help a lot.

If the content of these widget could be separately cached and pulled together at request time it would be even better.

[ghost]

I have created custom sharing buttons for my site, with shares counter. I would be great if those counter can update dynamically, when someone like the post.
I vote YES for this feature :)

[raamdev]

@joe8104 A better way of handling dynamic updates like that would be to use JavaScript, that way your sharing buttons will work with any caching plugin. :-)

Thanks for adding your +1 to this feature request. 😄

[webprom]

woocommerce recently viewed products also need some exclusion from caching. any idea how to exclude?