Category: File Gallery (elFinder or standard UI)

{syntax type="tiki" editor="plain"}
When listing a File Gallery you can select a number of files and use the "Select action to perform with checked ..." drop down list below the listing to select the "Download zip version' which will then download a .zip file with all the selected files inside.

This works OK in 24.6 but just produces a 'white screen' in 27.0

{syntax type="tiki" editor="plain"}
The list of actions that can be perform is limited to <move to> when others actions (individual list) could be performed as <delete>

The usability bug appears while updating the newer version of the file.
There is a field for a comment given to the newer version of the file being uploaded, however, what is being typed is not displayed:
{img fileId="1062" thumb="box"}
{img fileId="1061" thumb="box"}
If we then look, it displays what I typed as metadata (works properly here):
{img fileId="1062" thumb="box"}

I believe that the feature is unimportant and the bug it comes with confuses a non-technical user, the feature is to be fixed or got rid of

When you have more than one version of an image in the file gallery (via the update mechanism) you get an additional property: Archive.

When you select that, you get this images individual archive displayed. All images have the standard properties, and among them is "delete" to delete the image. That works as it should.

But also each and every image gets a checkbox, and underneath the listing, you can perform some task on a set of images collectively (all that got a check in the checkbox).

Among those task is again "delete".

But when you check some archived images and select a collective delete, this will be completely ignored. You do not even get the normal confirmation dialog. Also, no error message. It just does _nothing at all_. Whatever you had selected stays selected. And this is independent from permission, the same happens to the admin, when he or she wants to delete a selection of images.

As I said before, individual deletion works as it should, so it's probably "only" a problem of the collective delete algorithm.

Thanks
Hman

{syntax type="tiki" editor="plain"}
File galleries have an edit setting that limits the number of file versions that are held as 'archive' but this limit does not seem to be respected in T27.x as the number of archived files exceeds this value.

auto categorization does not work in drag an drop. This can be a huge problem for those who use category jail, as all files will become invisible.

This bug occurs when using multiple workspaces, where each have a perspective with a category Jail.

Consider each workspace to have a main file folder (that belongs to it`s main category, and is only acessed by a certain group when it enters the workspace).
If you upload a file with the normal way, it will acquire the category by the autocategoriation pref.
But if you use the drag and drop feature, it will have no category, and will become invisible to the users, even if is inside the main group folder (because it has no category, and the category jail pref is on)

Show instance: http://fvtorres-11800-5950.show.tikiwiki.org/
User: admin
Pass: 12345

The backlinks in the file gallery don't appear to work. At lest they do do nothing with my install and configuration.

Not really sure how to proceed, but just to let you know. It could have been a very useful feature to me :(

Happy to give more info if you like. Backlinks for wiki pages seems to be working well. 12 LTS installed. Latest version (installed just over a week ago)

{syntax type="tiki" editor="plain"}
I want to use backlinks in File Gallery to show me what wiki pages reference the files. This is how I can identify orphaned files. However, this function is so broken that it is unreliable.

What I would expect from this feature is the following behaviors:
#Each file referenced in a wiki page has a single backlink to that page recorded in the File Gallery that contains the file
#Backlinks to wiki pages are uniquely indexed, so that even if there are numerous references to the same file on a page, there is only one backlink to that page shown in the File Gallery, rather than multiple backlinks to the same page
#Removing a reference to a file from a page will remove the backlink to that page from the file in the File Gallery
#Deleting a wiki page will delete all backlinks to that page in the File Gallery

The behaviors I have been able to duplicate in the demo wiki ([http://demo.tiki.org/11x/tiki-list_file_gallery.php?galleryId=6]) are as follows:
#Linking to a file in a wiki page will create a row in the ''tiki_file_backlinks'' table for that page in the File Gallery every time you save the page, even if there is already a row for that page
#If you edit the page and then save it, the backlinks to the referenced files are sometimes incremented, and sometimes not
#Removing the link to a file in a wiki page and then saving it ''does not remove the backlink'' in the File Gallery to that page
#Completely removing a page from the wiki that is referenced by backlinks in the File Gallery will not remove those backlinks, but will instead leave orphaned backlinks to non-existent pages
#There is no reindex or cleanup function built into Tiki for File Gallery backlinks, and no way to manually fix or remove bad backlinks (other than directly editing the database tables)

Once the file gallery batch feature is enabled:
At https://next.tiki.org/tiki-batch_upload_files.php?galleryId=17 at the bottom if you enable "Upload into galleries according to sub-directories" other options are displayed but the design alignment and position of sentence is broken. Col-4 and 8 are over lapping instead of being one next the other.

As the additional options are child of "Upload into galleries according to sub-directories" they should look like child options (indent)

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

Tested in v3.1. When choosing to store File Gallery items in a directory instead of the database, the directory field requires the full server path. If the abbreviated relative path to the wiki is entered, file uploads fail.

This conflicts with both doc.tw.o (as of today's rev) and Admin > Wiki, which allows the attachment directory to be specified relative to the wiki directory.

I tried the file gallery from tikiwiki 3.2. in opera 10, the loading screen (uploading) never stops and the image is not shown in the gallery (empty picture frame) or when used inside a wiki page. When clicking at the icon symbol or empty space shown there instead the invisible thumbnail is opened correctly though showing the full picture. Works fine in IE 7 and latest Firefox.

Chose a non-default workspace:
{img fileId="1064" thumb="box"}

Open File Gallery and upload a file:
{img fileId="1065" thumb="box"}

Choose the file and see that the checkbox marking the category corresponding to the workspace is checked:
{img fileId="1066" thumb="box"}

The file is uploaded:
{img fileId="1067" thumb="box"}

Browse the file gallery - it is empty, where did the file go?
{img fileId="1068" thumb="box"}

Open the file gallert from the default perspective (workspace), the file is shown, thus, it was uploaded:
{img fileId="1069" thumb="box"}

Let's see its properties:
{img fileId="1070" thumb="box"}

It doesn't belong to the category it was said to belong during the upload:
{img fileId="1071" thumb="box"}

We add it to the category that we intended it to belong to:
{img fileId="1072" thumb="box"}

We switch back to the desired workspace, open the file gallery, our file is there:
{img fileId="1073" thumb="box"}

__Very low usability!__

I got a problem to see thumbnail and download file from File Gallery.
What I did are:
1. create a customized a folder for file gallery
2. point the file gallery folder destination to the new folder in setting.
3. upload a file
4. try to view the file and download the file, the system goes to endless loop, and no responds from server to client, logs are continuously generated till disk full.
[Thu Jan 01 12:56:38 2014] [error] [client 192.168.1.102] PHP Notice: ob_end_clean(): failed to delete buffer zlib output compression. in /apps/tiki/tiki-download_file.php on line 147, referer: http://tiki.mydomain.com/file1
5. after I check the code. in the tiki/tiki-download_file.php, line 146, it has below
~~#60F:while (ob_get_level()) {
ob_end_clean();
}// Be sure output buffering is turned off
~~
6. I googled the coding, looks it should be changed as below.
~~#60F:while (ob_get_level()>1) {
ob_end_clean();
}// Be sure output buffering is turned off
~~
7. I changed, the code, the file viewing and download are perfect. problem is solved.

Could any developer please review the code, if it is the way to go, please merge the change into the main trunk for future releases.

Thanks.

When downloading file/files from the file gallery the actual download completes in ~1 second. The File Gallery UI download progress bar still thinks the download to progressing at a slower rate and shows 100% complete after 10 or so seconds.

I'm getting a 500 error trying to upload the screenshot so I'll attach

I recently upgraded our tiki install to version 2. Most things survived the upgrade, however the most obvious thing that was broken is the file galleries feature.

All links to files previously in the gallery still work correctly, however when I select the option to list galleries, none of the existing galleries are displayed. It just shows "No records found"

Looking in the database, all files and galleries are there.

When i attempt to upload a new file, I am still given the option to select a file gallery (all gallery names are still shown). When I select the appropriate options and confirm the upload I can link to it as usual but it does not appear when I select to browse the gallery.

[http://tikiwiki.org/tiki-download_forum_attachment.php?attId=231|Screenshot]

> As admin, I can't set the permissions on Registered users to: list_file_galleries or create_file_galleries, though other file galleries settings are selected, including view_file_gallery, download_files, upload_files, view_fgal_explorer, and view_fgal_path. I tried to deselect that last 2 since I don't understand what the file gallery explorer is and I don't know that they need to view the path, but I can't seem to deselect and save it successfully.
>
> When I log in as a Registered user and click on File Galleries, I get this Error message: Permission denied you cannot view this section.
>
> I see a link for Upload file, but when I click on it, I get: No gallery available. You have to create a gallery first! Create New Gallery.
>
> When I click on Create New Gallery, it gives me this Error message: Permission denied you cannot view this section.

I experience that my site's file galleries get slower and slower. Currently, there are just about 200 Mbyte of mostly images in there, in just about two dozen folders. Although my rented web space will of course not boast performance wonders, but it should't be THAT slow. When I clear caches, just calling file galleries takes up to three minutes. If cache has not been cleared, galleries come up instantly.

I have stopped using tiki-check.php even before that, because it regularly breaks my ISPs five minute quota...

I store the images in the DB, but I don't think this really makes the issue. The DB still has almost a terabyte of available storage. And a DB's speed shouldn't depend on amount of storage taken, but on complexity of SQL requests.

I believe that most of the current slowness came when I uploaded some graphics for my co-admins that are not large in size, but large in dimensions (300 kbyte, but 14,000 x 10,000 pixels) (logo master file in PNG). For them, thumbnail creation fails. Could it be that Tiki tries to generate those thumbnails all the time, and fails?

Thanks
hman

when listing a gallery via tiki-list_file_gallery.php?page=fgal&galleryId=<GALLERYID> (with mode set to Browse), the filter section is always opened, even without filters being set, eating a lot of space.

probably comes from the other submitted but where uselessly empty filter parameters are added to the url, like find=&type=&types=&topic=&lang=&langOrphan=&exact_match=&categId=&find_from_Month=&find_from_Day=&find_from_Year=&find_to_Month=&find_to_Day=&find_to_Year=

when you list a gallery, tiki automatically adds all those useless parameters find=&type=&types=&topic=&lang=&langOrphan=&exact_match=&categId=&find_from_Month=&find_from_Day=&find_from_Year=&find_to_Month=&find_to_Day=&find_to_Year=, probably that's why u1 (see below) happens.

In 2.0, Flash files (.flv) stored in the file directory don't play with the FLASH wikiplugin. The movie source url, etc., look ok in the page source, but still nothing displays. File gallery Flash files work with the FLOWPLAYER plugin, though.

This may overlap with the Bug report that "large file galleries are broken".

I consider mine not to be large, but it's broken anyhow. I first noticed it a month ago, when there were about 30-50 images in the file gallery. An image I knew I uploaded was not to be found anywhere. Back then, I thought it might be my mistake, and uploaded again, everything seemed fine.

But now there are precisely 300 images in the file gallery, and I wanted to upload a newer high-res version of an image I had uploaded last month. Then I had only a very low res version, but I had uploaded it as a stub, and created a Wiki page containing this image.

I could not find the image in the gallery! But the Wiki page containing it looked fine... So it was definitely in there, but was not to be found. Then I looked up the images ID in the page source, and used the search function of file gallery to find it - and there it was.

By the way: A feature request. The search function works, but it does NOT indicated WHERE a file was found. That is not very useful...

Then I uploaded the new high-res version, the Wiki page promptly showed it, everything looked fine again

[Edit: there weren't 238 images vanishing from display, as I wrote in the first version of the bug report. That was my mistake: 238 of 300 images are in one folder, and 62 in another. That is still being displayed correctly.
But the issue remains that sometimes single images vanish from display, and can only be found again using the search function.]

the wrench near the gallery name shows "<gallery name> - settings" but leads you to the global admin fgal page, same for the (?) button... doesnt lead to "<gallery name> - help" but to file gallery help on doc.tw.o.

when configuring a gallery, it says at the bottom: You can access the file gallery using the following URL: https://your.domain.here/file10?galleryId=10 ... sure? Shouldn't it be just /file10 OR /tiki-list_file_gallery.php?galleryId=10 ?

Using 1.9cvs from a couple of weeks
Attempting to list any file gallery returns:
{CODE()}
Fatal error: Smarty error: [in tiki-list_file_gallery.tpl line 43]: syntax error: invalid attribute name: 'galeria' title='Fes' (Smarty_Compiler.class.php, line 1536) in /home/httpd/tiki19/lib/smarty/libs/Smarty.class.php on line 1095
{CODE}

For instance, here:
http://www.moviments.net/diaspora/tiki-list_file_gallery.php?galleryId=3

I'm using Catalan language interface

I've removed that line from the code, and the site is working again.