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
=-=
the question posted is better suited to the 'module development and code questions' forum. Please edit the opening post and move it.Thank you.Well look at that! I moved
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:
For the record, it was this post that sent me down the right path.
https://www.drupal.org/node/2076659
-
Be the occasion.
Never hack a module.
Never hack a module.
..without properly
..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.
Well, you could do that. And
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.
_
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:
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.