The distribution wizard mentioned my custom template in the touched pages:
Here’s the changes
The template is really simple - and probably not so well written: I added two images (logos) to the template, then use velocity to use one of them in the header.
This is the header correctly generated on .13:
this is the same page / template / etc, after upgrading to .18:
Did I miss some upgrade notice?
This is the template header part code:
{{velocity}}
{{html clean="false"}}
<div style="height: 105px; width: 100%;">
<img style="width: 36.9%; margin-left: -70px; float: left;"
src="$doc.getAttachmentURL('logo.jpg')" />
</div>
## #if ("$!request.jobId" != '' && $services.job.getJobStatus($request.jobId.split('/')).request.isWithTitle())
## ## The title is extracted from the rendered content.
## <span class="pdf-chapter-name"></span>
## #else
## $escapetool.xml($tdoc.plainTitle)
## #end
{{/html}}
{{/velocity}}
This is expected because we added a new property (metadata) to the PDF template class (see Loading... ), so your template was modified to add the missing property (with an empty value). But this shouldn’t have any effect on the PDF output. The default PDF template has an empty metadata field, same as your template. And the rest of the fields from your custom PDF template were not supposed to be modified by the distribution wizard. You should be able to confirm this by comparing the versions 3.44 and 4.1 of your template.
No.
I don’t see anything wrong with this, so you’ll have to debug to understand the problem. Here’s what I would do:
try putting a simple plain text in the header to see if it gets displayed
check that the logo.jpg image is still attached to the template
output $doc.getAttachmentURL('logo.jpg') from the header to see its value, maybe the generated URL is wrong for some reason
debug directly the print preview by:
switch to User Browser (PDF) generator from the administration, if you’re not using it already
open the page to export
open the DOM inspector
export the page to PDF
check the iframe added at the end of BODY and open its source URL in a new browser tab
Wow! This must me mentioned in the PDF Application extension page: I spent hours with trial and errors to correctly place the logo with CSS positioning
Almost: it looks like $doc.getAttachmentURL() is outputting a path based no more on the template page (where the logo is attached to), but based on the document being exported.
In fact, If I open the template page, I see the attachment rendered:
$doc / $tdoc is supposed to be the document on which you trigger the export, not the template document. Check the cover field which uses $tdoc (i.e. “translated” $doc) to display information such as title, version and author of the exported page. It wouldn’t display the right information if $tdoc was the template document. The cover and the header fields are rendered in the same way (nothing has changed here). Maybe there was a bug in 14.10.13, but in any case you shouldn’t expect $doc / $tdoc to be the template document. There’s no binding for the template document, but you can access it with $xwiki.getDocument('My.Template').
Ok. If I understand that, it means I have to enter the whole page reference (absolute path) when calling getAttachmentURL() or getDocument(), reference that will break if I move the template page under another wiki path, right?
Asking just to be sure, I’m fine with it - moreover it’s the first time I try to write some velocity code.
Yes. Now, you can probably omit the wiki part of the reference if the pages you export are on the same wiki as the template, but you need to specify the full space reference (besides the template page name).
