I just rolled this module out on a live site and it seems that somehow (on cron?) The PDF templates that we upload through the views interface (that get placed at sites/default/files/views_pdf) disappear/are deleted after some undetermined amount of time (may be related to cron). Have looked through the code and can't figure out where/how the views_pdf directory that holds the templates is created, and am wondering if this is getting reset somehow?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

hunziker’s picture

This is really interesting, because we do not implement the hook_cron() in the Views PDF module. Additionally we have no delete method implemented for the template files, this means we have no UI / API implemented to delete any files.

Can you tell me a way how I can reproduce this? Is it possible that you can tell me what other modules you have activated in the environment?

FatherShawn’s picture

@Kyle Jaster: Any light shed on this via complaints in the logs for protecting the directory via permissions?

kylejaster’s picture

@FatherShawn - unfortunately nothing listed in logs...

kylejaster’s picture

Ok - we've noticed that this appears to be happening when the view is part of a feature and the feature's views get reverted. Everytime a feature with a views_pdf view is reverted the sites/mysite/files/views_pdf_templates directory gets emptied.

hunziker’s picture

This is really interesting. Is this a misbehavior or not? Should we fix something here or is it convenient?

Griso81’s picture

Version: 6.x-1.0-beta2 » 6.x-1.0

Subscribe, I have the same problem. After a PDF is generate via a triggered Rule the template gets deleted from the templates directory.

Bouke’s picture

Subscribe

hunziker’s picture

I can't reproduce this bug. Is it possible that someone can give more information about how this happened?

@Griso81: Is it really the "views_pdf_rules_action_save" action? Because there I don't invoke any delete method.

kylejaster’s picture

@hunziker - this is definitely amisbehavior, not convenient.

it looks like anytime a cache is cleared, or features are reverted etc.. the directory gets re-created - no idea how, but after looking through the code in views_pdf i'm not seeing how the directory is created in the first place? i imagine all that is needed would be a check to see if the directory already exists...

splash112’s picture

Same problem here, don't think it is because of the triggered Rule.
Cache clearing could be a problem, but not sure how.

But is this the right place anyway to store a file? Think using the file system in Drupal with the files stored in the /files/ directory (or subdirectory) would be much better?

Thanks
Mark

Griso81’s picture

Hi and sorry for delay but holidays couldn't wait :)

I've been trying to reproduce the problem, but did not manage. The only hint I have is that the problem occurred while I was having php timeout problems for other reasons, but I'm not sure this is related...

velpan’s picture

same problem.
I found a solution by changing the permission rights of "views_pdf_templates" folder, after the uploading of a template.

File: views_pdf_plugin_display.inc
Line: 514

        if (!is_dir($dir)) {
          @mkdir($dir);
        }
        
	@chmod($dir, 0775);  // give the rights back, to upload new templates
		 
        if (is_writable($dir)) {
          $template_path = file_create_path($dir);
          $file = file_save_upload('template_file', array(), $template_path);
	  @chmod($dir, 0555); // lock the writing rights
        }
                
        break;
File: views_pdf_plugin_row_fields.inc
Line: 353

   if (!is_dir($dir)) {
      @mkdir($dir);
    }
	
    @chmod($dir, 0775);
            
    if (is_writable($dir)) {
      $template_path = file_create_path($dir);
      // The file field is not called "template_file" as expected, it calls
      // "row_options". The reason for that is not clear.
      $file = file_save_upload('row_options', array(), $template_path);
	  @chmod($dir, 0555);

      if ($file) {
        $form_state['values']['row_options']['template'] = $file->destination;
      }
    }
kylejaster’s picture

any chance we can get this in the next release?

FatherShawn’s picture

It looks to me like #12 fixes the symptom, not the problem. Both of these code blocks properly use file_save_upload() to upload the file. But, as http://api.drupal.org/api/drupal/includes--file.inc/function/file_save_u... notes

The source file is validated as a proper upload and handled as such. The file will be added to the files table as a temporary file. Temporary files are periodically cleaned. To make the file permanent file call file_set_status() to change its status.

A search on this modules code base does not find a call to file_set_status() anywhere, so whenever Drupal does garbage collection, this template file is purged from the files table and deleted from the file system. The attached patch adds this call below both lines referenced in #12.

kylejaster’s picture

Nicely done FatherShawn!

We've tested this and it appears to be working.

flipolopo’s picture

Drupal 6:
file_set_status(&$file, FILE_STATUS_PERMANENT);

Drupal 7:
$file->status |= FILE_STATUS_PERMANENT;

FatherShawn’s picture

Status: Active » Reviewed & tested by the community

@flipolopo True, the file is an object in d7 and so the property is set as you stated. A file_save() would also be required as noted http://api.drupal.org/api/drupal/includes--file.inc/function/file_save/7

Note however that this issue does relate to the 6x-1.0 branch. Setting this to RTBC per @Kyle Jaster testing...

FatherShawn’s picture

Has this patch been committed?

splash112’s picture

As soon a s I patched the 1.0 version downloaded from the project page, I got the error:

"warning: Attempt to assign property of non-object in /home/dinilu/public_html/drupal6/includes/file.inc on line 840."

Hope it still works

FatherShawn’s picture

@splash112 - I'll have a look and reroll the patch as needed...

splash112’s picture

The patch applied perfectly to the 1.0 downloaded from the project page. The error came later. Maybe because before I used a dev version that's now nowhere to be found...?

Also, all new PDF's have now very bold letters, old ones are still the same. Will try to delete some files and upload a fresh version.

Thanks
Mark

maikeru’s picture

I'm using 1.0, and received the same error as #19 after saving the view with a new template.

It seems to appear if you select 'none' as your template and hit save on the view.

Shouldn't the file_set_status call be within an if statement to check if a $file was uploaded? (Changing to the below removes the error, and should still make it permanent)

 if ($file) {
            file_set_status(&$file, FILE_STATUS_PERMANENT);
          }
FatherShawn’s picture

Priority: Normal » Critical
Status: Reviewed & tested by the community » Needs review
FileSize
565 bytes

Setting this back to needs review as I added a conditional to check that a file object is returned. This fix is committed to the D7 branch via #1362058: 7.x patch for views_pdf templates disappearing from directory needed but is still not commited to the D6 branch. I've used the same conditional as the D7 branch for consistency.

alibama’s picture

patched successfully against the dev version - have uploaded a file will know in a few hours - thanks for the help with this - great module

for anyone too lazy to patch there's a link to the patched dev version at the top of this page

http://blog.hsl.virginia.edu/drupalpress/views-pdf-vbo-rule-sets-thousands-of-custom-forms/

alibama’s picture

confirm this patch fixes the deletion = merci to all

jawad.shah’s picture

Great work!

Reference #14 :
This patch is also working for me. Thanks FatherShawn .

Nor4a’s picture

Yap - #14 fixes the issue!
Thanks!

Simon Georges’s picture

Status: Needs review » Fixed

Committed, thanks!

Status: Fixed » Closed (fixed)

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