Category: File Gallery (elFinder or standard UI)

Not all galleries are listed (for example when uploading a file).

The problem is (IMO):
#$allIds is given as reference
#foreach go through the array (with an internal iterator)
#in next recursion step an other foreach is called (but with the same $allIds-object)
#the iterator reaches the end of the array and the loop goes a recursion step back
#the "outer" forach continues, but the iterator of $allIds is at the end of the array
#no other item is checked, if one of the inner recursion steps reach the end of the array

Between Tiki2 and Tiki3, behavior of PlginFile changed, and is causing "No such attachment on this page" errors

http://www.google.com/search?hl=en&q=%22No+such+attachment+on+this+page%22+site%3ATikiwiki.org&aq=f&oq=&aqi=

Some file galleries were not visible although categorized so they should have been visible. Had to set the "This Gallery is Public:" but this flag is not documented so its behavior is unknown.

I've added the following features to my tikiwiki 1-9-5:
1. added max_depth to {toc}
with {toc max_depth=3} I can limit the depth of the toc created. This is convenient if I only want to show the next level of subsections.

2. get a file by name via tiki-download_file
with galleryId=<id>&name=<?> I can retreive a file by name. If there are files with the same name the most recent is taken. This is convenient as I can reference the files by there name, e.g. schedule, an I can easily update it with out changing pages. Dynamic content would also work but I prefere the name as it is more obvious than 'content id=42'

3. get a random picutre from a gallery via show_image
with galleryId=<id> a random picture of the identified gallery is given.

Contributors

I need to see the information about the last modification of files on the File Gallery. Date and User.

two more columns are needed in tiki-list_file_gallery.php. Last modified, User. I don't know if more mysql field are required.

Contributors

Text search on files is not usable in 2.0RC4. Table tiki_files "search data" is empty. Files were uploaded, then I defined MIME types, then reindexed. I clicked on "Reindex all files for search" in Admin>File Galleries but can't tell if anything happened; nothing is in Tiki Logs (I already know there is no code for Debug Console to show what Admin>File Galleries is doing). I defined the MIME filters in http://doc.tikiwiki.org/tiki-index.php?page=Search+Admin&bl=n

This apparently sometimes works. In my "trunk" development system I have different text/.doc files uploaded and those were reindexed after I defined the MIME types.

UPDATE: I had trailing spaces in the MIME type names and the filter commands, due to cut-and-paste behavior. I request that trailing spaced be trimmed from the MIME filter input fields.

Users cannot edit files galleries properties.
At tiki-list_file_gallery.php file, the second if statement is open in the wrong place:

tiki-list_file_gallery.php

312 // Check THIS gallery modification rights
313 if ( $galleryId > 0 ) {
314 if ( ! $user || $gal_info['user'] != $user )
315 $smarty->assign('errortype', 401);{
316 $smarty->assign('msg', tra('Permission denied you cannot edit this gallery'));
317 $smarty->display('error.tpl');
318 die;
319 }
320 }

Contributors

Our users keep adding large .ogg files in our files galleries and we have been asked to externalize theses files in a special download directory of the web server. Problem is that the admin screen of the files galleries doesn't have a DISPLACE section. You can set the option for the files to be added in an external directory, and the new ones are indeed placed into it, but the existing files stay in the database.

I have discovered that the *Image* galleries admin screen has this DISPLACE section but it will work only for the image galleries, no way to use it for the non image galleries.

Contributors

Contributors

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!

Uploading a .tar.gz or .tgz file seems to go fine. The "tar tzf" command on the back-end file returns the archive's file listing and "gzip -t" does not show any errors. However, downloading the file with Chrome or FireFox into WinRar claims the archive is corrupt. Downloading the same file with IE works just fine. One of the files in question:

http://bartk.us/t/tiki-download_file.php?fileId=30

Feel free to test. I found a bug from 2006 where this was also happening and it suggested turning off gzip output compression. Looking at the performance settings (it used to be in general) I see gzip output compression was already off, so I turned it on. This did not fix the behavior.

Other files (images and a .rar file) are served A-OK, it is just the .tar.gz and .tgz files that screw up. Back-end storage checksum matches the original file:


$ md5sum THD-fig4.tgz /var/www/localhost/htdocs/tikifiles/7271d5da7a5dc935fe2576ef0a427a69
663f408c4dfc6ca864756f70aa2f9f29 THD-fig4.tgz
663f408c4dfc6ca864756f70aa2f9f29 /var/www/localhost/htdocs/tikifiles/7271d5da7a5dc935fe2576ef0a427a69


This means upload is working A-OK it's just the download that's screwing up. I've edited /etc/mime.types to move the "tgz" extension from the default "application/x-gtar" into "application/octet-stream", but this did not help the file corruption. One of the downloaded files is:


-rw-r--r-- 1 eo eo 60247 Jul 16 21:24 THD-fig4 (2).tar.gz
f3e4f281d2041ce2554d343156b4a1ce THD-fig4 (2).tar.gz

The original being:

-rw-rw---- 1 eo eo 60997 Jul 16 20:36 THD-fig4.tgz

The gzip layer looks in tact on the broken file, but the tar layer isn't OK:

eo@jo ~/THD $ gzip -t "THD-fig4 (2).tar.gz"
eo@jo ~/THD $ echo $?
0
eo@jo ~/THD $ tar tzf "THD-fig4 (2).tar.gz"
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors
eo@jo ~/THD $

A little further investigation shows the file is double compressed!


eo@jo ~/THD $ gunzip < "THD-fig4 (2).tar.gz" > "THD-fig4 (2).tar"
eo@jo ~/THD $ file "THD-fig4 (2).tar"
THD-fig4 (2).tar: gzip compressed data, from Unix, last modified: Sat Jul 16 20:36:37 2011
eo@jo ~/THD $ tar tzf "THD-fig4 (2).tar"
THD-fig4-lin-large.gnuplot
THD-fig4-lin.gnuplot
THD-fig4-ranged-large.gnuplot
THD-fig4-ranged.gnuplot
gnuplot.rot
THD.log
THD-ReB=220m-ReS=1m-ReE=221m-RlB=8-RlS=1-RlE=9-VbB=0u-VbS=10000u-VbE=1000000u-IbB=1550000u-IbS=4000u-IbE=1950000u.log
eo@jo ~/THD $

Even with the mime type set back to the original "application/x-gtar" this is the case. Even with gzip output compression disabled now and chrome cache cleared, the file still is presented corrupted by the server.

Help!