Is there any way of checking if the file exists in the file system prior to creating a new file?

The PHP / JavaBridge seems like a hungry resource on smaller servers.

Basically it would look like this:

  1. Request comes in for the file
  2. Server checks to see if the file exists
  3. If the file exists, serve it from there

  4. If the node is updated, delete the corresponding file so it can be re-created on the next request

This way, for sites with very static content, the file will always be served from cache.

Deleting the file on node_save also saves checking timestamps from the file vs node creation date.

This is just an idea to reduce server load and have the files served faster. I am not a programmer, so I would not know where to start.

P.S. we have this running on our site currently and id does do an awesome job!! Thanks for the module.

Comments

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented
Version: 7.x-1.9 » 7.x-2.x-dev

Good feature request. Fixing version (new features are against 7.x-2.x).

Yeah, Tomcat + JavaBridge + FillPDF Service is pretty resource-heavy. I've been thinking of trying to get things working on a smaller application server. I think Jetty is supposed to be the one.

One problem is knowing what "the file" is. Every file would need a unique name, and FillPDF would have to keep track of the files — I guess based on the arguments to it, judging from your post ("if the node is updated...")

P.S. Thanks!

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented

Oh yeah, one other concern is privacy. Currently, generated files aren't saved unless you explicitly save them to a file path. If someone broke into your server and you were only serving the files via download, the attacker wouldn't find anything. With this, we'd have to leave the files in place. But I don't think there's a way around that.

timpiche’s picture

timpiche commented

The file name would have to be based on the custom filename option i.e [node-title]-[site-name].pdf

This is also something you could look to rules for. I beleive some of the work is already done. I have been looking at a way to do this with rules with some php snippets. I will let you know if I fond a way.

Tim

timpiche’s picture

timpiche commented

If security is a concern, this could be done with an htaccess file inside the directory.

you could allow localhost to serve the files and deny from everywhere else.

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented

Yeah, private file system I guess you mean. I meant if an attacker actually got into the server. It's nothing new from saving files to a path, though. It was more a comment than anything.

OK, let me know how it goes.

timpiche’s picture

timpiche commented

Is there spot in the code I could do something like this before the pdf is handled:

if (file_exists($destination_path,$file)) {
drupal_goto($destination_path,$file);
} else {....}

I dont know what function it would be best to place this code in.

I could then use rules to delete the saved pdf file when updating the node.

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented

Well, either you'd need to track the filled filenames in the DB (a new table, probably) or you'd have to name them sufficiently uniquely that you could be sure it was the same one. You might be able to do that with a subdirectory structure, since that doesn't affect the end file name.

Then if it exists (probably make a function to check based on the node or Webform parameters), you delete the file on hook_node_update() (assuming it's a node, not a Webform).

That's the general logic.

liam morland’s picture

liam morland
Primary language English
Location Ontario, CA 🇨🇦
commented
Version: 7.x-2.x-dev » 8.x-4.x-dev
Issue summary: View changes
wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented
Status: Active » Closed (outdated)

We implemented private file support, and I think that's enough for someone who's interested to look into more caching.