Script bloat in the main template

Hi all, I see quite a few people are having the same problem (css and javascript bloat in templates that don't even use the comments system). I have tried the various hacks and updates in the forum here and am still unable to remove the bloat from the home page and others - its almost as though the include rules in the parameters are being ignore and it just includes it everywhere? I have a few sites that use chrono-comments (cause despite this minor oversight it is still the best damn comments system I've seen :-) ) but it would be nice to clean up those sites.
Any help greatly appreciated.

Hi shardnzl,

If I recall correctly Max posted a modified version of chronocomments.php that fixed this problem some months back.

Bob

Thanks for the swift reply :-)
I downloaded the one that was in a zip file all by itself, but it didn't make any difference :-(
I'll try again and do a forum search, just in case I grabbed the wrong one.

Cheers

This is the one I downloaded ..
http://www.chronoengine.com/forums/index.php?option=com_chronoforums&cont=posts&f=17&t=11304

But that seems to be for a problem with repeating script tags on pages. My problem is that they are there even if that page isnt using chrono_comments (basically they are included with every page regardless of settings in the parameters). Is it a write permission problem on the saving of settings perhaps?

Hi shardnzl,

Oh - OK, I didn't know that there was another problem. Please can you post a link to a page showing this?

Bob

Sure ....

http://www.cardrona.com
http://www.enrgfitnesschicago.com

Cheers - and thanks for your patience and support :-)

Hi shardnzl,

I don't know much about ChronoComments or how it works but it looks to me as though it's loading the plugin on any page which contains an article. I guess that there is no easy way of knowing at that stage if the article has comments enabled or not??

Max may have a more useful reply.

Bob

Thanks for taking the time to have a look anyway GreyHead - and I look forward to Max's ideas :-)

Any progress on this? I've had a look myself and the parameters are being stored correctly in the database (for where you want them to appear) they just seem to be ignored when it comes to adding code. :-)

I see that others in the forum are having the same problem (and have been since 2007) lol - and the only solution they've offered unfortunately suppress the code everywhere (the $suri request) including on comments pages.
Is there an easy way to ask (outside of the function) whether the current id exists in the parameters and then include the headers/scripts only then?

SOLVED.
I wrote a quick lookup to compare the category ID of the current page with those identified by the chrono_comments parameters as containing comment functionality. This obviously won't work for sections (though you could repeat the loop for them). The result will be that only those pages that you have identified as needed comment functionailty will load the various css and javascript files necessary. Place at the top (under the access call) of the plugins/content/ChronoComments.php page and then comment out the existing $mainframe->registerEvent call.

/* test current category */
$c_count = 0; $curpage = htmlspecialchars($_REQUEST["catid"]);
$paras = JComponentHelper::getParams('com_chronocomments');
$ptemp = $paras->get('comment_categories');
for($loopr = 0; $loopr < count($ptemp); $loopr++){
    if($ptemp[$loopr] == $curpage){ $c_count++; }
}
if($c_count != 0){ $mainframe->registerEvent( 'onPrepareContent', 'plgContentChronocomments' ); }
/* end test */

Note, this will only work if the category id (catid) is in the current "joomla generated" url (Joomla generates a url that contains the various ids and component names that make up the page and this is not always displayed in the browser). If using Joomla's SEF option then this might not work - whereas SF404E lets Joomla make the extended URL and then replaces it on the fly (so it works with SF404E but not with Joomla trying to make nice links itself). If you're not sure try echoing $curpage to find out if the catid exisits.