Cache PDF file in server

No. What you're referring would be to develop some kind of 'cache' of PDF files. This could be done, but it would require tracking the revision date of the node and the date of generation of the latest PDF, to invalidate the 'cached' copy in case there has been any changes to the node since the last time that the PDF was generated.

This would save some seconds of PDF generation time, but would waste a lot of space in the hard disk. Since in most situations the only limit is the hard disk space, this feature is probably not useful to the vast majority.

Makes a lot of sense to me, Super G. Not a 'cache', but an archive of snapshots, in PDF, in parallel to the DB contents generating the nodes, which is dynamic and inherently lacks snapshots in the typical hostnig MySQL situation. I agree with you: disk space is cheap and responsive relative to server CPU in the typical shared hosting evironment, particularly with Drupal which is so DB query intensive.

Well, every site is different. For me, server performance and reliability is paramount, and I have a lot of disk space, so I'm going with the "save all nodes as PDF" approach. I wrote a small custom module triggers a "generate PDF" action when a node is saved. Right now, the module is specific to my site, but if someone wants to help me make it worthy of being listed on drupal.org, drop me a line.

Hi SuperG. I am interested in this small module which trigger the generation of PDF when the node is saved. I am currently implementing a site where the content is mostly static, eventually it should be possible to modify your trigger such that it will allow an administrattor to request the generation of PDF for specific node types. If you can share your module I will look into extending it to allow generation of content "by request" of administrator (or other user with sufficient permission rights).

No.. I'm not a baby but I'm going to act like one on this issue, because you are and you need to learn some manners.

Understand two things:

1. You're using software for FREE that is designed by me in my free time.
2. I decide what I do in my free time.

So, if you want this one, this feature now costs you 5000€ (five K euros). Normally, I'm willing to accept patches that other people do and keep on maintaining those for free. In this one case, even if that happens, I won't accept it. You can, of course, fork the module, and keep on maintaining it yourself.. It would actually create more free time for me, so I would welcome it.

João

Thanks for clearing it up.. Yes, it really annoyed me at the time, as the phrase only made sense to me as an insult.

The main reason why I don't provide such an option is not that I am fundamentally against it, as I think it would be extremely useful and increase performance in sites that use the PDF functionality. It's the lack of time to do it, and the fact no-one has done it for me. Of course, if someone did sponsor this it would probably move up in the list of stuff to do in my free time :)

It's easy to add a node API hook and have the module create a PDF file each time the module is edited/created. Doing that however, would slow down the node creation/editing process that in extreme cases it may lead to PHP timeouts with unknown consequences (the worst being loss of the node contents). Also, Some kind of interface must be provided to enable the user to re-create all the nodes when a newer/better version of the PDF tool is released. So, on this option, the best would be to use the Job Queue to schedule the creation of these PDFs during the next cron run (of course, if a user were to ask for the PDF before the cron execution, then he would get a delay, and the cron job would now be irrelevant).

As this could eventually lead to several gigabytes of wasted space on the server, I would prefer the cache option, whereas the first user to access a PDF would get the delay, but all the others would just download the cached copy... This would allow the PDF 'store' to be configurable and all the usuallly-used PDFs would be instantly available. The problem with this is that handling a file cache is something that would probably benefit from a third-party module, but the one available (http://drupal.org/project/fastpath_fscache) doesn't seem to be actively maintained on a regular basis, and is used by almost no-one.

João

Subscribing. Thanks

I read a couple of threads about the caching issue and all point to this thread now. Has there been any progress on the caching of PDF files? João mentioned in some of the other issues that Drupal cannot handle delivery of cached PDF files. Is that still the case or might core updates have fixed this?

I can see this as a very useful feature, but I do see the performance concerns as well. In my case I only want very few PDFs to be cached, not all of them. I created a view to pull together various pages (like a print basket) which then can be printed into one PDF file. It works fine, but the delay while the PDF is created is a concern. The link to the PDF version is send out in an email, recipients click on it and see the PDF (instead of individual pages with a print to PDF button on it). The few seconds it takes to load might signal to them that the page is not working correctly and they might close the tab/browser. Ideally, I would be able to cache this file to inprove the load time, but I am not concerned about all the other pages that do not need cached versions and work just fine with generation on the fly.

It seems that various people were interested in variations of the caching option. Should we set a different status and see if this can be moved forward?

Thanks, J.

@Super G,

Hi,

I am interested in your module that could expand print.module; "a module you wrote to save a PDF output to a file on the server instead of saving it to the visitor's computer."

Could you upload it, so we could try to add it to print.module ?

Thank you

Leon

@chipway-drupal: thank you. In D7, I changed your lines (in print_pdf.pages.inc) as follow:

so that PDFs are saved to specified folders, that can be deleted at user deletion (Rules can create such folders upon the first login of a new user, and then delete them upon user deletion - at least this is the way I'm doing it, but please point me to a more functional method if this one is naif).

PS. If anybody is interested... I'm writing the generated PDFs to these /sites/default/files/fileviewer/[user-ID]/ folders because I'm using Fileviewer to have PDFs rendered in an html5 PDF viewer - instead of having them immediately available for direct download, or to screen. To explain further: I imagined that the PDF version of a node has to be stored and rewritten both by Print and Fileviewer in a "shared" folder (the mentioned /sites/default/files/fileviewer/[user-ID]/ folder), so that Fileviewer is able to always load the right PDF (there is always only one available) and convert it to PNGs, for direct HTML5 rendering. This way, no third party software i.e. Adobe Acrobat or Flash is needed to access a beautifully readable PDF document made in Drupal.

At the moment I am using File Field Sources to manually load the stored PDF to be rendered in the PDF viewer (we are always talking about a single PDF per node), at node save... but the idea is to have Rules doing this job, at node save (I don't know if this is possible... it should be matter of controlling fields content at node save - but point me, possibly).

And I would like to say hello to jcnventura: many thanks for your time!

Oh, I didn´t realize that #18 seems to be applicable to 6.x :)

But I dont get one thing, those lines shouldn´t be added to the .module file?
And how can I tell in wich nodetypes is this applicable?
Thanks!

This is what I have now:

I´ve installed (and I´m using to generate the pdf´s): wkhtmltopdf-0.9.9-static-i386.tar
I´m using 6.x-1.12 version of Print.

bump?