Basic XML Feed support for watchlist (implementation idea: token)
Closed, ResolvedPublic

Description

Author: foenyx

Description:
Add a basic XML Feed support for the user's watching list.
Each item of the user watching list become an Item of the feed, with the date,
the author and the url.


Version: unspecified
Severity: enhancement
URL: http://meta.wikimedia.org/wiki/Syndication_feeds

bzimport added a project: MediaWiki-Watchlist.Via ConduitNov 21 2014, 7:08 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz471.
bzimport created this task.Via LegacySep 13 2004, 7:08 AM
bzimport added a comment.Via ConduitSep 13 2004, 7:13 AM

foenyx wrote:

a basic implementation of the XML Feed for watch list

It's my first work on mediawiki, so I guess it's not bug-free. But it worked
quite well in my local mediawiki.

The main limitation is that user need to be logged into his account to access
it, but if the feed agreggator is included with the browser it should work.

Attached: xmlFeedSupportSpecialWatchlist.txt

brion added a comment.Via ConduitOct 12 2004, 6:28 PM

The tricky part with the watchlist is authentication; this patch doesn't seem to
address that yet.

brion added a comment.Via ConduitJan 7 2005, 12:45 AM
  • Bug 1265 has been marked as a duplicate of this bug. ***
brion added a comment.Via ConduitJan 11 2005, 9:36 AM
  • Bug 1303 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitMay 9 2005, 4:46 PM

zigger wrote:

*** Bug 2120 has been marked as a duplicate of this bug. ***

brion added a comment.Via ConduitJun 2 2005, 7:31 PM
  • Bug 2293 has been marked as a duplicate of this bug. ***
Wikinaut added a comment.Via ConduitJun 24 2005, 8:53 PM

Support; I like the idea.

The following amendment would be very useful and shorten the RSS feed:

I propose to have a special RSS FEED for only those items in one's watchlist,
which have UNSEEN changes. These are those changed (watched) pages, for which an
enotif have been sent to the watching user; the information is already available
in the Enotif versions ( 1.5 ) in the table watchlist - for each user.

bzimport added a comment.Via ConduitJul 29 2005, 10:29 PM

rowan.collins wrote:

Just for ease of reference:

  • One previous discussion

http://mail.wikipedia.org/pipermail/wikitech-l/2004-December/thread.html#26558

  • Previous discussions have generally come to the conclusion that the most

widely usable solution would be to let the user opt in in preferences to make
their watchlist public, and then generate a secret random token that has to go
in the URL to view it. (Noting that this provides only imperfect protection,
since the random string will be transmitted "in the clear" through any number of
proxies, logs, etc, and of course stored by any aggregator services used) This
way all RSS readers will be able to view the watchlist, people who don't use RSS
can have their watchlist completely private, and even people who *do* can have
it "mostly private".

bzimport added a comment.Via ConduitJul 30 2005, 3:35 AM

triddle wrote:

Perhaps it could be done both ways; they are not mutually exclusive.

bzimport added a comment.Via ConduitAug 2 2005, 5:27 PM

rowan.collins wrote:

(In reply to comment #9)

Perhaps it could be done both ways; they are not mutually exclusive.

Um, both of which ways? Do you mean Foenyx's "hope they already have a cookie"
approach and my "opt in and have a pseudo-secret URL" approach? Yes, I guess you
could easily have both, although I do think the former is likely to be somewhat
less useful.

bzimport added a comment.Via ConduitAug 3 2005, 12:54 AM

triddle wrote:

Yes, that is both of the ways I was refering to. Since the pesudo-secret URL isn't as graceful (but obviously is one of
the few ways to get non-cookie auth to work) as a browser with built in RSS abilities it seems wise to support both.
Safari and the new IE support RSS; I don't think its a stretch to assume that Mozilla and the other browsers will be
following suit soon. Is it a good idea to short-change those browsers to make up for the defficiencies in other RSS
readers? Granted the ability to view some random person's watchlist contents is of little value for nefarious activities
but is it hard to support them both? The watchlist code will have to modified to output RSS or HTML anyway; the
pseudo-secret URL is simply another authentication mechanism that is localized to readonly access to the RSS
watchlist. It seems to me that once you solve the pseudo-secret URL you already solved the RSS cookie problem to the
majority extent.

Tyler

bzimport added a comment.Via ConduitAug 3 2005, 7:11 PM

rowan.collins wrote:

Ah, fair enough. Just to be clear, Firefox supports RSS feeds out-of-the-box
too; there's probably extensions for Mozilla Suite, and who knows what the new
SeaMonkey will end up with. But anyway, the sense in which that approach is kind
of hacky is that it's not really a "deficiency in other RSS readers" - they're
not web browsers, so they don't support rendering and submitting an HTML form
(currently the only way of logging in). Who knows whether or not they'd support
cookies in general, but the question is how to do the authentication in the
first place.

The point of the pseudo-secret URL is that you don't ever need to go through a
username and password challenge inside the RSS reader - if your reader's a
browser, you can just use the existing login form fine (as Foenyx's patch
already does) so you don't have to do anything special beyond rendering the XML.

But, to get back to the point - no, I see no reason not to make it so that if
the Watchlist-feed is requested without the magic URL parameter, it sees if
there's a login cookie set and shows the logged in user's watchlist, just like
the non-feed version would. But it would be nice to have the more flexible
version ready before we enable it, so that it can be available to everyone.

Wikinaut added a comment.Via ConduitAug 31 2005, 12:41 AM

(In reply to Brion's comment #2)

The tricky part with the watchlist is authentication

Implementation idea:
Brion, perhaps you can easily re-use some of the lines you wrote for
"Confirmemail", I mean the token-method:

  • any user can request a token (rss/rdf-link incl. the token) to be sent to his

e-mail address

  • link example:

http://server/wike/index.php/Special:Watchlist/feed=rss/unseen/e45e0e1a1a2148b5719437c00d92fe41

Only watchlisted page titles, page edit time and edit summaries of pages having
unseen changes (*) are then delivered as an RSS feed.
(*) these are the bolded page titles in watchlists of mediawiki >= 1.5 versions

How do you like that ?

bzimport added a comment.Via ConduitSep 16 2005, 6:21 PM

avarab wrote:

I don't see why email addresses need to get involved, just displaying the token
in the user preferences should be enough.

bzimport added a comment.Via ConduitSep 16 2005, 6:37 PM

rowan.collins wrote:

Discussion about this has broken out on the mailing list again; future readers
should read this section of the archive:
http://mail.wikimedia.org/pipermail/wikitech-l/2005-September/thread.html#31577
[And please *do* read the previous discussions, to avoid raising points which
have already been discussed]

Wikinaut added a comment.Via ConduitSep 17 2005, 7:52 AM

(In reply to Rowan's comment #14)

I don't see why email addresses need to get involved, just displaying the token
in the user preferences should be enough.

Yes. of course, there is no need to _mail_ a pseudo-secret RSS feed link. It
will be sufficient and handy to show the pseudo-secret key for example on the
Special:Watchlist of the current user.

Example:
http://server/wike/index.php/Special:Watchlist/feed=rss/unseen/e45e0e1a1a2148b5719437c00d92fe413428124566

Rowan: I have this on my to-do list.

bzimport added a comment.Via ConduitOct 18 2005, 8:00 PM

mike wrote:

I've reworked http://meta.wikimedia.org/wiki/Syndication_feeds with the hopes
further rallying toward implementation. This bug is linked along with other
existing conversation. Let me know if there is any other way I can help ;)

Wikinaut added a comment.Via ConduitOct 18 2005, 8:18 PM
  • Bug 3167 has been marked as a duplicate of this bug. ***
Wikinaut added a comment.Via ConduitOct 19 2005, 7:55 AM

http://meta.wikimedia.org/wiki/Syndication_feeds --> very useful overview page,
thanks. I have added a link on my Enotif "Wishlist" page which is
http://meta.wikimedia.org/wiki/Email_notification_to-do_list

Wikinaut

Wikinaut added a comment.Via ConduitDec 21 2005, 12:26 AM

Is anyone working on an implementation of that ? Would be nice to have....

brion added a comment.Via ConduitMar 7 2006, 3:38 AM
  • Bug 5188 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitMar 7 2006, 4:06 AM

zach wrote:

Erm yes, I really should have posted the patch here rather then file a new bug.
Terribly sorry about that...

All: I posted a new patch and discussed some thoughts about this at bug 5188.
I'd really like to see this feature happen, so I'd appreciate your comments.

bzimport added a comment.Via ConduitMay 14 2006, 12:13 PM

adziura+wiki wrote:

I think that will be very useful.
Gmail have a feed (Atom) with new mails for users. And private is saved.

Nux added a comment.Via ConduitMay 16 2006, 12:21 PM

Here, here! For pseudo-secret URL :). That would be cool. The URL could be
changed monthly or on demand. to give more security.

brion added a comment.Via ConduitJun 19 2006, 7:07 AM
  • Bug 6370 has been marked as a duplicate of this bug. ***
PleaseStand added a comment.Via ConduitJul 2 2006, 9:17 PM

Or the URL could have a user-specifiable password, SEPERATE from the main
password, such as:

http://server/wiki/Special:Watchlist/User?watchpw=secret&feed=atom

(If the user has a login cookie, the following should also be able to be used:)

http://server/wiki/Special:Watchlist?feed=atom

Similar for rss.

bzimport added a comment.Via ConduitJul 23 2006, 4:27 AM

jay.corrales wrote:

I would like to propose an out-of-the-box idea.

What about having the RSS reader do all the work? When someone wants to "watch
a page", why couldn't they just add the history page as an RSS link? Would it
be easier to have the wiki software create an RSS-format history page for every
entry, maybe this can also be what the wiki uses to display the history page, or
maybe it can just be a mirror page with less information and a link to the edits?

I suppose going further, you could have your own RSS feeder that aggregates all
your watched wikipedia entries along with your other feeds. Most RSS feeders
also allow you to categorize your feeds (such as bloglines) so you could make a
wikipedia category in which you could add/subtract your wikipedia history feeds.

I am mainly interested in the feature for watching articles on Wikipedia, but I
figure this may also be helpful for other wikis.

Nux added a comment.Via ConduitJul 24 2006, 9:09 AM

This is already available - you can watch like that every single article when
you click on it's history. But having hundreds of channels in RSS reader... I
think I would have to pass that - beside to much trouble of adding them anyway...

But it would be cool if an RSS feed would be available for linked articles -
this way I could watch whole categories with RSS, which would be really cool :).

bzimport added a comment.Via ConduitAug 20 2006, 2:44 PM

logixoul wrote:

(In reply to comment #28)

This is already available - you can watch like that every single article when
you click on it's history. But having hundreds of channels in RSS reader...

... I have no problems with that, and I don't see how anybody would. So I'm in favor of marking this bug INVALID.

bzimport added a comment.Via ConduitAug 20 2006, 3:17 PM

conti wrote:

(In reply to comment #29)

... I have no problems with that, and I don't see how anybody would. So I'm in

favor of marking this bug INVALID.
When you have about 300 articles in your Watchlist (nothing unusual for alot of
Wikipedians), you have to add 600 (articles + talk pages) feeds, that's not a very
good alternative solution. So I'd still like to see this feature.

bzimport added a comment.Via ConduitAug 21 2006, 3:52 PM

jay.corrales wrote:

I guess it would come down to the efficiency of being able to add a feed to your
news feeder and if you news feeder allows you to organize links. Now that you
mention it, I don't think newsfeeders are really there yet.

If it were as simple as the click of a button to add the feed, that would be
great, but then wikipedia would have to add all the different types of newsfeed
buttons to make that work. Copying the link and adding it to an add news feed
dialog box or web form is a bit more of a pain.

If the news feeder allows organization of rss feeds into groups or folders, you
could group all the feeds into a category named Wikipedia or Watchlists, but I
agree that it would be a pain if you are watching a bunch of articles and your
newsfeeder doesn't allow categories or if it is cumbersome to add them, which I
think describes most.

If wikipedia adds newsfeed functionality, it would certainly make it easier for
a wikipedian if they can just add one feed named "Wikipedia Watchlist".
Wouldn't it also cut down on bandwidth use? If a wikipedian loads a feed
instead of the whole website to check their watchlist, I would think it would
cut down on load.

There could also be links in the RSS feed directly to the article, which would
make it so the user wouldn't have to load the main page and type in the article
name.

bzimport added a comment.Via ConduitSep 4 2006, 9:44 PM

wmahan_04 wrote:

Implementation

I implemented this as described in comment #8.
Cookie-based authentication as discussed in comment #11
is also supported.

With the patch, when $wgSyndicateWatchlists is true,
users who enable an option in their preferences can
share their watchlists using pseudo-secret URLs like:

http://wiki.example.com/wiki/index.php?title=Special:Watchlist&feed=rss&user=Wmahan&token=906d1d49f1f624775c33d033038181fe&limit=250

Once created, a watchlist token never expires but may
be disabled or reset to a new pseudorandom value using
the preferences interface.

Feeds showing only unseen changes as proposed in
comment #7 are supported; append "&unseen=1" to the
URL.

Notes:

  • The patch adds a column to the "user" table called

"user_watchlist_token" to store the user's
pseudo-secret token.

  • At the moment the feeds do not support the standard

watchlist filtering options (show edits in the last X
days, hide minor edits, etc.). That wouldn't be too
hard to add, but I think feed aggregators can probably
provide some of the same functionality.

  • The feeds are not cached; as I suggested at bug 4182,

that could be done in Feed.php to reduce duplicated
code.

  • I started this before realizing there is already a

patch at bug 5188. Unlike that one, this doesn't
create a new special page, and it doesn't add a DB
column and other infrastructure to rate-limit requests;
I was planning on handling that by caching.

attachment 471.diff ignored as obsolete

bzimport added a comment.Via ConduitSep 4 2006, 10:36 PM

wmahan_04 wrote:

Implementation, including schema change

Attached: 471-2.diff

bzimport added a comment.Via ConduitSep 14 2006, 3:34 AM

dto wrote:

*** Bug 7316 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitDec 3 2006, 12:20 AM

rowan.collins wrote:

I notice that the current work on an API includes a working implementation of
watchlist-as-rss, using login session tokens from cookies or an explicit login.
See http://meta.wikimedia.org/wiki/API and check it out at
http://en.wikipedia.org/w/api.php?action=feedwatchlist

Obviously, this doesn't solve the central issue under discussion here, of how to
have a stateless authentication for that one action, but it might be worth
considering if there's merit in implementing it as part of that API rather than
through the standard access route...

bzimport added a comment.Via ConduitJan 30 2008, 6:42 AM

sjekjr wrote:

regarding Wil's solution : can it be applied to MediaWiki proper? It would go best with a side of warm milk and a section of the user preferences (or MediaWiki: namespace strings) to define what sort of/how much diff and editor information to include in the rss update. One nice thing about a proper feed is that there is room to include more information than the single line the watchlist gives.

bzimport added a comment.Via ConduitMay 5 2008, 10:55 AM

Wiki.Melancholie wrote:

You might be interested in manually making a watchlist page that will have a XML feed then!

See https://bugzilla.wikimedia.org/show_bug.cgi?id=5220#c21 - bug 5220 - for that.

Catrope added a comment.Via ConduitSep 6 2008, 9:54 PM

Removing bot-interface keyword as the API now provides a bot interface for watchlists.

siebrand added a comment.Via ConduitFeb 2 2009, 11:42 AM

Changing component to "Watchlist"

bzimport added a comment.Via ConduitApr 23 2009, 11:10 PM

ezyang wrote:

*** Bug 18570 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitApr 24 2009, 3:44 PM

ezyang wrote:

Patch is three years old and doesn't apply anymore, removing patch status.

bzimport added a comment.Via ConduitApr 24 2009, 4:54 PM

ezyang wrote:

Initial implementation comments:

  • There has never been a syndicated Special page in MediaWiki's codebase before, and the existing code assumes that the corresponding feed is accessible at Special:Watchlist?feed=rss, which is not the case (you have to use the feedwatchlist API URL). There are two methods of going about solving this: one is generating a fake request from Special:Watchlist code to feedwatchlist and returning the code directly, and using the regular syndication link calculation code, and the other is special-casing Special:Watchlist in OutputPage. I would prefer the former, but both are fairly hacky.
  • My preferred implementation approach is to assume that the user is using a feedreader in their browser. If an unauthenticated user hits the RSS feed, we publish an item explaining to them that they are not logged in, and give them instructions on how to enable the "public" (should be phrased carefully) feed that they can directly give to their feedreader. This means that the discovery cost is minimal: a user can use the usual mechanism for subscribing to a feed, without having to have had twiddled a preference beforehand.
  • The token to be used can be cast as either a watchlist token, or a read token: that is, a token that can be used to read any private data on MediaWiki (which is really just watchlist). I prefer the latter.
bzimport added a comment.Via ConduitApr 24 2009, 6:58 PM

ezyang wrote:

convert watchlist to class

This initial patch converts watchlist into a class. This will make implementing Special:Watchlist?feed=rss simpler.

Attached: watchlist.diff

bzimport added a comment.Via ConduitApr 24 2009, 7:00 PM

ayg wrote:

(In reply to comment #42)

  • There has never been a syndicated Special page in MediaWiki's codebase before, and the existing code assumes that the corresponding feed is accessible at Special:Watchlist?feed=rss, which is not the case (you have to use the feedwatchlist API URL). There are two methods of going about solving this: one is generating a fake request from Special:Watchlist code to feedwatchlist and returning the code directly, and using the regular syndication link calculation code, and the other is special-casing Special:Watchlist in OutputPage. I would prefer the former, but both are fairly hacky.

Ideally this would be broken out into nice, clean, reusable code. I ran into this problem too when I was trying to make page history feeds available on article view instead of just page history view.

  • My preferred implementation approach is to assume that the user is using a feedreader in their browser. If an unauthenticated user hits the RSS feed, we publish an item explaining to them that they are not logged in, and give them instructions on how to enable the "public" (should be phrased carefully) feed that they can directly give to their feedreader. This means that the discovery cost is minimal: a user can use the usual mechanism for subscribing to a feed, without having to have had twiddled a preference beforehand.

Assuming that the feed reader supports logins seems like a really bad idea, TBH. A ton of people use feed readers like Google Reader or whatnot instead of their browser, and this will break horribly AFAICS, unless I'm missing something. I'm not even sure a majority of users use their browser for feed reading -- I don't, anyway.

scfc added a comment.Via ConduitApr 29 2009, 11:38 AM

(In reply to comment #42)

[...]

  • My preferred implementation approach is to assume that the user is using a feedreader in their browser. If an unauthenticated user hits the RSS feed, we publish an item explaining to them that they are not logged in, and give them instructions on how to enable the "public" (should be phrased carefully) feed that they can directly give to their feedreader. This means that the discovery cost is minimal: a user can use the usual mechanism for subscribing to a feed, without having to have had twiddled a preference beforehand. [...]

What happens when the authentification cookie or whatever of
a user expires? It should be ensured (and tested :-)) that
in this case the items already received are not affected and
that afterwards, "new" items are added even if they are
older than the "not logged in" message.

Catrope added a comment.Via ConduitApr 29 2009, 12:40 PM

(In reply to comment #45)

(In reply to comment #42)
> [...]
> * My preferred implementation approach is to assume that the user is using a
> feedreader in their browser. If an unauthenticated user hits the RSS feed, we
> publish an item explaining to them that they are not logged in, and give them
> instructions on how to enable the "public" (should be phrased carefully) feed
> that they can directly give to their feedreader. This means that the discovery
> cost is minimal: a user can use the usual mechanism for subscribing to a feed,
> without having to have had twiddled a preference beforehand.
> [...]

What happens when the authentification cookie or whatever of
a user expires? It should be ensured (and tested :-)) that
in this case the items already received are not affected and
that afterwards, "new" items are added even if they are
older than the "not logged in" message.

Any sane implementation will have a &from= parameter such that only results on or after the timestamp in from= are listed. If the client keeps track of the timestamp of the last edit it received, it can use this to get all results (common RSS clients don't actually do this, AFAIK, but it should be possible). *Never*, *ever*, should the cutoff time be based on cookie or login age; nobody suggested that BTW.

bzimport added a comment.Via ConduitApr 29 2009, 5:20 PM

ezyang wrote:

Should feed-readers Do The Right Thing(TM) when feed items have properly unique IDs attached to them?

Anyway, I'm blocking on getting the Watchlist file converted. I suppose I could make the patch w/o having Watchlist as a class.

Wikinaut added a comment.Via ConduitApr 29 2009, 5:46 PM

(In reply to comment #46)

Any sane implementation will have a &from= parameter such that only results on
or after the timestamp in from= are listed. If the client keeps track of the
timestamp of the last edit it received, it can use this to get all results

The watch list has (the watched pages have) "last visited" timestamps (for each user), thus no client action is needed.

bzimport added a comment.Via ConduitJul 24 2009, 1:24 AM

ayg wrote:

I've committed a fix in r53703. It's token-based; you set a magic value in your preferences. Currently there's no UI that actually exposes the link location (I'm sure that will be added by someone shortly), but if you set the token, the links look like this:

api.php?action=feedwatchlist&list=watchlist&wluser=Simetrical&wltoken=91c1ef18279f9c24ccf67a79e899ae4d2a3201bc

waldyrious added a comment.Via ConduitAug 11 2009, 9:24 AM

[[Special:Version]] shows that the current MediaWiki revision live on the English Wikipedia is r54757; I assume, therefore, that this is already available. However, I can't find any option in my preferences that allows me to set the token as specified in the previous comment. How should this be done? Or was this feature disabled for some reason?

werdna added a comment.Via ConduitAug 11 2009, 9:32 AM

(In reply to comment #50)

[[Special:Version]] shows that the current MediaWiki revision live on the
English Wikipedia is r54757; I assume, therefore, that this is already
available. However, I can't find any option in my preferences that allows me to
set the token as specified in the previous comment. How should this be done? Or
was this feature disabled for some reason?

No, it's not been deployed yet. You can no longer use the revision number to determine which software is running on the cluster (look at the wmf-deployment branch)

brion added a comment.Via ConduitSep 28 2009, 7:16 PM

Reopening, as there's still no UI for doing this which makes it nigh-useless. :)

brion added a comment.Via ConduitSep 28 2009, 7:16 PM
  • Bug 20840 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitSep 29 2009, 1:21 PM

ayg wrote:

Well, the summary does say "basic". :) We could just file separate bugs for improvements beyond this, IMO. But it doesn't make much difference.

waldyrious added a comment.Via ConduitSep 29 2009, 2:29 PM

I can see a "Watchlist token" in the watchlist section of my preferences. I suppose that can be considered a basic UI. The link to the feed is not shown, though, and after entering it manually in the url following Simetrical's example, I get an error: "Error (wlnotloggedin): You must be logged-in to have a watchlist". Even though I am logged in to enwiki, I tried doing api.php?action=login&lgname=user&lgpassword=password, but I get the error "The login module requires a POST request". How is this supposed to work?

werdna added a comment.Via ConduitSep 29 2009, 7:44 PM

In theory, we should be showing the "feed" icons on the watchlist at the very least, and adding <link rel> tags for them.

Unfortunately, the way that feeds were implemented was incredibly short-sighted, and assumes that the only URL that you could possibly think of for a feed would be with a suffix on the existing URL.

What we need to do first is to overhaul this feed system (see bug 20692). This is something I could possibly look into.

bzimport added a comment.Via ConduitSep 29 2009, 8:06 PM

ayg wrote:

Couldn't you manually generate the <link>s? Surely the feed class is only necessary for generating the feeds, not outputting links to them.

werdna added a comment.Via ConduitSep 29 2009, 8:09 PM

(In reply to comment #57)

Couldn't you manually generate the <link>s? Surely the feed class is only
necessary for generating the feeds, not outputting links to them.

It's the outputting of the <link>s by the skin, and the display of them in the sidebar, that is at issue, not the generation of the feeds.

This is the mechanism that sucks.

bzimport added a comment.Via ConduitSep 30 2009, 3:06 PM

ayg wrote:

You could get <link>s in the header without putting them in the sidebar easily enough, though, by just using one of our several bazillion scattered, poorly-named methods for directly injecting stuff into the <head> in various confusing and massively overlapping ways. Ideally we'd have a single feed per page in most cases, IMO, with the RC feed (currently on every page IIRC) only available on Special:RecentChanges, and some way to get both the icons and the <link>s working in a unified fashion, via a rewrite of the feed system . . . but for now, you can just have multiple <link rel="alternate">s on the page pointing to unrelated feeds. That's permitted, AFAIK, or anyway we already do it for history pages.

werdna added a comment.Via ConduitSep 30 2009, 3:10 PM

(In reply to comment #59)

You could get <link>s in the header without putting them in the sidebar easily
enough, though, by just using one of our several bazillion scattered,
poorly-named methods for directly injecting stuff into the <head> in various
confusing and massively overlapping ways. Ideally we'd have a single feed per
page in most cases, IMO, with the RC feed (currently on every page IIRC) only
available on Special:RecentChanges, and some way to get both the icons and the
<link>s working in a unified fashion, via a rewrite of the feed system . . .
but for now, you can just have multiple <link rel="alternate">s on the page
pointing to unrelated feeds. That's permitted, AFAIK, or anyway we already do
it for history pages.

I'd much rather do the job properly, and spend the half hour rewriting the feed exposure system.

bzimport added a comment.Via ConduitSep 30 2009, 4:52 PM

ayg wrote:

I doubt it will only take half an hour, but if you're really going to do it soon, then certainly that would be a better solution.

werdna added a comment.Via ConduitSep 30 2009, 5:41 PM

Feed URLs are now exposed on the watchlist page, if the user has set a token (r57119).

Would be nice if we could auto-set the token at some point instead of requiring that strange setup. I'm thinking that on loading the watchlist we could set it if it hasn't already been set.

brion added a comment.Via ConduitSep 30 2009, 5:46 PM

(In reply to comment #62)

Would be nice if we could auto-set the token at some point instead of requiring
that strange setup. I'm thinking that on loading the watchlist we could set it
if it hasn't already been set.

That should be very straightforward -- I endorse this!

werdna added a comment.Via ConduitSep 30 2009, 5:58 PM

(In reply to comment #63)

(In reply to comment #62)
> Would be nice if we could auto-set the token at some point instead of requiring
> that strange setup. I'm thinking that on loading the watchlist we could set it
> if it hasn't already been set.

That should be very straightforward -- I endorse this!

Done in r57124.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.