Description

Attached files in a document are getting improperly embedded into the page, even when their mime type should prevent it.

Steps to reproduce

  1. Upload a file attachment whose mime type should not support embedding (e.g. a Word doc file).
  2. Place a link to the attached file in page.

Example

Test-Word.doc

Component selection

I am not big on Python, but I am guessing it is somewhere in either of:

Details

If you follow the link for the attachment you get the error:

The symptoms are demonstrated in This Wiki.

Workaround

Discussion

Hi, the file is not embedded here too. The error message is currently not quite helpful to get the reason. It is changed in 1.7. You have to setup mimetypes_embed and you need a browser plugin to embed a doc file too, see HelpOnConfiguration.

embedding means it is shown as object readable in a page. If this is not possible you can download the file or do view it by an external program.

An example how it looks like for pdf you can get at http://test17.moinmo.in/ReimarBauer

-- ReimarBauer 2008-05-06 17:12:24

That's an explaination from the mailing list by ThomasWaldmann

That's intended, not a bug.

Pages and attachments will be unified to "items with a mimetype".

E.g. a wiki page could be a item of type text/x-moin-wiki that contains some raw wiki markup.

If you link to that page (that item) and click on the link, you will get a rendered view of that item (currently called "action=show" [default]).

Note: It won't download the raw wiki markup into your browser or onto your hard disk.

The same is true for attachments now: by default, you get a "rendered" view of them if you just link to them and follow the link, not a direct download of the item.

Currently that view is rather simple (just the download link + a view of the item below), but for the future I see some more enhanced renderers, showing some metadata in this rendered view, so it will be more useful than now with just the old AttachFile code.

Also, that [[attachment:foo.txt]] markup will get (automatically) converted to just [[/foo.txt]] (a sub-item of the current one, like attachments currently being stored logically below a page) as soon as we have the new storage backend that is capable of storing mimetype objects.

As you see, there is no "attachment:" any more after that change, so we won't be easily able to create a different link.

Of course you still can do something like [[target|label|special params]] then, there is just no "attachment magic" any more.

A side effect of this change will be that "attachment file names" move to PATH_INFO, e.g. http://server/WikiPage/file.png and this will fix the annoyance of non-ascii character handling (we can't currently do it so that it works for any browser). We maybe will have this URL change in advance as it is not dependent on the backend change (but it makes even more sense WITH it).

If you do want a download link you can write [[attachment:Test-Word.doc||&do=get]] e.g. Test-Word.doc

But this does not work if you want to use linktext - '[[attachment:Test-Word.doc||&do=get|Test Word File]]' e.g. [[attachment:Test-Word.doc||&do=get|Test Word File]].

Plan


CategoryMoinMoinNoBug

MoinMoin: MoinMoinBugs/AttachedFilesEmbeddedIncorrectly (last edited 2008-07-11 07:44:35 by ThomasWaldmann)