Here is a zwiki modification that I've found really useful to allow you to organise file uploads in a more structured way than is currently possible. I was originally impressed with zwiki (and indeed wiki in general) because it makes for a great tool for building free-format file repositories.

However I was disappointed that the storage of your uploaded files is flat - all are stored in the one folder. This means that there is the possibility of filename clashes with other contributors; also you can't easily tell just by looking at the file list what pages they're associated with. What I really wanted was some mechanism to associate uploads with the page you're uploading them to if you felt like it - and this is what I did.

It works by creating a new folder object for each page when a file is uploaded to it. These new folders are only created when necessary. I've tried to integrate it with the existing uploads functionality: currently, zwiki puts files in the root zwiki folder, or in a folder called uploads off the root if it exists; if this special uploads folder doesn't exist, then my modified functionality doesn't kick in, meaning that files continue to be put in the toplevel zwiki folder. Also, the user must have Add Folders permission, AND must choose to associate uploads with pages as a saved preference (defaulting to uploading in the original, flat structure).

The uploaded files are stored in folders named for the name of the wiki page, suffixed with "_files" e.g. SomePage_files, AnotherPage_files, blah blah, and all these folders are stored in the uploads folder.

The user can choose to switch on or off (off is the default) this modified upload functionality by use of a stored cookie - zwiki_uploadNamespace, which is set to global if the existing functionality is to be retained, or local if the user wants to switch on the new functionality and store files in folders local to each wiki page. This cookie is set using a new radio button control in the UserOptions? menu. The user must have Add Folders permission to see this new option. (NB. If the user doesn't have Add Folders permission, the system silently returns to the current functionality - ie. store files in flat formation in the root or uploads folder - regardless of the cookie value).

The generated inline links to uploaded files or images continue to point to the correct uploaded location of the file in Zope, regardless of whether you choose the old or new functionality.

Two code mods are needed: in ZwikiPage.py and the UserOptions? content.
Anyway here are the code mods (to the released zwiki 0.9.8) in diff format:

It should be easy to provide nice administration pages for the uploaded files: list, delete, rename etc. (perhaps even to let users see the contents of the upload folder thru the zope management interface?)

There is a related problem with file uploads. There is no way to replace an uploaded file - re-uploading gives an ID in use error. I was thinking about some timestamping approach to generate unique names. Maybe I'll look at FranOReilly's code. On a related front, does anyone know if there are any particular problems with storing many large files in Zope?

FranOReilly, 2002/01/04 18:14 US/Pacific (via web):
Marvin Greenberg points out a small existing bug with file uploads on GeneralDiscussion - if a file uploaded has a WikiName type file name then it tries to render it as such in the inline link to the file.

2002/02/06
This is a VERY usueful way of organizing file uploads...and I'd love to see it folded in with the standard zwiki distribution...

2002/07/31 13:52 GMT (via web): 2002/07/31 This is great, and SHOULD become part of the zWiki distribution. --Tracey Monroe

2002/09/30 (via web):

I've been thinking along these lines as well, for a Zwiki intranet - I'd like to keep the idea of the folders per page, but make them LocalFS folders so that the files are stored on a file server instead of in the ZODB.

I would like to then extend this so that a property is stored in the Wiki which specifies the UNC path to the file server, and display a link to view (via http) or edit (via UNC) the file. (Julian Melville)