Item1599: strip EDITTABLE commands and question marks from dangling links

• EDITTABLE{} directives should be stripped (or even better: completely ignored) for pdf generation. Currently the whole EDITTABLE{...} line gets printed.
• There should at least be an option which allows for stripping the question marks of dangling WikiWords.

---

I'm not able to recreate the EDITTABLE issue - it doesn't show up in the PDF's I've generated here. Please provide a testcase, and list any other non-default plugins that you have installed.

I've checked in a fix to the ? Dangling WikiWords.

---

To give you an example:

---+!! !EditTableTest

%EDITTABLE{ format="| row, -1 | date, 10, , %Y-%m-%d | text, 16 | text, 18 | text, 9 | text, 6 | text, 9 | select, 1, , CreatecSputter, SmallSputter, VabMBE | text, 10 | text, 20 |" changerows="on" headerislabel="on"}%
| *#* | *Date* | *OperatorName* | *DepositedMaterial* | *Thickness* | *Temp°C* | *Substrate* | *DepositionDevice* | *SampleName* | *Comment* |
| 1 | | | | | | | | | |
| 2 | | | | | | | | | |
| 3 | | | | | | | | | |

Exporting this by use of the URL http://XXX.XX/cgi-bin/foswiki/genpdf/Sandbox/EditTableTest?skin=print;pdftoclevels=0 results in the following pdf: Sandbox_EditTableTest.pdf

I'm running Debian stable with following foswiki packages installed:

Package	Version
foswiki	1.0.5-1
foswiki-attachcontentplugin	081124-194
foswiki-attachlinkplugin	081224-194
foswiki-autocompletionlibplugin	090316-194
foswiki-batchuploadplugin	090320-194
foswiki-comparerevisionsaddon	090428-194
foswiki-dbcachecontrib	090409-194
foswiki-dbicontrib	090320-194
foswiki-editrowplugin	090225-194
foswiki-excelimportexportplugin	090313-194
foswiki-filterplugin	090418-194
foswiki-findelsewhereplugin	090326-194
foswiki-formplugin	090317-194
foswiki-formqueryplugin	090409-194
foswiki-foswikisiteskin	090417-194
foswiki-fugueiconscontrib	090421-194
foswiki-genpdfaddon	090301-194
foswiki-getawebplugin	090220-194
foswiki-glueplugin	090418-194
foswiki-gouptotocplugin	090203-194
foswiki-historyplugin	081217-194
foswiki-imagegalleryplugin	090425-194
foswiki-imageplugin	090425-194
foswiki-jhotdrawplugin	090206-194
foswiki-jquerycompatibilitymodeplugin	090315-194
foswiki-mathmodeplugin	090424-194
foswiki-mediaplugin	090509-194
foswiki-moveabletypeskin	090220-194
foswiki-publishplugin	090327-194
foswiki-redirectplugin	090410-194
foswiki-subscribeplugin	081204-194
foswiki-topiclistplugin	090203-194
foswiki-widgetsskin	090512-194

-- PhilippLeufke - 15 May 2009

---

Definitely doesn't happen that way here. I've tried it on my production 1.0.5 server. I'll have to establish a different test environment to see if I can recreate it. Not sure what could be going on. I didn't have the EditRowPlugin installed. Installed that - still works fine. I don't want to install too many other Plugins on this particular server.

Would you be able to disable all but the default plugins to determine which plugin if any might contribute to this? If we can narrow this down it will probably be easier to fix. It might not be an issue in genpdf itself, but I'm not sure where to look.

-- GeorgeClark - 16 May 2009

I did some debugging: The problem is definitely caused by EditRowPlugin. I deactivated all plugins but this one (and TWikiCompatibilityPlugin which it depends upon) and got the error. Only enabling EditTablePlugin would make the error disappear. Having both of them enabled, the error is gone as well, but the EditRowPlugin features will not be present.Setting the PluginsOrder doesn't have any effect on that.

Switching $Foswiki::cfg{Plugins}{EditRowPlugin}{Macro} from EDITTABLE to something else, like EDITROW, will cause GenPDFAddOn to print the EDITROW line as well when printing to PDF.

-- PhilippLeufke - 24 May 2009

I think I see what is going on - but not sure how to fix it. I had not disabled the EditTable plugin. Now that it is disabled, I've recreated the problem. I believe that the EditTable plugin removes the EDITTABLE macro. The EditRow plugin however simply exits without processing if the context is anything but the "view" context, so the EDITTABLE macro is never processed and is left in the markup. genpdf is an alternative view context, so should probably be treated like view. But just adding genpdf to the EditRow plugin would not address other plugins that are also variants of view.

-- GeorgeClark - 28 May 2009

Sven suggest Crawford should take a look. I'd rather find a general fix that will work with other view alternatives. Modifying genpdf to strip EDITTABLE and/or modifying EditRow to detect genpdf are too narrow.

---

Any decent publishing extension will have features to support disabling plugins. What we don't have is any way to tell plugins to strip their "active content* without performing any action on it. Even if we did have such a beast, it would work through tag handler registration and for the EDITTABLE-like tags, they don't go that route (because of the way they process following tables). So it's hard to see how to make a generic mechanism that will strip active content from topics.

What might be possible is a filter plugin that could be used by all publishing engines, that can be taught (using regexes) what has to be stripped from topics before publishing. Such a stripper would be easier for someone with enterprise-specific extensions to configure as well.

-- CrawfordCurrie - 10 Jun 2009

Enabling the view context for the genpdf script resolves the issue.

-- GeorgeClark - 07 Dec 2009