create new tag
, view all tags

Feature Proposals » Preference for default attachment properties


Current State: Developer: Reason: Date: Concerns By: Bug Tracking: Proposed For:
AcceptedProposal TimotheLitt AcceptedBy7DayFeedbackPeriod 2010-06-30     KampalaRelease

Edit Form

DateOfCommitment:   Format: YYYY-MM-DD


On my sites, the general policy is that attachments are hidden, and a link is created for new attachments. The reason is that it presents a less cluttered look - and less temptation for 'experimental' management of attachments.

Today, this requires that the user check the "hide" and "create link" boxes for each attachment (or each drag and drop :-).

It would be nice to be able to have this be the default.

Description and Documentation

Add preference variables to control each property:

A patch (against Wiki 4.2.3) is attached. This patch modifies the pattern skin; other skins would need the corresponding change.

To simplify the patch, I introduce a "new_attachment" context variable. The new context could be useful in simplifying other skins and/or plugins. (Currently Upload reads different templates, which is a bit convoluted. The skins could, optionally, be refactored in a backward compatible way.)



WhatDoesItAffect: API, Documentation, Skins, UI, Usability


See attached. 1 line in UI::Upload.pm, a smidge of conditional in attach.pattern.tmpl

-- Contributors: TimotheLitt - 2010-06-28


Thanks Timothe for the feature proposal and patch.

TWiki already has a ATTACHLINKBOX setting in the TWikiPreferences, the ATTACHLINKDEFAULT seems to serve the same purpose? The ATTACHLINKDEFAULT is a better name than ATTACHLINKBOX. Since this is a TWikiPreferences it is OK to change the name.

As for value, to be XHTML compliant, better to use empty value for uncheck default, or checked="checked" for checked default. Here is the help text from the current TWikiPreferences:

  • Default state of the link check box in the attach file page. Checkbox is initially checked if Set ATTACHLINKBOX = checked="checked", or unchecked if empty ( Set ATTACHLINKBOX =). If checked, a link is created to the attached file at the end of the topic: (can be overwritten by user preferences)
Any way to have this feature done in a compatible way that does not require a "new_attachment" context variable?

-- PeterThoeny - 2010-06-28

I stand corrected - I completly missed the ATTACHLINKBOX preference. Sorry about that. In any case, I don't see a corresponding one for "Hide".

I do generate "checked="checked"" - don't understand why you think I don't.

%IF{"lc($ 'ATTACHHIDEDEFAULT')='checked'" then="CHECKED=\"CHECKED\" " }%

(I don't generate anything if checked isn't set - this works with both XHTML and old-fashioned HTML.)

There probably is a more involved way to implement these without a context variable - certainly however the ATTACHLINKBOX was done should work for hide. I thought that the context variable was a good solution for a patch because it localized the change to just one skin file, and the context variable is then available to plugins as well. Having upload select a different .tmpl file doesn't seem efficient to me - but perhaps this is just a matter of style. I don't really pretend to understand the whole skin system.

As for changing a preference name - is that really a good idea? Couldn't topics, or even users have set it? If not, then I think it should be settable at least at the topic level.

-- TimotheLitt - 2010-06-28

OK, I've tried the ATTACHLINKBOX preference. It seems to check the link box even when managing an existing attachment. For example, click manage on the patch attached to this topic -- you'll see that the create link box is checked. (I set this as a topic preference - which also illustrates why changing the name seems dangerous.) This isn't desirable - changing a comment or (more commonly) updating a file shouldn't spam the topic with a new link. (I think this behavior is a bug.)

So I would like to see each option have a preference that applies to NEW attachments only. This is what my patch does - though certainly fixing the current preference for createlink and adding one for hide using the same mechanism would be fine. Note that distinguishing new from existing attachments is why I introduced the context variable.

-- TimotheLitt - 2010-06-29

Makes sense to have the falg only take effect on new attachments. And I stand corrected, better to keep ATTACHLINKBOX name. For new flag, may be use name ATTACHHIDEBOX?

If you provide a patch we can take this into SVN trunk and 5.0 branch. It is a small enough change that is safe to take into a patch release.

-- PeterThoeny - 2010-06-30

I've given this some more thought, and concluded that my original patch is what should be accepted.

ATTACHLINKBOX syntax is not user-friendly. It also works on both new and updated attachments. I find the behavior highly undesirable - but there may be someone out there who depends on it. I'd rather not break them. And neither of us likes the choice of name.

So, I think the right things to do are:

  • Deprecate ATTACHLINKBOX, but leave it as is. This is not much legacy burden - it turns out to be a paragraph in the preferences page + the variable expansion in the skin.
  • Accept the original patch. It has the right behaviors, a reasonable UI, and is backward compatible. (If someone is using ATTACHLINKBOX, ATTACHLINKBOX will continue to work. If both are used, they are effectively ORed.)
All that's missing is documentation for the TWikiPreferences topic, which is:

  • Deprecated Default state of the link check box in the attach file page. Checkbox is initially checked for both new and updated attachments if Set ATTACHLINKBOX = checked="checked", or unchecked if empty (Set ATTACHLINKBOX =). If checked, a link is created to the attached file at the end of the topic: (can be overwritten by user preferences)
  • Default state of the Create a link to the attached file check-box in the attach file page for new attachments. Check-box is initially checked if Set ATTACHLINKDEFAULT = checked. Otherwise it is not checked. If checked, a link is created to the attached file at the end of the topic.

  • Default state of the Do not show attachment in table check-box in the attach file page for new attachments. Check-box is initially checked if Set ATTACHHIDEDEFAULT = checked. Otherwise it is not checked. If checked, the attached file is not shown in the table at the bottom of the topic view page.
    • Set ATTACHHIDEDEFAULT = checked

Oh, and whatever corrresponding changes need to be made for the other skins...

-- TimotheLitt - 2010-06-30

Does the multi-attach feature of TWiki-5.0 still work with this patch?

-- PeterThoeny - 2010-06-30

I have updated the patch to (a) include classic and null skins and (b) remove the drag and drop hook from pattern that inadvertently was included in the diff.

I don't know about TWiki 5.0. Depends on exactly how it was implemented. I don't expect to ever run on TWiki 5.0, so this is as far as I'm taking this here. If any adaptation is required for 5.0, it should be pretty clear what to do: the checkboxes are each separated out into TMPL:DEFs for attach and reattach, then instantiated based on the context variable.

-- TimotheLitt - 2010-06-30

Thanks Timothe for providing updated patch. Let's take that into SVN trunk and 5.0 branch, provided that it and multi-attach works properly in TWiki-5.0.

-- PeterThoeny - 2010-06-30

Let's wait for 7 days until it is AcceptedBy7DayFeedbackPeriod.

-- PeterThoeny - 2010-07-01

This is now accepted.

-- PeterThoeny - 2010-07-29

Ping. Anyone interested in working on this? We have not seen Timothe for a long time.

-- PeterThoeny - 2011-03-26

Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r18 - 2013-10-11 - 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.