I've written an extension that does something similar to what you're asking. It's called WikiArticleFeeds:

http://www.mediawiki.org/wiki/Extension:WikiArticleFeeds

It's not exactly what you want - but the syntax is really easy (I'm combining an example with a description of what it does, hope it makes sense):

---------------------------------------------- Text in page before feed - ignored for RSS/Atom purporses. <startFeed />

Any text before the first Heading becomes the description of the feed (this text).

== Item Two ==

Typically it's good practice to list feed items in reverse chronological order (newest on top).

--[[User:Someuser|Someuser]] 08:52, 5 December 2006 (MST)

== Item One ==

The extension picks out the "highest" level Heading as the Item level.

=== So this third-level heading ===

And this text both belong to Item One.

--[[User:Someuser|Someuser]] 08:42, 4 December 2006 (MST)

<endFeed />

Note that both startFeed and endFeed are self-closing tags with no internal text or arguments.

This text (and the preceding note) are again ignored by the extension since they're not in the start/end blocks.

<startFeed /> == Item Three ==

Since this page has two startFeed/endFeed pairs, the resulting RSS/Atom feeds will contain all items from both sections.

This means that you could have a series of disperate feeds that you transclude together on one page for aggregation.

--[[User:Someuser|Someuser]] 18:42, 6 December 2006 (MST)

== Item Four ==

The publication dates and authors for feed items are taken from the first instance of ~~~~ in the item.

Also, you may know that RSS/Atom feeds can have associated URLs. WikiArticleFeeds will look for the first link (internal or external, as long as it's not part of a ~~~~ segment) and use that URL as its own link.

If your feed item has no links, it defaults to [[#ITEM TITLE]] which in this case would be "Item Four".

--[[User:Someuser|Someuser]] 08:48, 7 December 2006 (MST) <endFeed /> ----------------------------------------------

Also, please note that the parsing for feed Items that WikiArticleFeeds does occurs AFTER mediawiki has converted the wikitext into HTML. This means that it (should be) totally agnostic towards templates and custom parser functions (though I haven't extensively tested this yet).

If you decide to use it, I'd love to hear your feedback. Thanks!

btw - if you want to see an example site, I'm currently using this to power my Blog:

http://jimbojw.com/wiki/index.php?title=Blog

-- Jim R. Wilson (jimbojw)

On 2/17/07, Erik Moeller erik@wikimedia.org wrote:

Wikipedia has hundreds of wonderful portals on every imaginable topic. These are perhaps one of the most underexposed treasures on the site. It would be lovely if people could subscribe to a portal feed, or individual "boxes" (typical portal arrangement is into rectangles with different content). Example: http://en.wikipedia.org/wiki/Portal:Free_software

How could this be achieved? One way would be to support an RSS extension that would operate as follows:

1. You put something like

<makefeed> title=Selected article on free software addto=freesoftware.xml addto=freesoftware-sel.xml </makefeed> <feedicon> feed=freesoftware-sel.xml </feedicon>

inside a template, or indeed any page.

2. When a user edits a page, the extension checks for the presence of

<makefeed> in the wikitext. If it is present, it adds a

( ) Add as new item to RSS feed ( ) Update most recent RSS feed item for this page (x) no change

selection to the page, below where the minor edit checkbox is. This selection should only be available to users with a definable permission level (e.g. autoconfirmed).

3. The feeds could be directly updated/written on the disk, in the

images/ directory. In any case, the <feedicon> tag would generate a pretty link to a feed with a given name.

The feed content would be the action=render output for the page where the <makefeed> instruction is found (ideally sans noinclude). It could also include the edit summary.

Given that a feed could be accessed from multiple pages, you could build aggregated feeds (in the above example, freesoftware.xml would be a feed for the whole free software portal) and individual ones (freesoftware-sel.xml would only be the selected article box). You'd have to do some clever scanning of the file on disk to make safe updates, but it shouldn't be too hard.

Any conceptual flaws? Any takers? I think this could really make a big difference for content re-use, not just in the context of Wikipedia. But the portals seem like a particularly attractive target application to me. -- Peace & Love, Erik

DISCLAIMER: This message does not represent an official position of the Wikimedia Foundation or its Board of Trustees.

"An old, rigid civilization is reluctantly dying. Something new, open, free and exciting is waking up." -- Ming the Mechanic

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l