Bug: attach does not render TWiki syntax

The attach perl script which comes with the distribution does not render TWiki syntax when viewing the table on the attach page. Here is the lines as they were originally in the attach file:

• $tmpl = &TWiki::handleCommonTags( $tmpl, $topic );
• $tmpl = &TWiki::getRenderedVersion( $tmpl );
• $tmpl = &TWiki::handleMetaTags( $webName, $topic, $tmpl, $meta );

This was corrected by re-arranging the lines as such:

• $tmpl = &TWiki::handleCommonTags( $tmpl, $topic );
• $tmpl = &TWiki::handleMetaTags( $webName, $topic, $tmpl, $meta );
• $tmpl = &TWiki::getRenderedVersion( $tmpl );

Test case

Environment

-- ShawnBradford - 22 Feb 2002

Follow up

If a test case could be provided show how to trivially duplicate this problem it would be worth while - BeijingRelease based code still has the first ordering of code listed above. Is there a reason that this re-rodering is inappropriate? If not this seems a trivial fix/change.

-- MichaelSparks - 20 Jul 2003

I can not duplicate the issue here. I am/was developing a add-in for the TablePlugin that allows simple table entry (SimpleTableEntryUsingForms) very similar to the EditTablePlugin. Since I am using forms to store the data therefore it resides in the META portion of the file. Since getRenderedVersion() get called before handleMetaTags() any TWiki text in the META fields do not get processed.

This issue seems to be locally isolated to my add-on and does not seem to have any effect elsewhere. I tried duplicating a similar scenario but was unsuccessful.

-- ShawnBradford - 06 Aug 2003

Thanks for letting us know.

-- PeterThoeny - 06 Aug 2003

Shawn might not have been able to duplicate this bug, but I have... (With BeijingRelease)

Beijing Release still contains the bug - and it is symptomatic of a number of larger issues.

Test case:

• Attach a document to a page.
  • Pick any file
  • Set the comment for the comment to:
    • %GREEN%ThisIsATest%ENDCOLOR% %INCLUDE{"TeSt"}%

When viewing the topic you'll find the attachments table rather broken. When viewing the "action" link for the attachment you will be presented with two tables - one correctly rendered, one incorrectly.

• http://www.yeoldeclue.com/twiki/bin/view/Scratch/HomePage

The suggested solution by ShawnBradford does not fix the problem.

As a further bug related to this:

• http://www.yeoldeclue.com/twiki/bin/view/Scratch/HomePage?raw=debug

Shows: %META:FILEATTACHMENT{name="foobar.html" attr=""}%

This is due to the same bug I discussed here:

• http://twiki.org/cgi-bin/view/Codev/AttachCommentBadCharacters

In the disk file - the "correct" version is however in the RCS log - which is why one of the tables has the data in correctly. Which is why one of the view renders succeeds despite no data being stored in the "data" directory, or the topic file:

• http://www.yeoldeclue.com/twiki/bin/attach/Scratch/HomePage?filename=foobar.html&revInfo=1

Furthermore simply updating the comment further allows misteps - cf:

• http://www.yeoldeclue.com/twiki/bin/attach/Scratch/HomePage?filename=more.gif&revInfo=1

Updating the comment field results in the two attachment tables for the same version getting out of step - again due to the RCS log.

Furthermore, including a page in as a comment (or more interestingly a section from a page - allowing translations of comments) results in the table breaking. This can be seen in the foobar.html example above.

This is due to includes happening before tables are rendered, and not being treated as subrequests (think of how apache handles this situation).

• This directly relates to a further "FeatureNotSuitable" : EmbeddedTableBug

Hey wait a moment - this sounds suspiciously like that bug i saw earlier. um - VariableInSquareBracketLinkDoestWorkInFormField

-- SvenDowideit - 21 Apr 2004

Don't think so. I just tested it on the alpha code with the TemplatesForMetaDataPresentation patch in, and it all worked perfectly.

Recommend mark the bug fixed, unless Shawn can reproduce.

-- CrawfordCurrie - 21 Apr 2004