Tags:
create new tag
, view all tags

Question

Issue:
We're looking for suggestions for a painless (well, pain is a relative term) upgrade path from Cairo to Dakar.

Problem:
Early in 2005, when we introduced TWiki into our internal environment, we had visions of making it the only collaboration environment within our group. Yes, I can see you all nodding your head ... we've all had that dream wink

The biggest resistance, of course, was to the way the attachments were handled. Everyone is used to Windows Share drives and TWiki's one file at a time, no in-place editing mechanism was not up to the task. Se looked at alternatives. WebDAV looked promising, but since we were on Apache 2.0, it wasn't for us.

So we did the unthinkable and took the worst possible path from an upgreadability point of view. We modified Attach.pm and all associated templates, etc. to throw away the native attachment mechanism and replace it with a custom implementation that used a Windows mappable mount point as the attachment area.

This has been in place for over a year and, obviously, the users were extremely satisfied with the solution ... even though it broke TWiki in a number of ways.

  • It no longer knew about the stuff in the attachment folders (drag-and-drop).
  • The attachment folders had unlimited hierarchy (again, drag-and-drop ... the typical migration path from share drives to the TWiki was to simply create a topic and drag the entire folder from the original share to the TWiki share).
  • TWiki metadata was useless ... this was not a big concern since some topics have hundreds of attachments (again, curtsey of drag-and-drop) and adding a line for each would simply slow down the rendering.

So we had to throw out the view-mode attachment table generation code (again in Attach.pm) and replace it with a dynamic table generation feature that simply the folder and created a nice twisty-like folder open/close view (this was before TwistyContrib).

Question:
The whole point of the long-winded explanation is that we are stuck with Cairo without any options that don't require a whole lot of work. We cannot give up the functionality that we have enabled.

Some of you might be thinking "Serves them right!", but we are seriously looking for any suggestions that could at least point in the right direction. There have been major changes in the Dakar timeframe that I haven't kept up with, so some of this might be easier to reenable now.

Thanks, Pankaj

Environment

TWiki version: TWikiRelease04Sep2004
TWiki plugins: DefaultPlugin, EmptyPlugin, InterwikiPlugin
Server OS:  
Web server:  
Perl version:  
Client OS:  
Web Browser:  
Categories: Platform, Installation, Deployment

-- PankajPant - 16 Jun 2006

Answer

ALERT! If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

Erm... actually I'm looking for the kind of functionality you describe, as I've described in UsingTWikiAsFileStore. For just the same reason you describe - users love TWiki, but expect some easy way to share file(structures) as well, in a familiar (read Windows Explorer-like) way.

I almost hope there is no easy way to upgrade and you end up creating a wonderful Plugin for Dakar, which you will then kindly share with the TWiki community! wink

-- JosMaccabiani - 16 Jun 2006

Pankaj - in DakarRelease I added AutomaticAttachments - this provides an approach that is compatible with some of the functionality you added.

-- MartinCleaver - 16 Jun 2006

Martin, I'll have to take a closer look at AutomaticAttachments. Thanks for the pointer.

Jos, if and when we do end up moving to Dakar, we'll make sure to "do it right" this time ... but it will probably be a while before that happens.

-- PankajPant - 18 Jun 2006

As a start, would someone be kind enough to point me to documentation on the attachment backend, and how one would go about changing the implementation cleanly? I cannot seem to find any relevant information. Thanks.

-- PankajPant - 23 Jun 2006

Pankaj, just an idea:

You could start out by uploading a diff against Cairo for the functionality, together with a few screenshots of what you achived. It's not given that your description and patch will not interest some in merging it to Dakar.

-- SteffenPoulsen - 23 Jun 2006

Follow up on this issue is in AutomaticAttachments and HierarchicalAttachmentFolders.

-- SteffenPoulsen - 02 Jul 2006

I think this topic raises a more generic (broader) question about upgrading TWiki where things have been customized. We have implemented several plug-ins and changed settings all over the place. We've got a couple hundred topics online now. We're looking to upgrade our desktop Mac installation to a full-blown XServe running OS X Web Services (Apache). I can't even begin to understand from current documents the process needed to move our installation to this new server. Our first trial run resulted in many, many topics that could not be read because of permissions problems. Is there any documentation or help for moving a TWiki installation to a new server while (trying) to maintain as many topics and settings as possible?

-- DavidWolfe - 31 Dec 2007

Moving to another server should not be a problem, unless users have written hardcoded urls in topics.

What kind of permission problems do you encounter? Webserver permissions or TWiki topic access permissions?

-- ArthurClemens - 31 Dec 2007

Please ask a new support question and provide as many details as possible (see SupportGuidelines.)

-- PeterThoeny - 31 Dec 2007

Edit | Attach | Watch | Print version | History: r10 < r9 < r8 < r7 < r6 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r10 - 2007-12-31 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.