This is mind bogglingly frustrating. I'm working with Views_Send and have made a few modifications to great success and one glaring failure.

My issue is simple: The attachments field will not allow me to attach docx, complaining the extension is not allowed. Easy enough to fix, riiiiight?

Here's the form_alter code behind the attachment field as per my feature module:

  if ($form_state['step'] == 'views_send_config_form') {
    $supported_extensions = array('doc docx pdf odt rtf ppt pptx');
    $form['mail']['views_send_attachments'] = array(
        '#type' => 'file',
        '#upload_validators' => array(
          'file_validate_extensions' => array('docx jpg jpeg gif png txt doc xls pdf ppt pps odt ods odp'),
          ),
        '#name' => 'files[]',
        '#title' => t('Select Attachments'),
        '#description' => t('The attached files are stored once per recipient in the database if you aren\'t sending the message directly.  I am overriding.'),
        '#attributes' => array('multiple' => 'multiple')
      );
  }

That isn't working. I cannot upload any docx files. I can upload any of the aforementioned files, so multiple doc files is no problem.

In an effort to circumvent the issue, I decided I'd add the extensions to the views_send.module file_save_upload function.

      if (VIEWS_SEND_MIMEMAIL && user_access('attachments with views_send') && !empty($_FILES['files']['tmp_name']) && is_array($_FILES['files']['tmp_name'])) {
        $dir = file_default_scheme() . '://views_send_attachments';
        file_prepare_directory($dir, FILE_CREATE_DIRECTORY);
        
        $extensions = !empty($form['mail']['views_send_attachments']['#upload_validators']['file_validate_extensions']) ? $form['mail']['views_send_attachments']['#upload_validators']['file_validate_extensions'] : array();
        
        foreach ($_FILES['files']['tmp_name'] as $i => $upload) {
          // attempt to save the uploaded file
          
          $file = file_save_upload($i, $extensions, $dir);
          // set error if file was not uploaded
          if (!$file) {
            //form_set_error('views_send_attachment', 'Error uploading file.');
          }
          else {
            // set files to form_state, to process when form is submitted
            // @todo: when we add a multifile formfield then loop through to add each file to attachments array
            $form_state['configuration']['views_send_attachments'][] = (array)$file;
          }
        }
      }

This garnered me nothing. The field still won't accept .docx

According to the API, file_save_upload will accept any extension if it is given a blank array. By default, this is what the views_send.module code does.

You can review the code behind the module here:
http://cgit.drupalcode.org/views_send/tree/views_send.module?h=7.x-1.x&i...

In short, I have spent two hours now trying various tricks to get the extensions accepted by the system and nothing is playing ball.

Any insight would be greatly appreciated.

Comments

VM’s picture

the question posted is better suited to the 'module development and code questions' forum. Please edit the opening post and move it. Thank you.

mcdoolz’s picture

Well look at that! I moved the post and suddenly I solved my problem. Thanks for all your help, VMII.

Anyhow, if you've happened upon this and are wondering what to do, I solved my issue by coding my valid extensions in the proper form.

In using file_save_upload, I was providing:
array('docx jpg jpeg gif png txt doc xls pdf ppt pps odt ods odp')

It wanted:
array('file_validate_extensions' => array('docx jpg jpeg gif png txt doc xls pdf ppt pps odt ods odp'))

So there you have it. If you're hacking views_send and can't explain why the extensions are sucking your soul out of you, that's the trick right there. Hack the core module, and replace the file_save_upload as such:

$extensions = array('file_validate_extensions' => array('docx jpg jpeg gif png txt doc xls pdf ppt pps odt ods odp'));
$file = file_save_upload($i, $extensions, $dir);

For the record, it was this post that sent me down the right path.
https://www.drupal.org/node/2076659

-
Be the occasion.

Jaypan’s picture

Never hack a module.

mcdoolz’s picture

..without properly documenting your changes and keeping a patch for yourself in case of updates that will wipe out your changes.

FTFY.

-
Be the occasion.

Jaypan’s picture

Well, you could do that. And I actually have done that in the past, but it makes for a messy, hard to maintain system. There is almost always a way to override in Drupal, so that method should be the absolute last option.

WorldFallz’s picture

took the words right out of my mouth! In 8 years with drupal developing several highly complex custom web applications, i've yet to encounter a situation where I had to hack core or a module like this.

My carefully documented and version controlled patches have always fallen into 2 categories:

  1. bug fix -- temporary by its nature, and I participate in the issue and reroll as necessary until it's been fixed properly. Even to the point of taking over or becoming co-maintainer of the module in question when necessary.
  2. enhancement -- also temporary, and I work to ensure it gets included in the module eventually.

I'm a one person band atm, so I don't have the bandwidth to service messy hard to maintain systems. It's totally self preservation for me, lol. Personally, if #2 ends up in a dead end, I opt to rewrite whatever it is into my custom module rather than try and keep up with a hacked module.