~~ODT~~ markup in a Bootstrap3 template hook

[fts-tmassey]

Hello!

With a Bootstrap3 template, the simplest way to add the ODT export icon on each page seemed to be to simply add the "ODT" markup to the the :pageheader document that Bootstrap3 will display on every page. Unfortunately, when you do, it creates a URL that will only export the :pageheader page -- not the actual page that is being displayed!

Is there a way to resolve this (without something like embedding raw HTML or PHP)?

In the interim I've used the pageheader.html hook instead, but I prefer where it goes on the page better when using the embedded markup -- and I'll always choose markup I can modify from my browser than HTML in a configuration file! :)

Thank you very much!

[lpaulsen93]

Don't you see the export icon if you just enable the ODT config option plugin»odt»showexportbutton? It seems to work fine for me.

[fts-tmassey]

Sure: in the logged-in-user bar on the right. I'm not sure what relevance that has for wanting an ODT export icon on the page itself? For example, so non-logged-in users can do so, too?

Just to make it clear: the ODT markup does appear, even with the Bootstrap3 template. The problem is trying to use the markup inside of a page that is automatically included via template hook on every page: the URL that's generated points to the included page only, not the page that it's included into.

And the reason I want that is: I like where it goes on the page, it's WAY more visible than the tiny icon in the far-right logged-in bar, and my entire reason for using this is for people who are not logged in (and therefore don't have the bar in the first place). Hard-coding stuff into an included HTML file works, but I prefer the visibility and maintainability of using the markup hooks we are already using.

Plus it would allow me to easily control which namespaces have the icon, which would be greatly preferred to having it on each and every page.

[lpaulsen93]

I had a look at this and unfortunately it cannot be implemented as you want in the ODT plugin.

The reason is that the pageheader hook of the bootstrap3 plugin is rendered like a single page. So the ODT export link includes the page name pageheader. After that the "real" page is rendered but the ODT plugin will never see it's name. The real page name is not known at the time that the export link is being created.

[fts-tmassey]

Thanks for the update. What you say makes sense: I figured it was something along those lines. I just hoped there was some sort of PHP call that could’ve been made that would give you, maybe, the original URL that was requested or such where the information could be gotten from there.

I wonder if there would be any advantage to open a ticket with the bootstrap3 plugin to provide that information somehow?

[lpaulsen93]

I wonder if there would be any advantage to open a ticket with the bootstrap3 plugin to provide that information somehow?

Well, it could maybe be implemented in collaboration of the two plugins:

The bootstrap3 plugin would need to provide a global variable containing the real page name (the main page or root page - however you want to call it). The current page name is stored in the global PHP variable $ID. But as mentioned in your scenario it is set to pageheader on rendering of the pageheader content. If bootstrap3 would provide something like a global variable $ROOT_ID which stores the original page name then the ODT plugin could use that. If the variable is empty it could use the "normal" $ID so it hopefully does not break compatibility to all other templates.

Just an idea. Maybe you can communicate that to the bootstrap3 author and see what he thinks about it.

[Klap-in]

I would prefer a variable mentioned $pageID (or $articleID). root sounds for me more as the first in the file hierarchy.

This looks like that the following pull request will be helpful in the future: dokuwiki/dokuwiki#3267, it isn't?

[lpaulsen93]

This looks like that the following pull request will be helpful in the future: dokuwiki/dokuwiki#3267, it isn't?

Could be. Would need testing to see if it solves this issue and if it works fine for export renderers (no XHTML renderers).