create new tag
, view all tags

WatchlistPluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on WatchlistPlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please file bug reports in the WatchlistPlugin bug database.

Feedback on WatchlistPlugin


  • TWiki has already a subscribe feature with a WebNotify topic in each web. This is flexible, but not very usable.
  • There is also a SubscribePlugin that adds a "Subscribe" button, which makes the subscribe process easier, but makes the WebNotify page messy.
  • TWiki currently has no good page watch solution. MediaWiki has a good page watch feature


  • Address issues mentioned in context
  • User based lists, not cluttered list for all users

Features of the WatchlistPlugin:

  • On each page:
    • Watch Menu dropdown / Unwatch Menu dropdown pulldown menu
      • Watchlist Changes submenu
    • "Watch" / "Unwatch" link in topic action row at the bottom
  • New Main.FirstLastWatchlist topic with three tabs:
    • "Recent Changes" tab: Shows recent changes on all topics that are on user's watchlist.
    • "Watched Topics" tab: Shows user's watched topic list.
    • "Preferences" tab: Shows user's e-mail subscription preference.
  • Subscription feature is separate and in parallel to the WebNotify feature, e.g. a user has the choice to subscribe in WebNotify and/or with the "Watch" links of the new WatchlistPlugin.

Example watch list topic:

TWikiGuest Watch List Changes

Recent Changes

Topic Date
WebStatistics in Plugins web:
Statistics for Plugins Web Month: Topic Views: Topic Saves: Attachment Uploads: Most Popular Topic Views: Top Contributors for Topic Save...
2018-04-22 - 07:01
EmbeddedJSPluginAPI in Plugins web:
EmbeddedJSPlugin API This page lists all the API functions for EmbeddedJSPlugin . See also EJS Table API List. print print(`text` , `text` ... ); Appends output...
2018-04-20 - 00:01
EmbeddedJSPluginTableAPI in Plugins web:
EmbeddedJSPlugin Table API This page describes the usage of EJS Table API of EmbeddedJSPlugin . See also EJS API List. parseTable parseTable( ` A B...
2018-04-20 - 00:01
EmbeddedJSPluginAppraisal in Plugins web:
2018-04-19 - 23:59
EmbeddedJSPluginDev in Plugins web:
Discussion forum for the EmbeddedJSPlugin Thank you very much for contributing this plugin! It looks very useful for TWiki apps.
2018-04-19 - 23:59

Watched Topics


E-mail notification: None: Watch list only.
Immediate: Get notified on each topic change on watch list.
Digest: Get notified of topic changes on watch list in batch mode once a day.


  • Watchlist data is stored in Main.FirstLastWatchlist topics
  • Each user has a <WikiName>Watchlist topic in the Main web:
    • Watchlist is stored in a %WATCHLIST{ "watched" topics="Web.Topic1, Web.Topic2, ..." }% variable.
  • Watch/Unwatch action requires authentication
  • Watch/Unwatch action updates the user's watchlist topic
  • Rename topic updates the user's watchlist topic
  • Delete topic removes entry from user's watchlist topic

-- PeterThoeny - 2013-02-27

Initial outdated proposal:

Features of the WatchAndSubscribePlugin:

  • On each page:
    • "Watch" / "Unwatch" menu item in "View" pulldown menu
    • "Subscribe" / "Unsubscribe" menu item in "View" pulldown menu
    • "Watch" / "Unwatch" link in topic action row at the bottom
    • "Subscribe" / "Unsubscribe" link in topic action row at the bottom
  • "Account" pulldown and user profile page have a "My Watch List Changes" link:
    • Show MyWatchListChanges topic that shows recent changes on all topics that are on my watch list. This topic requires authentication.
  • New WatchAndSubscribeList topic, linked to from user profile pages:
  • Subscription feature is separate and in parallel to the WebNotify feature, e.g. a user has the choice to subscribe in WebNotify and/or with the "Subscribe" links of the new WatchAndSubscribePlugin.


  • Watch and Subscribe data is stored in plugin's work area
  • Each user has a ws<WikiName>.txt file, content:
    Main.TWikiGuest, Y, N
    Plugins.MailerContrib, N, Y
    Plugins.SubscribeAddOn., N, Y
    Plugins.SubscribePlugin, Y, Y
  • Watch and Subscribe action updates the user's file
  • Watch and Subscribe action requires authentication
  • Rename topic updates the user's file
  • Delete topic removes entry from user's file


-- PeterThoeny - 2012-10-19

Sounds good to me except that I don't understand the distinction between watch and subscribe--is subscribe the action for RSS or Atom feeds, while watch sends email notification?

-- RandyKramer - 2012-10-20

  • Watch: Declare pages you like to watch, e.g. find out what is new. The MyWatchListChanges topic is like a WebChanges topic, except that is for all pages you watch across all webs.
  • Subscribe: Sign up get get notified of changes by e-mail.

-- PeterThoeny - 2012-10-20

Ok, understood--thanks!

-- RandyKramer - 2012-10-22

In my environment where three TWiki site are loosely coupled and mirroring each other, watch and subscription data stored in the work area of the plug-in is not desirable because it cannot be subject for mirroring. And if it isn't a topic, you cannot see its state in the past.

How about storing it on Main.FirstLastWatchSubscribe in a table?

Incidentally, I plan to contribute a plug-in named RTNotifyPlugin, which implements real time email notification fater a topic creation/update/move and an attachment upload/move. It sees the topic WebRTNotify which shares the same syntax with WebNotify.

Maybe it's better to share WebNotify instead of seeing WebRTNotify.

-- HideyoImazu - 2012-10-22

Hideyo-san, I like the idea of storing the data in the Main web as topics, with advantage of version control, and that everybody's watch lists are shared. Disadvantages are noise in WebChanges of Main web. It could also get into a scaling issue with tens of thousands of users because of number of additional topics in the Main web.

-- PeterThoeny - 2012-10-22

On workarea, as you know it is meant to be used by plugins to store content persistently. I think it is better to fix the mirroring and/or workarea API to support replication of plugin data in work areas.

-- PeterThoeny - 2012-10-22

Out of tens of thousand of users, people using the Watch & Subscribe features would not be so big. With WebChanges noise, FirstLastBookmarks causes it too.

If either or both of those issues become significant UserSubwebs alleviate them.

-- HideyoImazu - 2012-10-22

Mirroring is conducted web by web basis. Anything belonging to a web is morriror-able. Anything not belonging to a web is not mirror-able.

It's not an API issue. Even now HeadlinesPlugin and PublishContrib have no problem storing their data in their work areas because the data stored there is local to the site and out of scope of mirroring.

Watch & Subscribe data is to be shared among federated sites.

-- HideyoImazu - 2012-10-22

Some plugins create working data that is designed to be persistent, such as the SetGetPlugin (if persistent variables are used) and the TagMePlugin. That is, some plugins can't be used with the mirroring as currently designed. I think you have to support extension work area in some way if you don't want to exclude some plugins.

-- PeterThoeny - 2012-10-23

On API enhancement to support mirroring, I could imagine a recommendation for plugin authors to store web specific data in a /webs/ directory below the plugin's working directory. For example, the TagMePlugin could be enhanced to store the tagging data for the Main web in TWiki::Func::getWorkArea( 'TagMePlugin' ) . '/webs/Main';. Your mirroring code could be enhanced to replicate data of all plugins that have a /webs/ directory in their working directory.

-- PeterThoeny - 2012-10-23

Revised idea based on discussion in JerusalemReleaseMeeting2012x11x22 about RealTimeNotificationByMailerContrib:

  • Just one "watch this topic" menu item / button
  • A watch page to watch all page changes of interests, like in mediawiki
  • In addition, the user has a picklist to get notified by email in real-time, in batch mode, or not get notified at all by email
  • Possible to watch whole web: The watch menu item in WebHome could be labeled "Watch the Foo web", for all other topics in that web it could be "Watch this topic". Or the "Watch the Foo web" menu item could be an additional item to the "Watch this topic" item in WebHome.

-- PeterThoeny - 2012-11-22

I updated the spec on top based on discussion in JerusalemReleaseMeeting2012x11x22.

I renamed the topic from WatchAndSubscribePluginDev to WatchlistPluginDev to reflect the new WatchlistPlugin name.

-- PeterThoeny - 2012-12-28

If there are hundreds of users having Main.FirstLastWatchlist, when a topic is moved, can WatchlistPlugin keep up?

-- Hideyo Imazu - 2013-01-11

Good point, performance could become an issue. I have done global renames of 200+ topics using the GlobalReplacePlugin, and performance was not an issue. It might become a bottleneck with thousands of topics. Storing the data in the working area would be faster because/but there is no version control.

-- Peter Thoeny - 2013-01-14

I renamed this topic to lowercase "L" because "watchlist" is more common than "watch list". Also, Wikipedia calls this "watchlist".

-- Peter Thoeny - 2013-02-24

I updated the spec on top to reflect the work-in-progress implementation.

-- Peter Thoeny - 2013-02-24

Idea for enhancement:

  • Option for every watched page to get notified (none (n0), immediate (n1), digest (n2))
  • Watching a new topic will take the default notification option from configure
  • As for implementation, the watched topic list could be enhanced as follows: Topics="Web.TopicA:n0, Web.TopicB:n1, Web.TopicC:n2"

-- Peter Thoeny - 2013-02-27

First version posted, enjoy. This is plugin is sponsored by Wave Systems, thank you!

More idea for enhancement:

  • Support rename of a whole web
  • Error message forwarding after redirect
  • HTML e-mail for digest notification
  • Watch whole web

-- Peter Thoeny - 2013-03-04

At JerusalemReleaseMeeting2013x03x15 we discussed the idea to have a "subscribe to all topics in a web" feature. Question of UI and if unwatch of individual topics needed in "watch all" mode.

-- Peter Thoeny - 2013-03-15

It would be nice to exclude the current author from being notified when he edits a topic he has in his watchlist. Currently you get a lot of emails about your own changes when editing a watched topic.

-- Michael Gulitz - 2013-04-12

>> It would be nice to exclude the current author from being notified when he edits a topic he has in his watchlist. Currently you get a lot of emails about your own changes when editing a watched topic.

Strongly agree/endorse omitting person making the change. The noise level from the current behavior is unacceptable - personally, I consider it a bug.

If there are enough lonely people who insist on seeing their own changes, I suppose it could be a user preference feature. But the default should be 'omit person making the change.' I'd be surprised if there was demand.

>> the idea to have a "subscribe to all topics in a web" feature. Question of UI and if unwatch of individual topics needed in "watch all" mode.

Both are necessary in order to replace MailerContrib. Also, SubscribePlugin would need to become Watchlist-aware so that existing topics would continue to work without conversion. This plugin is a great intro, but long term having two mechanisms is hard to explain to users, and costly to maintain.

>> Watching a new topic will take the default notification option from configure

Perhaps that's a a fallback. But this should be a user preference - with the usual preference stacking: user, web, site, configure. And 'FINAL' rule. It could be put into the watchlist UI rather than the preference topics.

>> A per-user 'vacation' checkbox would be useful. This would disable delivery for people while on-vacation or traveling.

>> For the mobile world (which I have yet to join), it might be useful to have a means to indicate which topics are urgent enough to send to a mobile e-mail address, and which aren't. E.g., allow multiple e-mail addresses, and the 'notify' becomes 'which address(es)' for users with more than one. Think an operations wiki, with topics that are 'policy&procedure', 'meeting schedule', and 'outages'. Not sure if this should be selected by a user per-topic preference scheme, a topic tag (e.g. 'Edits to this topic are a {Crisis, Urgent, Routine} event) or some combination of preference and topic tag. As a user or administrator, I'd want to define which email address(s) get notified by each event class. So a manager might consider a p&p edit page-worthy, while a worker might consider it routine...

-- Timothe Litt - 2014-01-15

I have created a patch to unconditionally eliminate the ant-social spamming of change authors.

Once patched, it will not send immediate mail to the author of a change.

For digest mode, the author of the last change is not notified, as we presume (s)he reviewed all previous changes. (As expected, if the last changes to all watched topics are made by the author, no mail is sent. If the last change to any watched topic is made by others, only those changes appear in the digest.)

I saw no reason to make spam a user preference. If there is a strong argument/concensus that it ought to be, it wouldn't be difficult - though the impact on the UI needs to be considered.


-- Timothe Litt - 2014-01-16

Thanks Timothe, I applied the patch in TWikibug:Item7409 and also Support.SID-01858, and released a new plugin version.

-- Peter Thoeny - 2014-01-16

Watch all, watch new prototyped. See TWikibug:Item7411, apply patch in TWikibug:Item7410 first.

I withdraw the 'vacation mode' idea; preferences 'None - watchlist only' covers that.

Compared to MailerContrib, WatchlistPlugin still doen't have as expressive a specification language (e.g. partial wildcards, add to wildcard, subtract from wildcard). I don't think it ever will.

But someone (not me) might want to write a script that reads the WebNotify page and initializes each user's watchlist with the topics that match. Seems like it would be a good migration tool.

-- Timothe Litt - 2014-01-17

Thank you Timothe for the patches! I'll look into it.

Could you please read the log of yesterday's release meeting? We discussed this feature, KampalaReleaseMeeting2014x01x16.

-- Peter Thoeny - 2014-01-17

Patches ported to HEAD and checked in to svn under TWikibug:Item7411.

This includes some serious bug fixes as well as the Watch All and Watch New prototype.

I did read the release meeting discussion.

-- Timothe Litt - 2014-02-06

Idea: Add new menu item "Show people watching this topic". With this, "Watchlist Changes" should be renamed to "My watchlist changes"

-- Peter Thoeny - 2014-06-25

Idea: Ability to watch a topic and all its children, recursively.

Reason: I built a program management app for a client. Logically if you watch a particular program dashboard, one would expect to watch all changes going on in this dashboard, e.g. changes to all action items, meeting minutes, sprints in it.

-- Peter Thoeny - 2015-05-29

Edit | Attach | Watch | Print version | History: r31 < r30 < r29 < r28 < r27 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r31 - 2015-05-29 - 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.