create new tag
, view all tags
No such template def TMPL:DEF{PROMPT:AgreementScale}

What is the general consensus on extending %INCLUDE{...}% to include handling interwiki syntax as well. I was thinking of something like:


where the Wiki:RecentChanges would be the URL as given by the interwiki plugin.

Does this sound like a good idea, or should I just go home? I can think of a good reason:

  • Shorthand to include long and complex links (e.g. through cgi's). For example:
    • to the Corporate Knowledge Base server at work. It's a long cgi string whose last element is the id of the article I want to look at. KB:Sc12345 is a lot nicer than the alternative.
    • include a file from a CVS web server. Again long ugly string.

And a few bad reasons/concerns:

  • This creates a link between the INCLUDE variable in the core code and an optional plugin. Is this a good idea philosophically? I don't think the INCLUDE core should be changed to support this.
  • Should the code for this be in its own plugin, say InterwikiIncludePlugin. Are the hooks in the core sufficient to allow me to do something like this?
  • Should it even be another plugin, or an option to the base Interwiki plugin?

Quips, comments, evasions, questions answers?

-- JohnRouillard - 18 Jul 2002

This sounds like an enhancement for the InterwikiPlugin, so this discussion should be in InterwikiPluginDev.

TWiki's variable expansion in TWiki::handleCommonTags does expand the %INCLUDE{...}% before calling the Plugin handler hook, it should be the other way around. However it does not matter since %INCLUDE{ "KB:Sc12345" }% does get expanded internally in TWiki since the topic does not exist, then gets expanded in a second try in the Plugin hook.

-- PeterThoeny - 18 Jul 2002

On a similar note, I was a little surprised to find that wrapping an Interwiki link in double brackets does not do the obvious thing (at least on the 14 April 2002 beta). To expand on John's example, I had expected [[KB:Sc12345]] and [[KB:Sc12345][Article Link]] to create Interwiki links. Instead, I get dangling links to KB:Sc12345. While the first case is not particularly useful, the second one would make it easy to create named external links.

I would not call this a bug necessarily, but it was a surprise behavior to me.

-- DaveBoulton - 18 Jul 2002

This would be nice to have. It would also be good to allow embedding of Interwiki links into the EasierExternalLinking type syntax as suggested by DaveBoulton. This should be possible even within a plugin - the key is developing a regular syntax that allows Includes, Interwiki and external links, with all the various combinations working properly.

Interwiki is a core feature of most Wikis, and is so useful (and relatively simple) that it could reasonably be included in the core.

-- RichardDonkin - 18 Jul 2002

Interwiki plugin is now included in standard install, I cannot imagine a reason why somebody might want to disable it. So if interwiki functionality will be moved into core to easier integration with double [] links, hardly anybody will notice the difference. Only for better. And I also was surprised by quirk like DaveBoulton.

-- PeterMasiar - 18 Jul 2002

This topic seems to have died without any definitive resolution. I need both the Interwiki for INCLUDE and the Interwiki expansion within

. Is there anyway to achieve this with the Jan-2004 alpha?

-- KellySetzer - 24 Jan 2004

The short answer is no - not without changing the code. You'll need to add in an extra plugin hook near the beginning of handleIncludeFile that checks with plugins if they want to manipulate the object being included. (Passing through $theAttributes variable makes sense) The Interwiki plugin would need to be changed to pass back just the URL (rather than the rendered version the plugin currently passes back), then test, and in order to get this into TWiki you need to follow the PatchGuidelines laid down, document the approach taken on either this page or a new one (since the actual feature is a new plugin hook) and also add the changes to the InterwikiPluginDev page.

Also you should lay out in detail how you intend to do this on the various topics before implementing the code - as detailed on ReadmeFirst and wait for feedback - preferably including an active CoreTeam member. Only if the feature is assessed as suitable for inclusion into twiki should you implement the code and post it up here. (Unless the process has changed recently)

An alternative approach is to just go ahead, implement and post up a patch, and hope that it's accepted without changes and without breaking your content. This is quicker, but could lead to the situation that your wiki has features in that new releases do not, which means you end up running an incompatible codebase to TWiki.org.

Various tests that show that the method outlined above doesn't work can be found here .

If you need help with the implementation posting questions/queries here is the sensible thing to do.

-- MS - 24 Jan 2004

The Plugin can implement that without requiring any changes to the core code. The outsidePREHandler callback can simply scan for [[knownSites:page][label]] and [[knownSites:page]] patterns, and expand them to [[http://site.com/resolved/Interwiki/link/to/page][label]] links.

-- PeterThoeny - 05 Feb 2004

The InterwikiPlugin in the latest TWikiAlphaRelease supports now square bracket links, see InterWikiLinksDoNotWorkInBracketNotation.

-- PeterThoeny - 05 Feb 2004

I too would have expected




to be equivalent.

Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r11 - 2004-11-04 - MartinCleaver
  • 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.