Feature Proposal: Fix incorrect way of aborting a plugin invocation

Motivation

I just spent quite some time (several hours) debugging a problem where a topic was not correctly rendered. I found the following insidious trap lurking in a number of plugins:

Many plugin writers attempt to avoid the overhead of running the handlers where such does not make sense. Thus we find in several plugins code such as this:

    # Only bother with this plugin if viewing (i.e. not searching, etc)
    return unless ($_[0] =~ m/view|viewauth|/o);

The above is from a preRenderingHandler but there are several such examples.

I ran into this when trying to understand why some plugins did not fire correctly when using the GenPDFAddOn, which uses the script genpdf. You can see the problem. Any new script will either have to be tracked in the plugins, or it will not fire.

The plugins need to be careful to rely on the context established in a TWiki session, rather than on the test as to which script is invoking the plugin. If it relies on scripts, it must be at most a negative test, e.g., don't run this handler if such and such script was used.

Description and Documentation

The solution is specific to each plugin.

Examples

Impact

Implementation

Analyze the existing plugins and rewrite these tests. I will do this for my plugins.

-- Contributors: ThomasWeigert - 2010-09-15

Discussion

Good point.

Idea: How about add a test for each plugin in %FAILEDPLUGINS% so that it is shown InstalledPlugins?

-- PeterThoeny - 2010-09-20

Hmmm.... This test would require a new script that the plugin does not know about and then it would have to somehow determine that the plugin aborted instead of doing its thing. That does not seem easy to do.

-- ThomasWeigert - 2010-09-20

I was more think of calling some plugin handlers with some dummy data and check what the returned value is. That way we could catch an empty return.

-- PeterThoeny - 2010-09-20