Tags:
create new tag
view all tags

SID-01208: Topic parenting confusion...

Status: Answered Answered TWiki version: 4.2.3 Perl version: 5.8.8
Category: CategoryError Server OS: fedora Last update: 14 years ago

My production TWiki is 4.2.3 (with a few modifications).

I just installed TopMenuSkin - nothing fancy, no customizations.

In a web that is unique (e.g., not Main, not TWiki), I discovered that the Parent breadcrumbs were confused. They pointed to the correct topic, but on another (I think system) web - which obviously doesn't exist.

This web doesn't have a custom top bar, so I suspect it's getting the parent name relative to itself, not the base topic.

This seems to come from a %META directive.

I tried the trunk version of %META, with the same results.

This seemed curious. So I looked at all the metadata in my webs, and in every case the metadata looks like: %META:TOPICPARENT{name="<topicname>

If I run a SED script over the topics and change the TOPICPARENT to Webname.TopicName, sure enough the breadcrumbs work properly.

So, now the question is: what's broken?

I looked on develop.twiki.org, and sure enough parent names seem to include the webname.

Is all the metadata (including distribution topics) broken in existing twikis?

Well, if I leave the webname in the parent, all my %SEARCHes that work off "parent.name" are broken, because apparently %SEARCH doesn't expect the webname.

Bottom line: What should be fixed? Do I correct the metadata in all topics on all my webs? Won't that break existing %SEARCHs (like webchanges)? Is it %META? Is it the TopMenuSkinTopicMenu? Is a custom topic menu mandatory for all webs?

What's the right solution? And is there a patch?

Thanks.

-- TimotheLitt - 2011-06-21

Discussion and Answer

This is an early design flaw that should have been rectified a long time ago: It is possible to define a breadcrumb that jumps across webs.

I was asking to fix that, but some folks (long gone now) worked against fixing this. Here is what I think breadcrumbs should be:

  • A breadcrumb is a logical path within a web to the home of the web.

That is, META:PATENT should only contain a topic name that resides in the same web, it should never contain a web name.

So by all means, let's fix this once and for all. If inclined, please create a bug item and supply a patch.

-- PeterThoeny - 2011-06-21

Old discussions are at AvoidParentAcrossWebs.

-- PeterThoeny - 2011-06-21

I'm not sure we're on the same page in this discussion, so let me clarify.

The previous discussions at AvoidParentAcrossWebs seem to center on the problem of moving topics across webs and whether cross-web parenting is allowed. Those are valid concerns, but not my immediate problem. None of my topics have moved. And none are parented cross-web.

My problem is that in the 'Special' web, breadcrumbs in TopMenuSkin point to the corresponding topic in TWiki. E.g. Special.Child's P crumb has an href of TWiki.Child rather than Special.Child.

Looking further into this, it's not at all obvious how this was supposed to work. TopMenuSkinTopicMenu contains

  * %META{
 "parent"
 nowebhome="on"
 prefix="<img src='%PUBURL%/%SYSTEMWEB%/TopMenuSkin/menu-right.png' alt='' width='8' height='22' />$n   * "
 separator="$n   * <img src='%PUBURL%/%SYSTEMWEB%/TopMenuSkin/menu-right.png' alt='' width='8' height='22' />$n   * "
 format="<a href='%SCRIPTURL{view}%/$web/$topic' title='$topic (parent topic)'>P</a>"
}%

%META gets the metadata for the web.topic that contains the %META - TopMenuSkinTopicMenu. It then follows the parent chain from $meta->get( 'TOPICPARENT' ) up. But the breadcrumb is supposed to refer to %BASEWEB%.%BASETOPIC%, not TopMenuSkinTopicMenu. And you can't get there from here because %META will only return data on the topic that contains it. This is a fundamental design flaw in %META.

So I don't understand how these breadcrumbs work at all in TopMenuSkin. They're following the skin's ancestry, not the displayed topic's. And if they seem to work, it's an accident (or I don't follow the code.)

Here is my solution, in two parts:

  • Part 1: Teach %META to return data from a specified web and topic.
--- ../../lib/TWiki.pm~ 2011-06-21 01:04:12.000000000 -0400
+++ ../../lib/TWiki.pm  2011-06-21 11:03:11.000000000 -0400
@@ -3903,16 +3903,19 @@
 sub META {
     my ( $this, $params, $topic, $web ) = @_;

     my $meta  = $this->inContext( 'can_render_meta' );

     return '' unless $meta;

     my $option = $params->{_DEFAULT} || '';
+    $web = $params->{web} if $params->{web};
+    $topic = $params->{topic} if $params->{topic};
+
     my $result = '';

     if( $option eq 'form' ) {
         # META:FORM and META:FIELD
         $result = $meta->renderFormForDisplay( $this->templates );
     } elsif ( $option eq 'formfield' ) {
         # a formfield from within topic text
         $result = $meta->renderFormFieldForDisplay( $params->get('name'), '$value', $params );
  • Part 2 - Teach TopMenuSkin to ask about the BASEWEB.BASETOPIC instead of itself. (Two added lines marked with '++'. for clarity)
  * %META{
 "parent"
++ web="%BASEWEB%"
++ topic="%BASETOPIC%"
 nowebhome="on"
 prefix="<img src='%PUBURL%/%SYSTEMWEB%/TopMenuSkin/menu-right.png' alt='' width='8' height='22' />$n   * "
 separator="$n   * <img src='%PUBURL%/%SYSTEMWEB%/TopMenuSkin/menu-right.png' alt='' width='8' height='22' />$n   * "
 format="<a href='%SCRIPTURL{view}%/$web/$topic' title='$topic (parent topic)'>P</a>"
}%
  • Part 3 is an exercise for the reader - update the %META documentation to show the web and topic parameters.

Conclusions

  • These small patches fix my problem, but do not address the architectural issue of topics crossing webs. I have my hands full, so that one is not for me.

  • I do not have an explanation for why on twiki.org's sandbox, the metadata for Sandbox.TestTopic5 (?raw=debug) contains:
META:TOPICPARENT{name="Sandbox.WebStatistics"}
(I had to remove the % because even under verbatim, META data is extracted. I remember complaining about this before and getting nowhere.)

Note it's Sandbox., not bare Webstatistics. But you say (and my older wiki agrees) that TOPICPARENT should always be web-relative.

So I remain confused. No magic - I just created an autoinc topic, used more topic actions -- set topic parent, and looked at it.

  • In any event, fixing %META seems like a good thing - this isn't the first time I've wanted metadata from another topic. And that makes it possible to fix TopMenuSkin.
  • TopMenuSkin requires the indicated patch as well.

  • The deeper architectural issues need to be addressed - but not by me.

-- TimotheLitt - 2011-06-21

The %META change may need to be expanded - consider that %META will return form data items. I didn't follow the code to make sure that it checks that the user has access to everything it touches. If not, there's a security concern.

But the issue with TopMenuSkin breadcrumbs needs to be fixed, and this still seems the best (only reasonable?) way to fix it.

-- TimotheLitt - 2011-06-21

Ah, indeed, that was a design flaw. Workaround created for TWiki-5.0 in TWikibug:Item6438

-- PeterThoeny - 2011-06-21

I added this comment to the TopMenuSkin installation instructions for TWiki-4.2 and TWiki-4.3:

    • Apply patch TWikibug:Item6438 so that breadcrumb links point to the current web instead of the TWiki web.

-- PeterThoeny - 2011-06-21

      Change status to:
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.
SupportForm
Status Answered
Title Topic parenting confusion...
SupportCategory CategoryError
TWiki version 4.2.3
Server OS fedora
Web server apache
Perl version 5.8.8
Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r4 - 2011-06-21 - 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-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.