Hi there,
I try to give a pdf via token the sitename as filename. This is actually not working in my case. It get's only the path name as name. My PDF is created out of a view. Could that be the reason?
Is the token based naming only working for single nodes?

Cheers Apfel007

Comments

Apfel007’s picture

any hints?

jcnventura’s picture

Component: Code » Documentation

Yes. The token_replace() function only allows further tokens, if there's a type. In this case, I use the node type.

It should still work for the sitename when it's not a node however... I'll need to investigate further.

siliconmeadow’s picture

Component: Documentation » Code

I wonder if this is a related problem to one that I now have. Let me explain, and if necessary I can open a separate issue.

  1. I'm using wkhtmltopdf;
  2. printing a book with the full hierarchy uses the path e.g. printpdf/book/export/html/55437 to generate the filename (book_export_html_55437.pdf), instead of using the tokens specified in the form at /admin/settings/print/pdf in the edit-print-pdf-filename field. In essence, it's using the defaults;
  3. I've created another test site with the bare minimum of modules, devel generate to stick dummy content in, and am using Garland. The same results appear between versions 1.12 and 1.13 - the token generated filenames are honoured in 1.12, but files produced using 1.13 of the module cause the files to be named with the default naming convention;
  4. the problem appeared on tagged releases after 6.x-1.12. I've not looked at the commits between 1.12 and 1.13. I've tried 1.13, 1.15, 1.16 and 1.x-dev as at commit f314ae0cc94f333083a80e76ca182aa6046df398 (Thu Apr 19 01:31:52 2012 +0200).

I've spent some time with Netbeans stepping through the code but I can't seem to see when $pdf_filename is generated and the token module is ignored. I'll continue looking but any advice would be gratefully received.

Cheers,

Richard

jcnventura’s picture

Component: Documentation » Code
Status: Active » Fixed

I've committed to dev a fix that tries to use the global tokens when it's not a node.. However, if the filename template uses node-specific tokens, it will still fallback on the path-based filename.

@Apfel007: Indeed, when it's not a node, it didn't even try to use non-node tokens..

@siliconmeadow: the change betwen 6.x-1.12 and 6.x-1.13 was introduced by the backport of the fix for #1235842: Notice: Undefined variable: node in print_pdf_controller(). This is actually a good fix, as a node was being passed to token_replace when there was no node..

siliconmeadow’s picture

Thanks jcventura. Today I'll give it a spin. I'd like to be able to have selections for different file name conventions for different node types, in the way pathauto works. Sounds like topic branch for me to work on. I hope I can contribute something back from it soon. I suspect I may also have to do something about paths like 'printpdf/book/export/html/55437'?

Do you ever use the 'Needs review' status?

jcnventura’s picture

Yes, I love the needs review.. It's my list of user-contrib patches to look at.. And 'needs work' is those that I already looked at, and could be improved. RTBC is the complicated one, it's used so rarely, that I forget patches placed there :)

The book/export/html path is using the book module's hierarchy-expansion routines. That one actually has a node (the point of origin of the book traversal), so you shouldn't need to do anything there.

If you're going to work on that, leave this issue as is, and provide a patch in #377550: Default PDF Filenames by Type?

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.