FourThingsPatchMightWantToDo

There are four things a patch might want to do to the code

1. add new variables
2. set those variables
3. add new subs
4. change existing subs (including add/mod/delete lines within them)

Of these, number 4 is obvious (give or take some white space) you change existing code where it is

Taking the others in order:

1. Adding new variables

In my opinion wiki.pl would benefit from more segregation of its variables than it already has - splitting the declarations of config and internal constants would be my first job there.

So my request is don't make it even more monolithic. There is no charge for a use vars qw - put your own in for your patch, and comment it # patch blah, config setting

(incidentally, newcomers to Perl should note that you cannot put comments on the ends of lines within a qw( ) list, to comment the new additions you need to put them in their own list)

2. Setting new variables

My request is that if these are going to be truly constant (ie not subject to user configuration) set them below IndexFile? = (the last line of the block headed by the comment You should not have to change anything below this line - that comment is addressed to the config person, not to the patcher).

Equally if they are to be user configured then put them at the foot of the long list of default config settings.

Subtleties:

The above assumes you want them set when the code is loaded. In most cases (if they are true settings or constants) this will be OK. Skip the subtleties if that is the case for you.

But suppose you decide to set $EditAllowed? according to the incoming user's LAN address? Where should that go?

• If you follow my above advice then if later the webserver keeps the code loaded permanently, the $EditAllowed? setting will not be reset every time.
• To make sure it is set every time the code runs, put it inside the top of the DoWikiRequest sub
• To write special code that runs in the standalone case but not when called from another module, invert the if at the foot of the program so that it reads

 if (...) {
    &DoWikiRequest ()
 }

instead of a one line if. Now insert your code inside the new block. (Purpose would be to emulate code that would normally have been provided by your wrapper script)

3. Add new subs

Until you turn on DeferredCompile, you can put these anywhere. However, if you put them too near the top of the program they will be compiled even when not needed. Put them too near the bottom, and you will get very confused by DeferredCompile - it will say your sub is not there when you can see it in the code.

My advice is

• if the sub is likely to be needed even when wiki serves up a page from the cache, put your new sub just before the line where $BrowseCode is assigned, ie before the comment # == Normal...
• elsif the sub will be needed for normal browsing or for RecentChanges, put it immediately before the comment line #END_OF_BROWSE_CODE
• else put it immediately before the comment line END_OF_OTHER_CODE