Item12721: Support multiple attachments at one time

See also Item1886 which has been outstanding since March 2011.

It is now 2014 and TWiki 6 (as well as TWiki 5 before it) has the ability to attach up to 10 files in one pass.

It's silly, don't you think, that I need to pop over to our installed TWiki just to attach more than one image at a time?

-- VickiBrown - 18 Jan 2014

Up to 10 files in one pass? Where does that limitation come from?

Try TopicInteractionPlugin. Comes with

• unlimited multi-upload,
• drag&drop upload,
• instant upload,
• pagination of large attachment lists
• async-loading of large attachment lists for faster topic view times,
• search in attachment lists,
• modal dialogs to, edit, rename, move, comment, hide attachments,
• download a selection of attachments as zip archive,
• move/delete/hide/insert-link/insert-gallery for a selection of attachments,
• thumbnail preview of images,
• selecting an image to be used as thumbnail for the topic in search results,
• build in slideshow of images,
• listen to mp3 audio,
• embed pdfs using FlexPaperPlugin,
• support for chunked upload of very large attachments,
• one-click editing using WebDAVContrib

... etc.

The thing detects capabilities of the browser and uses the best technology available in a configurable priority order, defaulting to html5, flash, silverlight, html4.

See in action here.

This feature is available for Foswiki since August 2012.

Sorry, but I think this is a DoneJob^™ for Foswiki, by far exceeding TWiki's attachment handling.

-- MichaelDaum - 18 Jan 2014

I don't want to need to install a plugin. I don't want any users to need to install a plugin,

Make it part of the core distribution so that everyone who clicks "Attach" gets it for free and then I'll consider it DoneJob™

-- VickiBrown - 19 Jan 2014

Actually, we tend to go the opposite way on Foswiki: instead of loading more and more plugins into the core, we'd like to strip off plugins and come to a clean and fast core.

The discussion of which feature or plugin is then bundled is more on a distribution level, not on the what-goes-into-the-core level. The standard Foswiki distribution will then be a minimal one with additional distributions on the side, more tailored to specific needs. (I often call it the bare-bones distribution.)

There are a lot more plugins in the same situation like TopicInteractionPlugin where you could ask yourself: why the hell isn't this shipped with Foswiki by default. These are very difficult to resolve questions if discussed on the core level, not so when you have multiple distributions maintained to fit specific needs.

Btw. not wanting to install a plugin is a bit off. Just imagine you'd demand to have all apps used on your smartphone being loaded by default. Foswiki and TWiki have always been so attractive and flexible because of their plugins, not so much because their standard distributions are so well fitting.

I personally don't find the standard Foswiki ready for enterprise from day one and I have a quite clear vision of what it has to look like being deployed in an organization. This vision vastly differs from what my Foswiki chaps think. That's the freedom of choice, rather than impose a certain setup for everybody.

This all put aside: just install TopicInteractionPlugin will solve your problem. So ...

-- MichaelDaum - 19 Jan 2014

MIchael -

I don't want to solve "my problem". I want to solve other people's problems. Something called "TopicINteractionPLugin" is not what people are going to look for if they want to attach multiple attachments at once (and I know from experience at Yahoo! that multiple attachments is an important enterprise requirement.

"I personally don't find the standard Foswiki ready for enterprise from day one" -- that's too bad, and I hope you change your mind, but if we want to compete with Confluence and not be a toy wiki, we NEED to be ready for the enterprise from day one.

-- VickiBrown - 19 Jan 2014

"... instead of loading more and more plugins into the core, we'd like to strip off plugins and come to a clean and fast core."

I don't need a plugin. I'm not asking for 16+ features that are inherent in TopicInteractionPlugin.

I want multiple attachments, as described in Item1886.

When I'm talking to a client, I want to be able to say "Yes! Foswiki will do what you want" not "Well, actually, TWIki has a built-in feature that I know big companies have been wanting since 2003..."

-- VickiBrown - 19 Jan 2014

When I say "I don't want to install a plugin", again, I am speaking for all of the possible users and sysadmins, not for me, Vicki, personally.

Multiple attachments is simply something I think should have been part of the standard distribution before the 2008 fork.

-- VickiBrown - 19 Jan 2014

Actually, users don't care how many plugins are installed as long as they get the system that solves their problem. It really does not matter whether there's YAPWABN (yet another plugin with a bad name) on their system as long as it is required to deliver what they want.

In that sense, TopicInteractionPlugin is already there "to solve your problem".

The other "problem" is: why do I have to install YAPWABN at all? This is more a question how Foswiki is presenting itself in the marketplace. I fully agree with you that it is a pity that Foswiki is not ready from day one downloading the initial core distribution. You can't say it is. And this is not only because of a missing multi-attach feature not delivered with the core system right away.

The idea of different distributions has been lingering around for quite some time. We simply did not execute on it. This is were I think your second "problem" finds its answer: by crafting a Foswiki distribution among others that comes with a specific feature set that indeed is ready for enterprise from day one.

Foswiki distributions that I can think of is targeting at

• personal information management
• content management
• blog systems
• document management
• corporate intranet portal
• community sites

You name it. Foswiki "core" is not fit to fulfill any of the above scenarios from day on. You will always have to tinker it to the need.

Other products in the same market segment come in different flavors that indeed are aiming at these slightly use cases and user groups. They all have different requirements. Some features that you need in a corporate intranet (e.g. holiday booking, meeting room reservation, Active Directory connection, SAP connection, single sign on, etc) are simply not required in any of the other cases. You will always find yourself having to install additional plugins based on the scenario. Even then people have ideas how to extend the use of the system. Over time, the system will grow and morph and diverge quite a lot from what you gave them as a consultant initially.

As you see this latter discussion has quite a wider scope that we should be talking about and far exceeds TopicInteractionPlugin yes-no.

Status quo:

• With regards to implementing multi-attach now and today: install TopicInteractionPlugin. People love it.

• With regards to Foswiki distributions: please help getting this vision in place. Otherwise Foswiki will end up in a misshaped something.

Thanks.

-- MichaelDaum - 20 Jan 2014

"Actually, users don't care how many plugins are installed as long as they get the system that solves their problem."

Admins care. Managers care. Trust me; I worked with them for 5 years.

-- VickiBrown - 21 Jan 2014

Manager: "And does the new system fit our needs? Is is easy to use?"

Admin: "Well, it has got too many plugins."

(Pause. Manager remembers that tech staff is quite elusive from time to time.)

Manager: "It looks nice though and with this new fulltext search I finally find my stuff again. Is it a problem that it has so many plugins now? In how far does it harm business requirements?"

Admin: "I don't like all these plugins. Installing any additional plugin makes me nervous."

(Pause. Manager scratching his head.)

Manager: "Okay I see, you don't like it. And does Sales like the new multi-attach-drag-n-drop feature?"

Admin: "I hope so. Haven't heard from them in a while. Took me ages to sort things out. Why can't everybody do Ruby or Erlang? I aint gonna touch any of this Perl fluff again. There are other projects I have to take care of now."

Manager: "Yes, right. The new Sharepoint thing needs to finish at least sometimes. Let's hope we won't exeed budgets."

Manager: "Hm, I wished we had this new Foswiki half a year before with all of this neatness. Why isn't this thing enterprise-ready from day one? At least it didn't cost anything besides your time."

Admin: "Open Source, y'know. All these hobbiist hackers, they don't care about enterprise requirements. Most of their stuff is buggy anyway and I had to fix it and minimise cruft all by myself. I could do a better wiki in pure JavaScript in three days ..."

Manager: "Ah, ok. Anyway. Well done. I appreciate all your personal efford."

(Manager wanders off and quickly forgets about Admin's objections against plugins'n stuff.)

-- MichaelDaum - 21 Jan 2014

I'd just like to say that you are both right.

At first glance they are quite contradictory requirements. However, somehow we need to bridge that gap.

I think it's worth bearing in mind that some admins are not that confident/capable/conscientious etc. A good OOBE is not achieved by a minimal distribution but an optimal one (from that OOBE perspective).

An easy to maintain and develop FW is however best supported by a minimal distribution (i.e. very modular construction).

If a potential new FW convert (admin/company) has a good OOBE then they may well stick with FW. In this specific case some new admins will not bother to see why FW OOB does not support multiple attachments and potentially give up on FW.

An Optimal distribution is not necessarily every plugin (even taking Task12725 suggestions into account). It could still confuse a new Admin with too many plugins to understand.

Now choice is generally good, but when you're thrown in at the deep end you do not want too much choice — initially.

The key idea is that the new admin is given a good OOBE distribution and has a chance to play with and become confident with FW (i.e. good experience). At this early stage a new admin is assessing the main features. Subsequently, the new admin may choose or need more advanced features.

This task and Item12725 should really become a FeatureProposals (need to check if one covering this already exists) and I do think we should take time to discuss this at the upcoming FoswikiCamp2014. We will need to decide what extensions should be part of the OOBE distribution (assuming this idea is agreed upon).

-- JulianLevens - 21 Jan 2014

Commenting is disabled while not logged in