Post Caching (BBCode specifically)

[Mooglefrooglian]

Hey there,

I've been having issues with huge posts with tons of BBCode being extremely slow to load. It seems that the BBCode is being parsed every single time the page is requested. Setting caching to level 3 didn't seem to fix this - is there an obvious setting I can tick for this?

If there's not such a setting, I suppose I could go put a hook in the parse_bbcode function in the code and parse that, but I'd really prefer to avoid coding in PHP if possible.

Help appreciated.

[Kindred]

Are you actually using 2.1 beta?


And yes...  BBC is always interpreted and processed at page LOAD time.

[Mooglefrooglian]

Are you actually using 2.1 beta?

Production site is 2.0, but I'm playing with 2.1. This topic could be better placed, if you/someone wants to move it.

And yes...  BBC is always interpreted and processed at page LOAD time.

Sounds like a travel deep into the depths of the source code, then, as I can't find any mods. Thanks.

Edit: For anyone with the same problem as me, the parse_bbc function can be found in Subs.php. It's actually passed an id for use with caching - you can just throw in a cache_get_data/cache_put_data (SMF-defined) thing at the start/end. Just check to make sure the post is over a pre-defined length for caching (no point doing it for small posts) and that there IS an id passed in for caching and you aren't using the default ''.

Edit2: Actually, there's already caching for caching >= 2:

   

Code Select Expand

if ($cache_id != '' && !empty($modSettings['cache_enable']) && (($modSettings['cache_enable'] >= 2 && strlen($message) > 1000) || strlen($message) > 2400) && empty($parse_tags))

But it seems to be on a per-user basis or something... I'll try messing around with it. I think the cache-key should not serialize the browser.

[nend]

I am starting to wonder also. I knew that cache was there but never really looked at it until you brought up the browser being in the key.

I can see the logic here.

Code Select Expand

'parse:' . $cache_id . '-' . md5(md5($message) . '-' . $smileys . (empty($disabled) ? '' : implode(',', array_keys($disabled)))

But I don't get the reasoning here.

Code Select Expand

serialize($context['browser']) . $txt['lang_locale'] . $user_info['time_offset'] . $user_info['time_format'])

Maybe it is directed to compatibility for BBC mods that may display something different according to these variables. IMHO though if a mod does change something like this then it is up to the mod to make sure the key gets updated accordingly. However this is not possible due to the fact that cache_id is not global so any BBC mod that relies on integration hooks cannot make that determination.

An easier method would be using the $auth variable passed on to the function. I still think hooked mods should have some say on the key, especially if they display information to one group and not another. The current key doesn't protect this information and is vulnerable to leaking sensitive information if a BBC mod shows different information to certain members.

Code Select Expand

if ($cache_id != '' && !empty($modSettings['cache_enable']) && (($modSettings['cache_enable'] >= 2 && strlen($message) > 1000) || strlen($message) > 2400) && empty($parse_tags))
If you look at it, $cache_id is never set in the function itself and can only be set on the function call. So the code that calls the function must set up the id. The means if the id is not set on the function call then the cache will definitely not be made. In Display.php, the cache_id is set, so this doesn't apply here.

I think the main problem your having is this line.

Code Select Expand

if (isset($cache_key, $cache_t) && array_sum(explode(' ', microtime())) - array_sum(explode(' ', $cache_t)) > 0.05)
BBC on my forum definitely doesn't take that much time processing. Usually a page gets served around 0.01 seconds.

Just a little thoughts on the topic.

Thank you for bringing this to my attention.

[nend]

Argh, looking at 2.0.x

In 2.1, it looks like mods do have access to modify the $cache_id, this fixes that problem of spilling out sensitive information. Modifications will need to update this key if they do that sort of thing.

Ok,
$context['browser'] is in the shadow BBC.
$user_info['time_offset'] and $user_info['time_format'] is used by Quote.

Now it makes sense. 

[Irisado]

Production site is 2.0, but I'm playing with 2.1. This topic could be better placed, if you/someone wants to move it.

Is the query you are asking in this topic related to 2.0 or 2.1?  This is the key piece of information we need from you, in order to know whether the topic stays here or whether it needs to be moved .