site.ini [RunnableSettings]
The block [RunnableSettings] of settings/site.ini, with 2 setting(s).
The kernel notifies content/publish ( object id, version ), content/move ( node id, object id, old parent, new
parent ) and content/remove ( object ids, node ids ). The live mirror of the data tables is called by the kernel
itself, in every process (doc/eng-us/features/6.0/data-tables.md, "Live mirror").
Never edit settings/site.ini itself: an update replaces it. Put the settings you change in an override, which wins over the shipped file:
settings/override/site.ini.append.phpfor every siteaccess,settings/siteaccess/<siteaccess>/site.ini.append.phpfor one siteaccess,extension/<extension>/settings/site.ini.append.phpin an extension (read when the extension is active).
Implementation
Commands (bin/), cronjob parts (cronjobs/) and module views are classes that extend
Exponential\Runnable\Command, CronjobPart or ModuleView.
Guide: doc/eng-us/bc/6.0/cli_cronjob_view_abstractions.mdRe-implementation: the class to create instead of a runnable class. It must extend
the class it replaces; an entry naming anything else is ignored.
Implementation[<runnable class>]=<subclass>
eg:
Implementation[Exponential\View\Kernel\Content\History]=myHistoryView
Implementation[Exponential\Command\Kernel\Trashpurge]=myTrashpurgeCommand
Default: an empty list.
# settings/override/site.ini.append.php
[RunnableSettings]
# an empty "Implementation[]" first replaces the shipped list; without it the items are added
Implementation[]
*/ ?>Listeners
Listeners of the runnables' events, in the form of [Event] Listeners[]:
Listeners[]=<event>@<callback>
The events, <kind> being command, cronjob or view:
runnable/<kind>/before notified with ( $runnable, $class, $scope ) before run()
runnable/<kind>/after filters the result: ( $result, $runnable, $class, $scope ),
returns the result to use
eg:
Listeners[]=runnable/view/after@myViewTimer::after
These are attached for the runnables in every context, the command line too
([Event] Listeners[] is attached to web requests only).
A command is created before its script has read the siteaccess and extension
settings, so Implementation[] and Listeners[] for a command are read from
settings/site.ini and settings/override/site.ini.append.php only.runcronjobs.php asks one more filter before the scripts of a part run, after the
siteaccess and extension settings are loaded (its listener may come from either):
cronjob/part/run ( true, $part, $siteaccess, $scripts, $single ); return
true to run the part, anything else leaves it out. $part
is '' for [CronjobSettings] and for --script; $single is
true for --script, whose one file name is in $scripts
Listeners[]=cronjob/part/run@myCronjobStop::partRun
Guide: doc/eng-us/features/6.0/cronjob-part-filter.md
Default: an empty list.
# settings/override/site.ini.append.php
[RunnableSettings]
# an empty "Listeners[]" first replaces the shipped list; without it the items are added
Listeners[]
*/ ?>Related
Generated by ./console exp:help:examples from settings/site.ini. Do not edit this page: change the source and generate again (how). Free documentation: GFDL 1.3 or later.