create new tag
, view all tags


I have a "public" web and a "dev" web, in which public topics simply include dev topics so that users can comment in the public web without being able to alter text, and for other reasons, such as more easily maintaining private attachments and private discussion pages in the Dev web (see AuthenticationScenarioForExample).

Includes still work. But TWiki suddenly no longer renders as Public links the relative topic links set in the Dev topics (though attachment links are still translated between webs).

Ie, view/Public/MyTopic includes view/Dev/MyTopic, and Dev/MyTopic contains a relative link like [[RelativeTopic][Relative Topic]] (note the lack of a Web name in the link), but the link from the inclusion in Public renders as "view/Dev/MyTopic".

Both webs are served from the same installation and host, so the base URLs are the same.

I have tried %INCLUDE{"Dev.%TOPIC%" raw="on"}% (the "raw" portion was not previously needed), but links are still rendered as Dev links, not Public links.

Rendering suddenly stopped treating included links as relative and I can't figure out why. We haven't upgraded or applied bug fixes at the time things must have broken, and one plugin we installed, FootNotePlugin, around the time things broke did not alter other scripts or settings. I removed it anyway, but the buggy behavior persisted.


TWiki version: TWikiRelease04x02x00
TWiki plugins: GluePlugin, SpreadSheetPlugin, IfDefinedPlugin, AliasPlugin, BlogPlugin, BreadCrumbsPlugin, CaptchaPlugin, CommentPlugin, DBCachePlugin, EditTablePlugin, ExtendedSelectPlugin, FilterPlugin, FlexWebListPlugin, FootNotePlugin, HeadlinesPlugin, ImagePlugin,Plugins.InterwikiPlugin, JQueryPlugin, MediaWikiTablePlugin, NatSkinPlugin, PreferencesPlugin, RedDotPlugin, RedirectPlugin,Plugins.RenderListPlugin, SendEmailPlugin, SlideShowPlugin,Plugins.SmiliesPlugin, SubscribePlugin, TWikiNetSkinPlugin, TablePlugin,Plugins.TagCloudPlugin, TimeSincePlugin, TinyMCEPlugin, TwistyPlugin, UserInfoPlugin, WysiwygPlugin
Server OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 5)
Web server: Apache/1.3.37
Perl version: Perl 5.8.5
Client OS: Linux 2.6.24-17-generic #1 SMP i686 GNU/Linux
Web Browser: Firefox
Categories: Missing functionality

-- StephenMossbarger - 03 Jun 2008


ALERT! If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

What you describe is actually spec. Assuming you have Public and Dev webs, and MyTopic in Dev web has a link to OtherTopic it will link to the OtherTopic in the Dev web. Now if you include Dev.MyTopic into a topic in the Public web, TWiki adds the "Dev." prefix all topic links that do not have a web specifier. This ensures that links continue to work when included into another web.

I am not sure what caused your installation to suddenly behave differently. Disable all plugins to see if a plugin causes that.

-- PeterThoeny - 04 Jun 2008

Peter, thank you for your quick reply.

I understand the need to continue linking included pages to their original targets, but there is a logical difference between AWeb.ATopic (an absolute form) and ATopic (a relative form) used as a link, and it should be exploitable by TWiki to allow mirroring Webs such that mirrored pages using a relative form automatically link within their own webs.

This is because the HTML relative/absolute URL formats should be respected by TWiki given its requirement to rewrite URLs.

I also understand that there might be security concerns with INCLUDE. However, if both including and included webs are located on the same host, and assuming that security settings are configured as they should be, I would argue that at least an override or translation parameter (a la included attachments) in INCLUDE should be provided to support the syntactical "relative" form of a link as set in the ML. To me, "raw=on" and "disablerewriteurls=on" purport to do this but doesn't.

If a relative ML form is supported, it would allow editors linking naturally in one web to mirror to another, while allowing closed access to the editorial web that is mirrored, for reasons of confidentiality -- without having to tweak Search, Index, and other tools that might expose confidential editing materials to those who just need to read the published material, or lock down individual pages against reader group access.

In this scenario, a user in an editing group publishes a page deliberately simply by creating a new page with a template that automically includes its correlate in the editing web based on its topic name. Users in browsing groups can't create new pages. I also succeeded in creating updated Search pages that returned relative results and worked great (limit search set in Dev by pages existing in Public, then search that set in Dev and return relative results). I wrote a PHP script to generate Apache Basic Auth group files from TWiki group pages to limit browse access to the Dev web (in my opinion, a security option that should be provided by TWiki, to allow/limit browse access while still permitting view access for includes).

Is there some way to accomplish the above scenario with existing 4.2 tools?

PS: I think a Perl script I got from twiki.org to move pages from MediaWiki to TWiki didn't write TWiki page meta headers -- maybe that has something to do with the previous behavior. The 2 webs involved use the naming scheme "MyWeb" and "MyWebDev".

-- StephenMossbarger - 04 Jun 2008

Sorry, closing this after more than 30 days of inactivity. Please feel free to re-open if needed.

-- PeterThoeny - 02 Aug 2008

Change status to:
Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r4 - 2008-08-02 - 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.