Snippets do not function in PDF content type

[pyrographics]

Summary

When you have a snippet that generates PDF content, the resource must be set to HTML content type and not PDF or the snippet will not execute.

Step to reproduce

Create a snippet that outputs pdf document, create a resource set to PDF content type, place the snippet in the resource, save, view it in your browser.

Observed behavior

Snippet call will be displayed in PDF instead of snippet output. (have to change file extension from PDF to text to view output)

Expected behavior

Snippet output will be displayed in PDF instead of snippet call.

Environment

MODX 2.6.1, reproducable on MODX Cloud environment and cPanel LAMP.

[Bruno17]

generating pdf - content within a snippet doesn't work. This has to be done with a plugin. See, how PDFresource does it https://github.com/Jako/PDFResource/blob/master/core/components/pdfresource/model/pdfresource/events/pdfresourceonwebpageprerender.class.php

or maybe, you just could use pdfResource?

[pyrographics]

I do it currently with TCPDF and a snippet but the snippet has to be HTML content type and the snippet return set to download instead of inline. Inline content would work if the snippet would function with a PDF content type as it does with an HTML content type.

Susan asked if it was set to binary. I checked, the pdf content type is binary.

PDFresource looks interesting, I'll have to try it out.

[sottwell]

From what I recall of my research into how static resources work, resources with a "binary" setting are shunted off to their own processor, which re-sets everything back to the beginning, then sets streaming headings and streams the file specified in the resource content. Now, I don't know if this does the same thing if it's not a static resource, but it sounds like it.

[wuuti]

I can confirm this behaviour, which was definetily not the case in earlier versions: if you have a resource with the only content [[!createPdf]] and the snippet creating the pdf data (e.g. mpdf), the snippet is not processed on content-type PDF, but on all other content types. Btw, it seems that changing the content type of PDF away from "binary" is not possible through the manager grid...

[Mark-H]

Try creating a new content type for pdf that is not set to be a binary, that way the content will be processed. I don't immediately recall that behavior having changed any time recently...

[intersel]

It seems to be a choice in modresponse.class.php (line ~61) that binary type doesn't process the resource

if (!$this->contentType->get('binary')) {
             $this->modx->resource->prepare();//not done when binary... if set before test... seems to go fine
...
else
...

Is there a reason why the "prepare" is not done for the binary type files? as when I put this line above the test... not really tested but it seems to be fine...