Category: File Gallery (elFinder or standard UI)

when I choose to "Upload a new version" of a "myfile.xls" I get this error:

PHP (5.6.31) ERROR (E_WARNING):
File: lib/filegals/filegallib.php
Line: 3430
Type: move_uploaded_file(/myfile.xls.tmp): failed to open stream: Permission denied

And at the top of the browser window it says:

Check that these paths exist and are writable by the web server: /tmp/phpaMyPJu /myfile.xls.tmp

1. notice the root level directory
2. notice the space before /file

{syntax type="tiki" editor="plain"}
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

Again recycling... :-/

Uploading such a document produces this error:
"Incorrect string value: '\xFCr Spi...' for column 'search_data' at row 1"

Can't reproduce here but it still fail at local installation, will check what's needed to make it fail.

"Create H5P" action in File Gallery no longer works in the newly released tiki17.0

The link should look like this: tiki-h5p-edit
but
The link is like this: tiki-index.php?controller=h5p&action=edit

I performed an SVN 17.1 on my instance and the issue was not resolved.

A show instance is created, and the error persist in the show.

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.

In file gallery it isn't possible to block access to file archive.

We should be abble to block the access in order to prevent users from viewing/using an old version of the document(for example a procedure manual)

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.

12.x: file actions (in file gallery) can't be operated in mobile mode

This is because when you click on the tools icon at the left of the file in a file gallery, a popup opens showing all the posible actions to be done with that file.

In mobile mode, nothing is shown.

Remember that file gallery use the non-elFilder interface in mobile mode.

Example:
http://xavi-9794-4984.show.tikiwiki.org/tiki-list_file_gallery.php?galleryId=4
u: admin
p: 12345

(enable Mobile mode through the module in the right hand side column, and attempt to click later to the tools icon with actions to do with the file "My Flower": nothing is shown)

Testing on show.tiki.org is not a good test because .htpassword is something that could block WebDAV

So, to reproduce, try the following (http and https)
* http://dev.tiki.org/tiki-webdav.php/
* https://dev.tiki.org/tiki-webdav.php/

Also, please try:
# visit http://demo.tiki.org/12x/tiki-webdav.php/
# Activate all WebDAV features
# Use a WebDAV client to access http://demo.tiki.org/12x/tiki-webdav.php/


Try uploading a spreadsheet file, and editing in place

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

Image width is set to 600
Image height is not set

Thus, it should be proportional, no?

Please see:
{img fileId="829"}
---
This is happening also to any 12x site based on svn.
Regression was introduced by r52064 in 13.x, and its backport to 12.x (r52066)
{CODE()}
[bp/r52064][FIX] When remote server whre image is down, img plugin will try in vain to get image until timeout which causes page not to load
Authored by: nkoth 2014-07-22
{CODE}

13.x: After a remote file is uploaded to a file gal, no file Id is shown any more since 13.x

Reproduced in doc.t.o.
* Edit a page
* click on the icon at the toolbar: {img src=https://doc.tiki.org/img/icons/file-manager-add.png}
* place a remote url to a file. For instance: http://www.r-project.org/hpgraphic.png
+ Once uploaded, you see no fileId any more. Upto 12.x, you saw the filename with a link to the file id number on hover, etc.

13.x: dev.t.o fivealive-lite.css: images can't be uploaded or selected throught the toolbar icon from tracker textarea

{HTML()}
<video width="320" height="240" controls>
<source src="http://doc.tiki.org/dl1108" type="video/webm">
Your browser does not support the video tag.
</video>
{HTML}

{WEBDOCVIEWER(url=>http://doc.tiki.org/dl1108, width=>425, height=>350)}{WEBDOCVIEWER}

See: http://doc.tiki.org/dl1108

__140713_dev.t.o_13.x_bug_when_attempting_to_upload_or_select_image_from_textarea.webm__ - 5.69 Mb

Upload a file in the registration tracker after choosing group is not possible (field Files: using modal or not) - ajax needs to be re-attached probably after the group selection, since the gruop selection already loads the form through ajax.

Reproduced here:
http://xavi-9794-5987.show.tikiwiki.org/tiki-register.php
* choose group (any of the 2)
* attempt to upload a file at the field: "CV-Resume (PDF)"

To login as admin:
u: admin
P. 12345

FYI: everything works as expected when the registration user tracker is just used by the "Registered" group, and no ajax in the gruop choice to see the fields to be filled at registration time.

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.

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

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 }

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

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.

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

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!

{syntax type="tiki" editor="plain"}
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!