We should replace them with a unified %SCRIPTCALLBACK{action}% directive.

-- MartinCleaver - 29 Sep 2004

The more unique s there are, the slower the prefs substitution goes. So cleaning this up is desireable. But can you please provide an exhaustive list?

-- CrawfordCurrie - 29 Sep 2004

We can provide additional functionality, but I strongly disagree to remove existing variables because it would break existing content. And it would violate one item in the TWikiMission, to "protect corporate investment (topic contents) from data corruption and incompatible changes - don't require the use of upgrade scripts"

-- PeterThoeny - 30 Sep 2004

If it didn't break existing functionality, would you agree?

• Changing infrastructure is a necessary part of progress. Otherwise manufacturing plants would continue to use bespoke sized nuts, bolts and screws like they did before someone worked out that huge amounts of overhead cost lay in the administration of incompatible parts. Life is cheaper without all that overhead: which means people can use energy resources to be more productive instead.

Support for the old syntax does not need to be halted overnight, if ever. But if one thinks that it isn't needed on a particular installation any more one should be able to unplugin it to gain the incremental speed update.

The ugliness can be first moved to a plugin where they become rewrites of the new syntax. Eventually the bloat can be blown away.

Anyway, the phrase "Don't require the use of upgrade scripts" in the mission is followed by (e.g. category to forms upgrade happened automatically): we would of course provide the administrator with tools to help them detect and replace old instances. And for users, once support for the old syntax is removed a plugin could simply alert the user on save (or after, e.g. by email) if they've tried to use an deprecated %MACRO.

-- MartinCleaver - 30 Sep 2004