I can't upload .pdf files in resources

[NeilEccles]

Hi there please help

Since the last major upgrade, I have not been able to upload .pdf files in resources.

I have checked the Options and my file extension list which includes a whole list including pdf has not changed.

Might this be a bug perhaps?

Sorry to trouble

Kindest

Neil

 

[ForumFlex]

what was the error message when you upload it?

 

[Mike]

I assume you mean upgrading from 2.0. Nothing significant has changed here in the RM with 2.1.

Note that the RM has a separate list of allowed extensions: "Allowed resource file extensions" Make sure pdf is listed there. Otherwise, we'd need more details on what's happening when you try to upload one.

 

[taydin]

Having same problem with XFRM version 2.1.1. The list in the allowed extensions includes PDF, but I can't upload PDF's.

When I press attach files button, the list of allowed extensions is fixed to jpg, jpeg, jpe, gif, png. No matter what I enter in the resource manager configuration, the file upload dialog only lists the above as the allowed extensions. And when I upload a PDF anyway, XF complains that an uncompatible file has been uploaded and only offers me to delete it.

I think the problem is that XFRM completely disregards the configuration and has a hardcoded list of extensions that it accepts. Let me know what extra information I can provide.

 

[taydin]

With my limited (read: almost non-existent) PHP knowledge (I'm a C/C++ guy), I have sniffed around the source code and made the following change in ResourceUpdate.php:getConstraints()

Change this:
$constraints['extensions'] = ['jpg', 'jpeg', 'jpe', 'png', 'gif'];
to this:
$constraints['extensions'] = ['pdf', 'jpg', 'jpeg', 'jpe', 'png', 'gif'];

Now it offers PDF as one of the allowed extensions. But now, it complains that the file size is too large. The file size is about 3000 KBytes, and I have configured maximum resource file size to 8192 KBytes. Hmm, so it looks like XFRM doesn't even read the maximum file size configuration, and uses it's internal default, which I suppose is 2048 KBytes.

 

[Snog]

With my limited (read: almost non-existent) PHP knowledge (I'm a C/C++ guy), I have sniffed around the source code and made the following change in ResourceUpdate.php:getConstraints()

Change this:
$constraints['extensions'] = ['jpg', 'jpeg', 'jpe', 'png', 'gif'];
to this:
$constraints['extensions'] = ['pdf', 'jpg', 'jpeg', 'jpe', 'png', 'gif'];

Now it offers PDF as one of the allowed extensions. But now, it complains that the file size is too large. The file size is about 3000 KBytes, and I have configured maximum resource file size to 8192 KBytes. Hmm, so it looks like XFRM doesn't even read the maximum file size configuration, and uses it's internal default, which I suppose is 2048 KBytes.

There are two different constraints in the Resource Manager.

The first is for the resource itself which is defined in the Resource manager options. It's for the one where you create or update a resource and you're asked for the file name to upload.

The second is for attachments to the resource description. And I believe those are intentionally limited to images since the description should not contain the actual resource file.

However, there is a bit of a discrepancy in the the RM code for handling the attachments to the resource description.

$constraints = $attachRepo->getDefaultAttachmentConstraints();
$constraints['extensions'] = ['jpg', 'jpeg', 'jpe', 'png', 'gif'];

The first line loads the default attachment constraints for a message. And the second line immediately overwrites those values, limiting them to images.

EDIT: After looking closer at it, it's not a discrepancy. It's an intentional limiting to images in the resource description, but retaining the other settings for attachments in the description (size, width, etc.).

 

[taydin]

Hmm OK, I see now ... I was trying to attach the RESOURCE FILE itself as an attachment to the description. I guess the right way is to choose the correct resource first, and at that point, keep adding files. And this works.

Oh well, sorry for the noise