Bug? Upload text file to folder, nothing there. Plone 5.1 rc 2

Plone 5.1rc2 (5109)

Uploading images like jpg is fine.
Folder_contents view, click "upload" select file(s)
Click on icon of uploaded file> Picture appears with standard Plone title, etc

Same sequence with a plain text file:
Folder_contents view, click "upload" select file(s)
Click on icon of uploaded file> nothing but the file name appears (w standard Plone chrome), no content is shown at all.
Indeed, apparently there's nothing there... I used a WebDAV connection to download the photos from the users, but the "txt" file had nothing in it but a bunch of Plone wrapper html.

The use case is for end-users to add a "manifest.txt" file for the images which they are uploading.
I don't want them to have to add a new page, etc, at this time, since there's already resistance to even using the site for uploading images (this will probably be the only time these users ever log in to this site)

What's up with this??? Is there a setting somewhere? Permission?
Even if I can't view or edit the file in Plone, I should be able to download it!?

Thanks for pointers!


Your file is not loaded as a file, but as a document. Since a document has no method for upload a file, it does not work. To work, your file has to be handled as .... a file.
After some research, I have found that the mapping of extensions to content type is handled in Plone by a little known database named 'content types registry'. AFAIK there is no UI to manage it (I'd be happy to be shown ignorant but I have searched docs and Internet for 2 good hours without success). I looked at the registry (no joy) and the ZMI (don't seem to be any way either).

Well... there is always the dirty way.

You can use it too if you are not afraid.

Fire up Plone in debug mode (bin/instance debug or something like that)

>>> plone=app.Plone
>>> from zope.component.hooks import setSite
>>> setSite(plone)
>>> plone.portal_registry.content_type_registry.predicates['ATDocument_ext'][0].extensions
['txt', 'stx', 'rst', 'rest', 'py']
>>> plone.portal_registry.content_type_registry.predicates['ATDocument_ext'][0].extensions=['stx', 'rst', 'rest', 'py']
>>> plone.portal_registry.content_type_registry.predicates['text']
(<MajorMinorPredicate at text>, 'Document')
>>> x=plone.portal_registry.content_type_registry.predicates['text'][0]
>>> x
<MajorMinorPredicate at text>
>>> plone.portal_registry.content_type_registry.predicates['text']=(x,'File')
>>> import transaction
>>> transaction.commit()

then exit the debug mode and restart Plone normally. Works for me (TM)

If you don't understand what this does, the txt extension is associated with an old Archetypes type, the first change removes the txt extension from it. Then the mimetype text/* is associated with 'Document'. the second change associates it with the 'File' content type.

If there is a bad side-effect your can revert the changes by doing the opposite.
Please post if you see a problem.

As of your question, is this a bug ?

IMO, having to fiddle extension associations to get proper handling of files is not really a bug, it is done in many other systems (Windows, browsers, etc...)

Not having an user friendly way to change these extension associations is not truly a bug, if this is correct I'd say that it is more an oversight.

1 Like

That's an interesting issue and IMO a bug.

The content_types_registry is mainly meant to handle filetype to contenttype conversion when uploading via WebDAV. When doing a file upload via the folder_contents I would expect to have an image OR a file created - and not the file converted to a content type.

@pfraterdeus - can you please file a bug report at https://github.com/plone/Products.CMFPlone/issues and mention me (I'm @thet on github)

@gp54321 there is a ui for managing these entries: just add "/content_type_registry/manage_predicates" to the URL at the root of your Plone site, e.g. http://localhost:8080/Plone/content_type_registry/manage_predicates . It's from the ZMI, the Zope Management Interface.

so that's why a Plone specific interface to the content type registry was never developed: it was deemed unnecessary, Webdav being as doomed as the Zmi itself. However the old code is still here and get in the way. That explains it, thanks.

WebDAV might not have a bright future in Zope due to recent changed in Zope itself. But IMO it could still be quite an argument for Plone if it would work better out of the box.

1 Like

Thanks @gp54321 thanks @thet!
I'll file an issue, sure enough.
In fact the only way I could find to download all the images collected in the folder was via WebDAV, and therefore, yes, very helpful that it's an option!
Although the images are stored as blobs, there's no real way to identify them in the filesystem!

Two references related to this issue:

Oh that AJ, so contrary :wink:
Did anything ever get resolved about this question?
It does seem a bit awkward in general, and I'm quite surprised that Plone by this time doesn't deal well with the upload of a simple text file .
I'd think two things should happen to this uploaded file.

First, a file uploaded should be able to be downloaded without contortions or having to open a WebDAV client.

Second, a simple text file should be correctly rendered as a content page (rich text, etc?), and an html file should be processed by safe-html and presented as a preview. A conversion option should make a new content object which would be editable (ie a Page) as usual, but I'd not expect that this would then be downloadable (except as TinyMCE might provide a 'save' option?)

Just my two cents. This functionality would be of great use to me.

First, a file uploaded should be able to be downloaded without contortions or having to open a WebDAV client.

once a file is uploaded, something you can achieve right now by:

  1. using the standard Add / File OR
  2. making the changes I showed but by using the ZMI tool to configure the types registry as explained by @thet instead of using my programmatic way - that will allow you to use the Contents view / Upload button as asked in your first post. It will be fixed in a future version (hopefully) in a different way without having to fiddle with extensions, but now it's the only possibility.

then you have a file that any user can download by pointing it, right click, save as, using any decent browser (I use only Firefox, YMMV)

A conversion option should make a new content object which would be editable (ie a Page) as usual

that would be an improvement, not a bugfix :slight_smile: . You don't have that in the Add.. File classic feature. Right now if you upload a file it will not be loaded in a Richedit - I don't think there is any by default in the File object and even if you add one it will not work, the default behavior would have to be changed.
The change I showed you and is intended to be done by @thet is only to have the same behavior in both cases (Add.. File and upload in content view)

Thanks very much for your suggestions I will look into it!
I'm not entirely clear on the correct entries or deletions which I'd have to do in
I'll do some more reading when I get a chance.
I assume that your code would have to become a step in the startup to make it 'permanent' against updates etc.

absolutely no code is needed; once you do the changes using manage_predicates they will be saved in the database (ZODB) forever, even if you upgrade Plone. manage_predicates will do the exact same changes I did by code, but it's easier and you don't have to stop Plone.
Basically you click in extensions in ATDocument_ext entry, delete the txt part, click Change, in the Text entry you use the list to pick the 'File' instead of 'Document', click Change. Should work.

Ah, great! I'm still wary of making changes I don't understand 'under the hood' :wink:
Thanks very much for the step-by-step, that's pretty much what I thought, but there's a lot of stuff there...

I had some users discover the same bug in 5.0.5, and I posted this to the CMFPlone issue tracker too. Pop quiz, did you know that it's actually saving the file to the Document's "file" attribute even though that is not one of its schema fields? And did you know you can link to this with "@@download/file" appended and this actually works? I have some users uploading Files that become Documents that behave like Files - yuck!

1 Like