Category: File Gallery (elFinder or standard UI)

When ''Automatic indexing of file content'' is active, trying to upload pdf files fails.

The pdf file is still uploaded but the end user is told that upload failed.

Try uploading pdfs in [http://nycdwight-11908-6600.show.tikiwiki.org/tiki-upload_file.php?galleryId=4] ! (beware of the 8MB size limit) (verify that ''Automatic indexing of file content'' is still active)

They display an error « File upload failed: SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data ».
Only for pdfs.

This is an example return answer to /tiki-ajax_services.php?controller=file&action=upload_multiple :

<feff>{"files":[{"size":15295,"name":"document_BBB_02_argentine.pdf","type":"application\/pdf","fileId":"5788","galleryId":"137","md5sum":"7a035db1d92779f8dcdefe083b292d94","info":{"fileId":"5788","galleryId":"137","name":"Document BBB 02 Argentine","description":"","created":"1554159196","filename":"document_BBB_02_argentine.pdf","filesize":"15295","filetype":"application\/pdf","data":null,"user":"Jyhem","author":"","hits":"0","maxhits":null,"lastDownload":null,"votes":null,"points":null,"path":"90792de52961c34118f976ebe4af3a75","reference_url":null,"is_reference":null,"hash":"7a035db1d92779f8dcdefe083b292d94","search_data":"\n","metadata":"","lastModif":"1554159196","lastModifUser":"Jyhem","lockedby":"","comment":"","archiveId":"0","deleteAfter":null},"syntax":"{img fileId=\"5788\" thumb=\"box\"}"},{"size":15741,"name":"document_BBB_01_bresil.pdf","type":"application\/pdf","fileId":"5789","galleryId":"137","md5sum":"50d71753a6487af8c023f28d8df58d24","info":{"fileId":"5789","galleryId":"137","name":"Document BBB 01 Bresil","description":"","created":"1554159196","filename":"document_BBB_01_bresil.pdf","filesize":"15741","filetype":"application\/pdf","data":null,"user":"Jyhem","author":"","hits":"0","maxhits":null,"lastDownload":null,"votes":null,"points":null,"path":"c84d5b2eb5e278b26a0d60ab7bc4c606","reference_url":null,"is_reference":null,"hash":"50d71753a6487af8c023f28d8df58d24","search_data":"\n","metadata":"","lastModif":"1554159196","lastModifUser":"Jyhem","lockedby":"","comment":"","archiveId":"0","deleteAfter":null},"syntax":"{img fileId=\"5789\" thumb=\"box\"}"}]}


The issue seems to be one or more invisible BOM (zero-length nonbreaking spaces) character before the json string.

My guess is, this regression is related to our changing the way pdfs are indexed. Since Tiki18, we use a php library bundled with Tiki. Before, we relied on a command line executable. Sadly, reverting to the old way of putting the following in tiki-admin.php?page=fgal#contentfgal_admin-5 does not work:
|| application/pdf: | pdftotext -enc UTF-8 %1 - ||

Have Tiki 5.0 installation (both fresh and upgrade) on Windows XP. Accessing interface from localhost (same Windows XP). Uploaded both Word 2000 and ODT files (simple Lorem Ipsum text 1-2 pages) to file gallery. When dowloading and reopening files, I get errors in both open office and Word indicating that neither program recognizes the character encoding. The file gallery is storing these binary files in the database (not the file system).

Work Around - Save files as .rtf (rich text format), whic increases their size about 5-fold. Uploading and downloading and opening works perfectly.

When Tiki 5.0 is running on CentOS, this same error occurs. Seems to be independent of versioning versus non-versioning.

What's going on with the character encoding?!

While navigating galleries in Finder View the URL does not change. The impact of this is selecting "Edit Gallery" will result in editing the gallery identified by the out-of-date URL, and not the currently view gallery. Easily missed, resulting in editing the wrong gallery.

{syntax type="tiki" editor="plain"}
{maketoc}
!Problem Summary
The dialog structure for uploading a file and adding a link to it in wiki page is much better than it was, thanks to the introduction of the __File__ icon in the toolbar of the wiki editor. But it is still cumbersome and error prone. Here is the process below and the usability issues that I found at various spots.

# Click on the __File__ icon
# Pick __File Gallery/Archive__ in __Type__
# Click on __Pick a file__ link
# Click on the __Upload File__
# Click on the __Browse__ button
# Click on __Upload__ button
# Browse the file system and pick the file.
# Once the file is uploaded, click on its name.
# Click on __Insert__ button

Besides the fact that this is long, there are many places where it is misleading to the user (details later). I had to try this more than a dozen times, clicking on different items, to figure out how it works. And I had help from some experts on the mailing list!

Fortunately, there are a number of very small fixes that we could implement to address those issues. See below for a discussion of the various issues and proposed fixes.

!Issue 1: __Type__ should have a reasonable default
Currently, the type is set to empty. It really should be set to either __File Gallery/Archive__ or __Attachment__ by default. Personally, I would favour __File Gallery/Archive__, because I think it's generally a bad idea to attach files to a wiki page, because it limits your ability to link to those files from other pages. But the point is: the value should default to what users most commonly use.

In some cases, the picklist only has one option in it anyways (ex: if the feature for attaching files to wiki pages is off). In those cases, then the picklist should DEFINITELY default to that single value.

^Fix: Set the __Type__ to a sensible default... I vote for _File Gallery/Archive__^

!Issue 2: __Pick a file__ link looks more like a caption than something you can click on
I never realized that I could click on it to choose the file. Someone had to actually point that out to me. Others on the mailing list have said that they need to point this out to users all the time.

^Fix: Change the link to a button^

!Issue 3: Too easy to miss the __Upload__ button
Once you click on __pick a file__ link, you are presented with the general screen for navigating and managing the File Gallery. But at this point in time, you are only intersted in uploading or choosing a file from the gallery, and seeing this complex dialog is very disorienting. In my case, I managed to miss the fac that there was an __Upload__ button on that screen, and I thought I had mad a mistake and someone pressed the wrong button or link in the previous screen. I had to go back to the previous screen several times and click on different things, and finally come back to clicking __pick a file__, and then I saw the __Upload__ button.

^Fix: Instead of having a single __Pick a file__ link (well, button, if we implement the fix to Issue 2), we should have two buttons: __Upload__ and __Choose from Server__. Or something like that (I can't think of a good workding). The __Upload__ button will take you directly to the place you currently get to after clicking on the __Upload__ button in the File Gallery screen. The __Choose from Server__ button will still take you to the __File Gallery__ navigation and management menu.^

!Issue 4: Not clear that you have to click on the file name after uploading
In Step 8, there is nothing that tells you you need to click on the file name after you uploaded it. I went through the whole process several times and it never occured to me that I had to do this until someone from the mailing list told me.

Note that there is a message to that effec that appears if you hover the mouse over the file's name. That message really should be visible at all times, not just when you hover over the file name.

^Fix 1: Make it so you don't need to click on the file name altogether.

Fix2: If that's not possible, at least put a very prominent messages saying that the user needs to click on the file name^

!Issue 5: Insert button is not clear.
In Step 9, you are back at the original pop up, and you need to click on the __Insert__ button, otherwise the link to the uploaded file does not get inserted.

Again, I had to do the process several times before realizing I had to do this. My natural tendancy was to close the popup, either by Xing it or clicking on the __Close__ button. The result is that the file does not get inserted on the page.

I think the problem is that the two buttons at the bottom say:

__Close__ __Insert__

And you naturally tend to click on the first of these two, i.e. __Close__.

^Fix: Change the order and caption of the two buttons as follows:

__Insert link__ | __Cancel__

Also, if the user clicks on the X to close the window, the link should be inserted (in other words, __Insert link__ should be the default). The reason is that it's easier to recuperate from that error (you just need to erase the link) than to recuperate from the other error (you have to start again from the beginning, to insert the link).
^

__Fixed in 4.0__

When a Gallery is designated as an audio podcast Gallery with a file folder used for storage, and files are added to the Gallery they are correctly stored in the file folder BUT the links generated when a file is downloaded from the Gallery is incorrect.

In my example I set the folder as podcasts/ (in v2.x the path setting for the podcast gallery folder had to be relative I'm assuming this is unchanged) so the download should generate a link like:

....tikiwiki/podcasts/filename.mp3

Instead the link incorrectly is generated as:

....tikiwiki/filename.mp3 ie the download path is omitted

All non podcast galleries are OK generating the usual:

tikiwiki/tiki-download.... format

This worked fine in versions 2.2/2.3/2.4

Our friends at [http://www.horde.org/imp/|IMP] offer a feature to view various file formats without having the viewer installed on your desktop.

Beyond viewing, we could want a way to import to a wiki page. Since this is a broad topic, we'll coordinate on ((Binary File Handling)).

Trying to understand what is going on with files and Tiki21 (most image show a .jpg icon instead of the image in the file gallery) I found out that I have way to much files in my file folder than my file gallery.

For 53 files in Tiki I have 204 files in my directory.

{img fileId="1359" thumb="box"} {img fileId="1358" thumb="box"}

I understand there is an option to have more than one file per file (previous version) but I never had such quantity of extra files.

I see a parameter at : tiki-admin.php?page=fgal
"Allow download limit per file"
It is not set by default and when setting it the user have no idea of the limit that he can set.

# --I should be able to set "here" the threshold for the limit-- See my comment {sign user="Bsfez" datetime="2020-02-24T08:09:13+00:00"}
# I don’t think this is the expected default behaviour and it can lead to serious inflation of the file folder (especially for new users without a lot of experience in IT).
# Now that it’s all here and after I set my limit to allow 1 file per download (1 file in my directory for 1 file in Tiki gallery) how to clean the extra files that are still there ?

Dear folks, if you go to this page at:
https://thepatriotwoodwiki.org/Western-White-Pine
or
https://thepatriotwoodwiki.org/Eastern-White-Pine
or
https://thepatriotwoodwiki.org/California-Incense-Cedar
or
https://thepatriotwoodwiki.org/HomePage

Basically anywhere I have list files in place, if you click on the wrench icon at the left of each file, then click on "Browser Display", you are redirected to an unrelated page in our wiki, the same page for all the files. I cannot make heads or tails on this one.

What I would expect to occur when "Browser Display" is clicked on, is the image to display in browser view.

A show instance will be created to try to reproduce this bug.
I don't recall this issue before my tiki 18.3 updgrade.

Issue was introduced in our forums at https://tiki.org/forumthread71245-Weird-Action-w-File-Browser-Display?topics_offset=13

I edit an image from the file galleries using ''Edit properties''.
It does not matter that it's in list or browse view.

The image is of type "image/jpeg", as is reflected in the database dump:
INSERT INTO `tiki_files` VALUES (4321,120,'P1080902.JPG','',1452031989,'P1080902.JPG',424279,'image/jpeg',NULL,'Jyhem',NULL,0,NULL,NULL,NULL,NULL,'435783c7acc75fad9fe03d146b238a8c',NULL,NULL,'f79bf974b338faad5e21ed9eb3fd2dfe','',NULL,1452031989,'Jyhem',NULL,'',0,NULL);

But it shows the first item in the "type" drop-down (application/andrew-insert) instead of image/jpeg

And it's a long long dropdown so fixing it is a pain :-)

DEMO Instance: admin/12345

discovered on tikiwiki.org

If an Admin set his Tiki file gallery using a directory to store files and he doesn’t use an LTR language for admin he will have a wsod. This is a regression as it was working (18, 19 may be) before we were able to select an Admin language.

I think that the path to the files is reversed leading to an error that shutdown Tiki.

It will require to have access to the db and set (or unset, depending if the non LTR language is Tiki default or Admin language) a different value (like "en") at : language_admin to regain access.

I’m not sure what’s the best course of action but this should be addressed as a user may choose a language on the install without knowing it will brick the application. It is unlikely he will have an idea of what to do.

* Tiki should be protected from using a wrong or broken path.
* Setting warning on install, 18n, etc doesn’t seems appropriate and will harm Tiki image.
* On the other hand, it is not really possible (unless someone want to suffer and die in pain :)) to use the Admin in Hebrew, Arabic or other RTL languages.

May be the simplest answer is:
# Make sure wrong path can’t break Tiki (or can’t be saved)
# Limit the usage of the Admin to LTR language

In all case it can’t stay like this.

I've upgraded today to latest 20.x (to r71082, from svn code from 1-2 months ago or so) and attempting to insert wiki code to display a file in a wiki page (just after file upload) fails: not the full syntax is written, just "file", and no fileId either.
File seems to get uploaded successfully indeed, but the popup helper (open through the toolbar icon to upload files) fails to display the information that the file was uploaded successfully, not to insert the right syntax to that file.

{img fileId="1329"}

Reproduced with updated Firefox and Chrome, on Ubuntu GNU/Linux 64 bits (in case it matters)
And reproduced in dev.t.o also (provided that the tool -+tikifile+- has been added to the editor toolbar.{sign user="xavi" datetime="2019-09-27T11:06:15+00:00"}

Using standard file gal interface (not elfinder), and standard wiki editor toolbar, and using toolbar icon -+tikifile+-.
Same process to upload images works as usual, as expected.

{syntax type="tiki" editor="plain"}
When attaching a document to a wiki-page, for example an MS-Word file, this attachment seems not to be indexed. There's also no option to indicate which handlers for different mime-types to use. This option is available when using file-galery, but not for page attachments.
As a result the file will never show up in any search results.
Furthermore: it would be convenient to be able to indicate that the indexing of attachments should be logged. This would ease system debugging in the case mentioned.

If an upload fails here: tiki-list_file_gallery.php?galleryId=1, I get a descriptive error message (ex: file too big).

The same would be useful for wiki page attachments.

{syntax type="tiki" editor="plain"}
Hi,
I found an issue using "wikiplugin_files" plugin.
If You try to use it (on Wiki pages or in other available places like parsable ptracker descriptions etc) Wiki page show files in the particular gallery but You can only download file. You cannot update newer version or see a history of that file althou theres an option to do it.
Ive try it both on TW 2 and TW 3(beta).
Ive tried to turn off/on all java UI thingy but w/o success.

Best regards,
Piotr

At tiki-file_archives.php?fileId=n when you select several or one archived file and try to delete it using the bottom action selector nothing happen.

Work fine if you delete one file using the "delete" action button action under the wrench menu.

On Tiki24 on file gallery => edit properties you can add a description to a file.
If you come back and remove it, it will stay... forever ! ??‍♂️

http://bsfez-11581-8072.show2.tikiwiki.org/tiki-list_file_gallery.php?galleryId=1

Tested with 2 files.
Try to edit/remove save the description.

If you save a page that has a description in Hebrew and categorise it (it wasn't categorised previously) on save a WSoD is displayed but the data is saved.

It happens every 3 pages... and kind of unpredictable.
I put this ticket on side until I find a better way to reproduce.

On file gallery you have a slideshow option (admin => listing).
Once enabled it will display a slideshow button at the top of gallery pages.
In browse mode you can navigate from page to page: http://bsfez-11581-7931.show2.tikiwiki.org/tiki-list_file_gallery.php?galleryId=4


When clicking it start a slideshow that display images ===from the first file in the gallery.===

When you have several pages this is not user friendly and is bad UX. (imagine you have hundreds of pictures)

To demonstrate:
*In the edit gallery Iisting setting I set 2 image per pages (row) to have several pages
* I used small images but bigger images or on mobile the image will cover all the screen (you won't see the screen below the slideshow like in my screenshot)

{img fileId="1635" thumb="box"}

ADDITIONAL INFORMATION;
Seems that the URL and the slideshow should use an offset parameter but it is not working.
Exemple: http://bsfez-11581-7931.show2.tikiwiki.org/tiki-list_file_gallery.php?galleryId=4&offset=4

If I want to update an image that's used in a wiki page, or for some other reason find an image in the file galleries when I only know its ID, as in "display290", it would be great to be able to find it by simply searching for the ID number or display code. This doesn't seem to be possible now.

Working with workspaces + permissions comes from the need to protect content from unauthorized access. While this already works great with wiki pages, such confidential content are also files & images uploaded to galleries. However, those aren't created via workspace templates. one has to create and manually assign permissions to them additionally.
Either have them created automatically or have an option to do so if it's not common case to have separate galleries along with separate categories/ permissions.

In the file gallery you can set how many results you want displayed, but this setting is called (in find.tpl, line 261) ...

{CODE(Colors="Tiki")}
{tr}Displayed rows{/tr}
{CODE}

... "Displayed rows".

The default setting is 25, but not 25 rows are displayed, but just five. With five results per row, that makes 25 results, and not 25 rows.

Maybe this is a leftover from old days with line listings? Either change the label or the logic behind the setting, the former possibly easier to achieve :-)

Thanks
hman

Uploading any non image into the file gallery with the upload image button in the WYSIWYG editor works fine. But when selecting that file to put in the site, TikiWiki incorrectly specifies that the file is an image. This results in the webpage with "File is not an image".

My php is 5.3 and fileinfo extention is set up correctly. I can correctly display the file by switching to Wiki text mode and changing the designation from "img" to "file"

OK, before anyone calls me stupid, the button does say "Choose or Upload Images" There is no button for choosing and uploading files, but I assume that since the "File Gallery" and not the "Image Gallery" is being called up, it should be able to handle both. If not, then I guess someone needs to add a button to CKEditor.

I created a show-me instance to show the problem in the current branch. However, this version has the option to add more buttons to the WYSIWYG. There is a file button that solves this problem. But this is a major hassel for me in the 11.1 branch. Any way I can get the file button in version 11?

{syntax type="tiki" editor="plain"}
I applied the patch from bug report 2956. Only one of the zipfile content files is added.

In Tiki 6.3, when using the 'Upload New Version' feature in the file gallery with Chromium 11 on Ubuntu 10.04 amd64, the file selection dialog appears, but when a file is chosen, nothing happens.

It appears to be an incompatibility with the browser, as the bug does not exist when using the following browsers/OS:
- Firefox 3.6, Ubuntu 10.04
- Chrome 11, Windows 7
- IE 8, Windows 7

Couldn't find anything on the chromium bug list or tiki bug list.

Any help is greatly appreciated!