-
2012-10-26
ach
Anything using p_wiki_xhtml() (like tpl_include_page() which e.g. is used for the default sidebar) cannot pass on the $ID of the page it's rendering. That's why it's impossible to find out if something is being rendered in the main content or an included page.
Not sure what's the best way to solve this. Maybe introducing a global $curID?
-
2012-10-26
ach
I just realised that the $ID is actually working correctly in the sidebar. But in my case it was not working in output from the navi plugin (because it resets the $ID to $INFO['id']). So, for plugins it's still necessary to be able to distinguish between those two types.
-
2012-10-26
ach
I just fixed this in the navi plugin [https://github.com/cosmocode/navi/pull/7]. So, changes to the core don't seem to be necessary. But I still think it would be beneficial. So, I'll just change this from bug report to feature request.
-
2012-11-02
Michitux
I think it would be great to have exactly this information and also information like if the currently rendered text is a wiki page at all available in the renderer. I was wondering if we could extend the already existing $info array in the renderer with this information. It might also be possible to extend this in plugins in order to provide context information for other plugins, for example the include plugin could inform other plugins that they are in an included page so these plugins could adapt to this situation (currently the include plugin simply removes certain plugin instructions from included pages).
As you already noticed, $ID is the currently rendered page and also in the parser/handler this is in most cases correct (at least when parsing is triggered from the xhtml/metadata rendering, but this did already cause problems with the combination of the include and the discussion plugin, now the include plugin sets $ID before getting the instructions of a page).
This also concerns metadata rendering as metadata rendering can be triggered from many places.