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