Item5938: CSS & JS not loaded for ACTIONSEARCH

I recently upgraded from 4.1.2 to 4.2.2 + latest (07 May 2008) action tracker. My ACTIONSEARCHes do not have the color coding, and edit links open in the same window.

I believe I've found the cause, but I don't understand the TWiki rendering pipeline well enough to suggest a fix.

ACTIONSEARCH is implemented by registerTagHandler; the TWiki engine decides when to activate it and hides the tag from other things. ACTION is implemented via commonTagsHandler, which is only called if TWiki finds an unknown tag; the handler bails if if doesn't find a tag of of the form ACTION.*

So: the CSS & JS files are inserted by commonTagsHandler. commonTagsHandler is never called because TWiki is handling ACTIONSEARCH itself.

Inserting a bogus tag such as ACTIONBLARG will cause the routine to run and add the appropriate files. Simply copying the addToHEAD lines to _handleActionSerach does not seem to work.

-- TWiki:Main/JustinLove - 18 Aug 2008

We see this same issue on our attempt to convert to 4.2.2. No js or css added to the head on pages with ACTIONSEARCH. The workaround of adding ACTIONBLARG{} works around the problem.

-- TWiki:Main.GeorgeClark - 04 Sep 2008

ACTIONSEARCH tags are registered using TWiki::Func::registerTagHandler(...) (ActionTrackerPlugin.pm, line 54), which causes them to get parsed like Twiki variables and a callback invoked when they are found. However other ACTION tags are caught by commonTagsHandler(...) (a few lines lower at 60).

As it stands the javascript for asynchronous updates and css for formating of the action tables are included in the page in commonTagsHandler using calls to TWiki::Func::addToHEAD(...) (lines 69 to 74). This does not get called for ACTIONSEARCH because it is using the different registered mechanism. If you only have an ACTIONSEARCH on your page and no ACTION (or even ACTIONBLARG) you don't get the javascript and css, hence the observed symptoms.

As a temporary workaround i included the following code in _handleActionSearch at line 395...

   # Lee Ryman, 2008-12-19: Added following lines as commonTagsHandler is not being called for tags registered by registerTagHandler...
   my $debug = $ENV{TWIKI_ASSERTS} ? '_src' : '';
   
   TWiki::Func::addToHEAD('ACTIONTRACKERPLUGIN_CSS', <<HERE);
<link rel="stylesheet" href="$options->{CSS}" type="text/css" media="all" />
HERE
    TWiki::Func::addToHEAD('ACTIONTRACKERPLUGIN_JS', <<HERE);
<script type='text/javascript' src='%PUBURLPATH%/%TWIKIWEB%/ActionTrackerPlugin/atp$debug.js'></script>
HERE
   # ...End addition by Lee Ryman, 2008-12-19

...Its not the best as it duplicates code, but it fixes the problem. Perhaps it would be better to remove it all together from commonTagsHandler(...) and include it in _lazyInit(...)? Someone with a better knowledge of the framework and plugin to confirm.

Regards,

• LeeRyman - 19 Dec 2008

I tried including the above code at the end of _lazyInit(...) just before the $initialised = 1; and removed it elsewhere and it appears to work. Could someone confirm or deny this is the right thing to do?

• LeeRyman - 19 Dec 2008

That should be fine for now, Lee. I will try to get to the plugin to review this in detail some time over the next few weeks. Do the unit tests still pass?

Do you have checkin rights? If so, go ahead and make the change. If not, attach a patch here and I'll apply it.

• CrawfordCurrie - 19 Dec 2008

I do not yet have checkin rights - I'm probably still a little green with it all and at the moment I'm doing things a bit adhoc. Let me get a working copy of trunk set up and i'll attach a patch.

• LeeRyman - 19 Dec 2008

Excellent analysis, Lee. I have this in hand.

-- CrawfordCurrie - 28 Jan 2009

Done -- CrawfordCurrie - 29 Jan 2009