The Arcive of Official vBulletin Modifications Site.It is not a VB3 engine, just a parsed copy! |
|
#1
|
|||
|
|||
Want to mod cleanup2.php for post_parsed cache
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: Code:
$vbulletin->db->query_write(" DELETE FROM " . TABLE_PREFIX . "post_parsed WHERE dateline < " . (TIMENOW - ($vbulletin->options['cachemaxage'] * 60 * 60 * 24)) ); 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: Code:
// 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: 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" ); |
#2
|
|||
|
|||
What is your goal with this change?
|
#3
|
|||
|
|||
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. |
#4
|
|||
|
|||
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. |
|
|
X vBulletin 3.8.12 by vBS Debug Information | |
---|---|
|
|
More Information | |
Template Usage:
Phrase Groups Available:
|
Included Files:
Hooks Called:
|