Several handlers in Plugins don't have access to the meta object. This makes simple meta operations, such as checking permissions, a real PITA, as the topic has to be re-read.
There's a workaround, and that's to use
$context->{can_render_meta}, but that's a hack at best, and unreliable.
The right solution is to add a $meta parameter into the right places in the following handlers. Note that this parameter will be
undef when
processing certain types of text (e.g. text from templates).
- 'beforeCommonTagsHandler',
- 'commonTagsHandler',
- 'afterCommonTagsHandler',
- 'afterEditHandler'
There's also a requirement for a $meta parameter to
expandCommonVariables.
Tracked in
Bugs:Item3773
--
Contributors: CrawfordCurrie - 16 Mar 2007
Discussion
Is it possible to get at the meta data object from the session object? That way it would not be necessary to add the meta parameter to the handlers.
Detail in case a meta parameter is added: The 4 handlers have 3 parameters
($text, $topic, $web ), except for
commonTagsHandler which as a 4th parameter for the
$included flag.
--
PeterThoeny - 17 Mar 2007
Unfortunately not, for the same reason you can't get at the topic text from the session object. You just don't know which topic is being rendered at any given time.
Of course you could wrap the Func methods in push/pop wrappers to
set the session object, but this is inconsistent with the way $text is presently passed.
Thanks for the heads-up, I knew about the $included parameter. I made the changes locally but can't test properly because of all the test case failures (due to the permissions changes in the _default and Main webs).
--
CrawfordCurrie - 17 Mar 2007
Peter's questions above were answered and since no follow-up questions came up there was obviously no open concerns. No need for release meeting decision then.
Accepted by 14 day rule.
--
KennethLavrsen - 09 Apr 2007