Filenames with # in them do not open, instead the first file is displayed

[madsi1m]

Hi I have found a bug:

Clicking a file in the files browser called "test video #2.mp4" will open the mediaviewer on whatever the first file in the file list has eg:

file 1.mp4
file 2.mp4
file 3.mp4
test video #1.mp4
test video #2.mp4
video 1.mp4
video 2.mp4

Clicking one of the test video files with a # will always open "file 1.mp4" where it should open the video i clicked on. Strangely i can view the video from the mediaviewer slide show. See There is a bug in the file selection clicking stage rather than playback

[jancborchardt]

cc'ing myself on this. Also @tomneedham and @owncloud/designers

[tomneedham]

I need to do some research into how exactly you register to display files publicly in owncloud but I remember from discussions with @icewind1991 that the app needs to use a certain php file to open the file. However there are a couple of issue as we need the mtime and a couple of other custom details when opening a file. This is only for editing though, so maybe we can make this work for readonly.

[PVince81]

@tomneedham let me know how it goes. I think there is currently no good mechanism for the app to register itself and accessing the file needs to go through a different endpoint if I remember well. Ideally there should be only a single ajax mountpoint for accessing files, with only an extra "token" parameter, but we don't have this yet.

[MorrisJobke]

Maybe have a look at how this works for music: https://github.com/owncloud/music/pull/124/files These files could have changed until now: https://github.com/owncloud/music/blob/master/js/public/musicFilePlayer.js

I hope this helps also for this app.

[PVince81]

@tomneedham I think you could just go through the "download.php" by calling context.fileList.getDownloadUrl(file, dir) if we assume that the file is read-only in such cases.

From what I saw the editor is using a separate mountpoint because it is also handling mtime and change detection.

[PVince81]

See https://github.com/owncloud/music/blob/master/js/public/musicFilePlayer.js#L57 for an example from the music player.

[tomneedham]

True. For the public preview we don't need mtime. Where can I write this separate js to be called on the public page?

[PVince81]

I think you can detect the public page on OC7 by checking whether OCA.Sharing.PublicApp is defined. Or use the old school $('#isPublic').val().

So you'd add that code to editor.js.

Note that the action handlers from the action have that second argument that you can use as specified in the example.

[tomneedham]

So spent a bit of time on this. Moved the text editor over to the new OCA.Files.fileActions code.

However, there seems to be a bug in that image previews are always the default and it is not possible to override them because of this line: https://github.com/owncloud/core/blob/master/apps/files_sharing/templates/public.php#L59 and then an if statement that checks if that class exists: https://github.com/owncloud/core/blob/master/apps/files_sharing/js/public.js#L62

@georgehrke Apparently you might be able to help / offer hits here :)

[oparoz]

https://github.com/owncloud/core/issues/15652 implements a text preview of text files which are publicly shared. This can always be improved later by loading the content inside the text editor in read-only mode so that it looks better(, as in formatted).

[luckydonald]

From what I understand, the current solution is to display the first 1000 characters in a text div.

But now there is a preview api in the text editor, right? I think, the preview should be the preview on shared links as well. I would consider that as the expected result. That would also benefit plugins like the markdown plugin which are already implementing a neat preview in the editor.

(Not sure if I should open a new issue for this...)

Example screenshot:

left window shows the download page (shared link), on the right the preview pane of the editor (with markdown plugin).

[oparoz]

But now there is a preview api in the text editor, right?

Not from what I understand from that page. It's now possible to extend text_editor with more parsers, but there is no API to return a parsed preview of a file

[tomneedham]

It's now possible to extend text_editor with more parsers, but there is no API to return a parsed preview of a file

Correct. To get public viewing of files working we need to patch the editor to use the default endpoints for returning a file.

[luckydonald]

Not knowing the internals, but why do we need changes in the editor? Would we not only need the download page call the plugin's parser as well?

[tomneedham]

So right now the only way for 'preview' plugins on the public page to access files is for them to access the file in question using context.fileList.getDownloadUrl(file, dir) as Vincent mentioned above. Again many code examples have even been posted above. Pull requests are always welcomed, just right now I dont have the time to work on this.