Loading...
 
Features / Usability

Features / Usability


Help - force all images and attachments into the File Gallery

posts: 11

I'm making a wiki for a large group of scientists, many of whom are new to wikis and collaboration in general, so I'm trying to make things as streamlined as possible.

Right now, when they attach a file to a wiki (I have it set up to always show the attachment upload box), it just get filed with that page. However, if someone wants to refer to that file or insert that image in a DIFFERENT page, the uploaded file isn't available in the File Gallery for them to browse to.

Furthermore, some people have been creating new Galleries (I'm not sure why) and putting their files into them. Other not-so-savvy users can't find the files then, so I'd like to prevent this habit.

Is there a way to just dump ALL attachments, uploaded files, etc. into ONE simple directory no matter how they are added? We don't have that many files and I just want them all in one place.

Thanks,
CB

posts: 400

There's no way currently to have attachments go into a file gallery. What you could do is go to Admin Home -> Wiki -> Features (tab), turn off Attachments, and then turn on Pictures and Use File Galleries to store pictures. This way, when users edit a wiki page, they will see the Image icon in the edit toolbar which allows them to upload an image to file galleries.

Using user permissions (ie allowing users to upload to and view galleries but not create them) and file gallery settings (ie whether they are public or not or visible to non-admins) you should b able direct users to a single gallery.

Not sure if that helps, but just one idea for a work-around.


posts: 11

Thanks lindon,

I'll try that, but since none of the files are photos, I'm not sure if that will work. I think we'll just add a link to the page the file is on rather than the file itself and maybe also prevent galleries from being used. Not ideal, but at least fairly transparent. In this way the pages act a bit like folders/galleries themselves.

PS - how did you get the photo icon into the text of your post above? I'd love to use tikiwiki icons in my help documentation.

CB


posts: 400

You're right, for some reason I was thinking of images only.

Here's how I displayed the toolbar icon:

{img src=pics/icons/pictures.png}

posts: 1811 Catalan Countries

Dear Cricketbird:

You'd better disable attachments and create one file gallery then, set that gallery with permissions so that anonymous can see (download) files, and registered upload. And use that icon that lindon suggested, or a new one you can use instead. File galleries allow using images in them, but don't force to use images, so that you can use any type of file.

And you can customize the wiki code inserted in the wiki page from that file gallery, with code to show a link to a file, not a thunbnail from an image.

Glad to see other scientists using Tiki (it's a powerfull with lots of potential also for its usage in sicentific fields).

If your scientists are from experimental sciences, you/they might be interested in using Tiki with R together:
http://doc.tiki.org/PluginR

Cheers and welcome to Tiki Community!


posts: 11

Thanks, xavi, for the welcome and help. Actually, I went with just the opposite tack than you suggested. I'm using dedicated wiki pages with attachments as file directories and scrapped the real file directories altogether. This way, there is one-click navigation to find files (I put a TOC of the various pages in the sidebar), it is easy to link to the "folder" (ie, the wiki page) by just using the double-parentheses style (which people are slowly learning), users have fewer mouse clicks to find the files, and it's nice to be able to have some text explaining what the different files are, what permissions they have (ie "Doug requests that you not share this with anyone else").

It's actually working beautifully today. It works so well that I may yank the file directories from some other tikiwikis I maintain and switch to this setup instead.

Not sure if we're ready for a plugin R yet - most of us are still firmly in SAS-land. But, I've been thinking about trying R out for a while now and maybe this will be an opportunity to play with it more.