Want to mod cleanup2.php for post_parsed cache

[ddmobley]

I am looking for a mod to cleanup2.php in the includes/cron directory that deals with cleaning up the post_parsed cache.

The current code looks like this:

$vbulletin->db->query_write("
DELETE FROM " . TABLE_PREFIX . "post_parsed
WHERE dateline < " . (TIMENOW - ($vbulletin->options['cachemaxage'] * 60 * 60 * 24))
);

What I want is to modify this code where it also compares the sticky field in the thread table. If the thread is sticky then the postid in post_parsed which matches the firstpostid of the sticky thread would not be deleted.

Is this doable?

I believe I have written my own solution. If anyone sees anything wrong with this, please respond. I modified the code above to look like this:

// expired cached posts
$vbulletin->db->query_write("
DELETE FROM " . TABLE_PREFIX . "post_parsed
WHERE dateline < " . (TIMENOW - ($vbulletin->options['cachemaxage'] * 60 * 60 * 24)) . "
AND NOT EXISTS (SELECT firstpostid FROM " . TABLE_PREFIX . "thread WHERE firstpostid = postid)"
);


This is my latest code:

$vbulletin->db->query_write("
DELETE parsed FROM " . TABLE_PREFIX . "post_parsed AS parsed
LEFT JOIN " . TABLE_PREFIX . "thread AS thread ON thread.firstpostid = parsed.postid
WHERE parsed.dateline < " . (TIMENOW - ($vbulletin->options['cachemaxage'] * 60 * 60 * 24)) . "
AND thread.sticky = 0"
);

[Marco van Herwaarden]

What is your goal with this change?

[ddmobley]

I added a mod to allow certain usergroups to post HTML to the forums, but when the post with the HTML expires in the cache, the next reader to view the post who doesn't have the HTML status causes a cached post of just raw HTML code to be saved. This mod was to allow me to stick posts, and leave the cache with the HTML approved version in place. It still doesn't work like I want, as periodically, the cache gets deleted anyway and a page of raw HTML gets displayed. Even setting the particular forum as HTML for the forum level doesn't work. It shouldn't be so difficult to allow admins to post HTML and not other users.

I guess the real solution is to just set the dateline of the post_parsed record to some unbelievably forward-in-time number.

[Marco van Herwaarden]

The real solution would be to fix the modification you are using. Parsing should not be based on the member viewing, but on the member who posted.

Like it currently works it is even dangerous by the sound of it. How about the following:
- Mallicous user tries to hack your site by posting mallicious HTML. Not a real problem as default vB will not parse it and your modification will probably be setup not to parse the HTML from this "regular" member. But what if an admin (or someone set to have HTML permission) is the first to view the post (or the first after a cache clean), now it would be parsed and your site is successfully hacked.