Name | Type |
---|---|
tmpDir is the empty string by default , unable to write to temporary directory | tracker item |
_getGalleryChildrenIds{List,Tree} does not work correctly in php 5.2.x | tracker item |
PDF/ office document files are supposed to be indexed while uploading, but indexing + upload fails | tracker item |
"Create H5P" Link Faulty (takes you back to home page) | tracker item |
"No such attachment on this page" appearing after change of behavior of PluginFile
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= |
tracker item |
"This Gallery is Public:" not documented
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. |
tracker item |
[Feature] Disable File Archive access | tracker item |
{toc} with max_depth, file access by name, show_image with random picture of a gallery
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. |
tracker item |
12.x: file actions (in file gallery) can't be operated in mobile mode | tracker item |
12.x: WebDAV is not working | tracker item |
Caldrac
Contributors |
tracker item |
12.x & 13.x: Images stretched & skewed (in *.t.o sites and LTS production sites on svn) | tracker item |
13.x: After a remote file is uploaded to a file gal, no file Id is shown any more since 13.x | tracker item |
13.x: dev.t.o fivealive-lite.css: images can't be uploaded or selected throught the toolbar icon from tracker textarea | tracker item |
15.x regression: Upload a file in the registration tracker after choosing group is not possible (field Files: using modal or not) - ajax might need to be re-attached | tracker item |
See file last modification date and last user that modified the file
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. |
tracker item |
jonnybradley
Contributors |
tracker item |
File Directory search indexing space sensitive
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. |
tracker item |
Users cannot edit files galleries
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 } |
tracker item |
philippeback
Contributors |
tracker item |
Files Galleries admin screen should allow to displace files like in the Images Galleries screen
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. |
tracker item |
changi67
Contributors |
tracker item |
eddiem.com
Contributors |
tracker item |
Upload new version fails with Chromium 11 on Ubuntu
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! |
tracker item |
tar.gz / tgz corruption in File Galleries downloads
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! |
tracker item |
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