Extension points #

Read this page if you extend Exponential with your own code and want to know where each kind of extension plugs in, which INI line registers it, and which tool in Setup > RAD helps you build it. Exponential is extended in a handful of ways that repeat: a class in a directory the kernel scans, a class named by an INI setting, a file in a place found by convention, or a template in a design. Which of those applies, and which INI line registers it, used to be discoverable only by reading the kernel.

In short #

Every entry was checked against the source; the Kernel column names the file the mechanism lives in.

How things are registered #

• directory — A class in a directory the kernel scans. The directory is named by a RepositoryDirectories setting, and the class is found by its file name.
• handler — A class named by an ini setting and loaded through eZExtension::getHandlerClass. The setting gives an alias, the alias gives the class.
• autoload — A class reached through the extension autoload path, registered once in an ini and then available everywhere.
• file — A file in a place the kernel looks by name. Nothing registers it; being there is the registration.
• design — A template in a design, found through the design chain rather than by being named anywhere.
• ini — Settings only. Nothing is written but ini, and the behavior changes.
• override — A kernel class replaced by one of your own through the override autoload path. The heaviest of these mechanisms and the last resort: nothing registers the replacement by name, so two extensions replacing the same class is a fight neither of them knows it is in.
• registry — An entry of a registry that rad.ini declares: the kernel or an extension says which ini blocks, or which class list, hold the entries and what each must be, and the extension point survey counts and checks every entry without the kernel naming the extension.
• filter — A listener of a filter event in site.ini [Event] Listeners[]. The kernel passes a value and goes on with what the listener returns, so a listener that forgets to return it destroys the value.

Content #

What content is made of, and how it is edited and stored.

Datatype #

Tool: /setup/datatype

A kind of value a content class attribute can hold, with its own editing, validation, storage and display.

Content class #

Tool: /setup/contentextension

A type of content: its attributes, their datatypes, and how an instance of it is named.

XML custom tag #

Tool: /setup/contentextension

A tag authors can use in rich text, with its own attributes and its own template.

XML text input handler #

Tool: /setup/handlerextension/xmlinput

What turns what an author typed into the xml a rich text attribute stores.

XML text output handler #

Tool: /setup/handlerextension/xmloutput

What turns stored rich text into what a visitor sees.

Information collection behavior #

Tool: /setup/settingsextension

What happens when a visitor fills in a form built out of content: what the submission is called, whether it is kept, whether it is emailed, and what the visitor is shown afterwards. Matched per content class, so a poll and a contact form built the same way behave differently.

View cache clearing rules #

Tool: /setup/settingsextension

Which other pages have to be rebuilt when one object is published. The default clears the object, its parents and what relates to it; a group named after a content class identifier says what else - a listing that has to change when a comment is posted, an object somewhere else entirely.

Asynchronous publishing filter #

Tool: /setup/handlerextension/publishfilter

Decides whether a version is published in the request or handed to the queue. Publishing a large object blocks whoever pressed the button; a queue that takes everything makes small edits feel broken. This is where that line is drawn.

Templates and design #

What a template can call, and what a design can replace.

Template operator #

Tool: /setup/templateoperator

Something a template can pipe a value through: {$value|my_operator()}. One class may answer to many names, and what it promises the compiler decides whether it runs once at compile time or on every request for ever.

Template fetch function #

Tool: /setup/templateoperator

Something a template can ask a module for: fetch( 'module', 'thing', hash( ... ) ).

Attribute operator #

Tool: /setup/handlerextension/attributeoperator

An operator that applies to a content attribute of a particular datatype.

Template function #

Tool: /setup/templateoperator

Something a template calls rather than pipes through: {my_function arg=1}, optionally with a body it may draw none, one or many times. How {section} and {foreach} are built.

Fetch alias #

Tool: /setup/templateoperator

A name for a fetch that is written out in full somewhere else, so templates can be short.

Design extension #

Tool: /setup/designextension

The templates, stylesheets and images a site is drawn with.

Template override set #

Tool: /setup/designextension

A template used in place of another, for the content it matches and nothing else.

Icon theme in an extension #

Tool: /setup/settingsextension

A set of icons an extension brings with it, searched before the ones that ship. The whole chain falls back: the current theme, then any additional themes, then the standard one; and within each, extension directories before share/icons. A missing icon takes the theme default rather than drawing a broken image.

Modules and views #

Addresses the site answers on, and who may reach them.

Module over existing tables #

Tool: /setup/moduleextension

Administration and a template API for tables that already exist, here or on another database.

Module #

Tool: /setup/modulewizard

A new address the site answers on, with its own views and its own policies.

View for an existing module #

Tool: /setup/modulewizard

One more thing an existing module can be asked to do.

Policy function and limitation #

Tool: /setup/modulewizard

A thing a role can be granted, and what it can be narrowed by.

Content policy limitation #

Tool: /setup/settingsextension (choose the event module/functionlist: it writes the listener and a working handler)

A limitation of your own for a content function such as content/read, next to Class, Section and Subtree: an extension adds it to the function, and its handler decides for objects, nodes and versions and gives the SQL condition of list and tree fetches. Without a handler the limitation denies everywhere. See Content policy limitations of extensions.

REST provider #

Tool: /setup/handlerextension/restprovider

A set of addresses answering outside the template system, for something else to call.

REST route filter #

Tool: /setup/handlerextension/restroutefilter

Something that inspects or changes a REST request before it is routed.

Server-side ajax function #

Tool: /setup/handlerextension/ajaxfunction

Something the browser can call and get json back from, without a page.

Registry declared in rad.ini #

Tool: /setup/radsurvey/(show)/registries

A list of implementations that an extension reads from its own settings or from its own code, such as AI providers and tools, MCP tools or queue job types. Declared in rad.ini, it is counted and checked by the extension point survey like the kernel's own registries: every entry is listed, and one whose class, method, template or block is missing is shown as broken. How to declare one: The extension surface.

Workflow, events and jobs #

What happens when something is published, and what runs on its own.

Workflow event type #

Tool: /setup/workflowevent

A step a workflow can take when something is published, moved or removed.

Trigger #

Tool: /setup/settingsextension

The point in an operation where a workflow is given the chance to run.

Notification event type #

Tool: /setup/handlerextension/notificationtype

A kind of thing people can be notified about.

Notification handler #

Tool: /setup/handlerextension/notificationhandler

What decides who is told, and how they are told.

Cronjob script and part #

Tool: /setup/cronjobs

Something that runs on its own, on a schedule, outside any request.

Cronjob part left out #

Tool: none (the settings extension wizard writes [Event] Listeners[], which the command line does not read)

Something that decides whether a cronjob part runs at all, for example a stop switch while a release is deployed. runcronjobs.php asks the filter cronjob/part/run with the part, the siteaccess and the scripts before the first script starts; only true runs the part. Guide: Leaving out a cronjob part.

Kernel event listener #

Tool: /setup/settingsextension

Something called when the kernel reaches a named point, such as a request arriving.

Filter event listener #

Tool: /setup/radsurvey/(show)/events

A listener of a filter event, whose return value replaces what the kernel passed: for example httpcache/store/headers, the headers an HTTP cache keeps with a page. A notify event such as package/install/drafts, after a package was installed as drafts, ignores what its listeners return.

Storage and infrastructure #

Where things are kept, and how they get there.

Database handler #

Tool: /setup/handlerextension/dbhandler

A kind of database the whole system can run on.

Cluster file handler #

Tool: /setup/handlerextension/cluster

Where files live when more than one server serves the same site. Everything the kernel reads or writes under var/ goes through this, so it is the widest reaching of the storage points and the one most worth extending from eZFSFileHandler rather than from the bare interface.

DFS backend #

Tool: /setup/handlerextension/dfsbackend

Where the DFS cluster handler puts the bytes: a mounted share, an object store, anywhere reachable. The index of what exists stays in the database; this only moves file contents.

DFS database backend #

Tool: /setup/handlerextension/dfsdbbackend

The other half of DFS: the index of which files exist, how big they are and which are being generated. It is what stops two servers building the same cache entry at once, so it is the harder half to replace.

Binary file handler #

Tool: /setup/handlerextension/binaryfile

How an uploaded file is stored and handed back.

Search engine #

Tool: /setup/handlerextension/search

What indexes content as it is published, and what answers when somebody searches.

Session handler #

Tool: /setup/handlerextension/session

Where sessions are kept and how they are cleaned up.

Mail transport #

Tool: /setup/handlerextension/mail

How mail leaves the system.

Static cache handler #

Tool: /setup/handlerextension/staticcache

What writes pages to disk so the web server can serve them without php.

Image handler and aliases #

Tool: /setup/settingsextension

How an image is scaled and what sizes exist.

Compiled settings and view cache in Redis #

Tool: /setup/handlerextension/inicache

Two places the kernel will hand its caches to Redis or Valkey if something answers for them: the compiled ini cache, and the content view cache. Neither is an ini setting - the kernel asks whether a class exists and uses it if it does, so an installation without the extension behaves exactly as before.

Debug bar panel #

A tab of the Exp Debug bar from an extension, after Memory, with an optional chip in the summary and data in the page's JSON: what the extension knows about the page, such as the layout it was built from. The panel decides who may see it, since the bar also shows to anonymous visitors by IP.

Packaging and shop #

Moving things between installations, and selling them.

Package handler #

Tool: /setup/handlerextension/packagehandler

A kind of thing that can be put in a package and taken out again.

Package creation handler #

Tool: /setup/handlerextension/packagecreation

The steps the admin interface walks through when a package is made.

Package installation handler #

Tool: /setup/handlerextension/packageinstall

What happens when a package is installed or taken back out.

Payment gateway #

Tool: /setup/handlerextension/paymentgateway

Takes a basket to somewhere money can be paid and brings the answer back. The shop prices, taxes and delivers a basket and stops at taking money: this is the piece that does not ship. It is called twice for one order - once to send the buyer away, once when they return - and the two visits are joined by the payment row it stores in between.

The kernel looks for a gateway at <GatewaysDirectories>/<gateway>/classes/<gateway>gateway.php, for each name in AvailableGateways[], so the class file sits in a directory named after its alias. Before 6.0.15 the tool wrote paymentgateways/<alias>gateway.php, where nothing looked, and registered the class under <alias>gateway rather than its own name: a gateway made with an earlier version has to be moved to the path above, and the second argument of its registerGateway() call changed to the class name.

Payment gateway, transparent #

Tool: /setup/handlerextension/paymentgatewaydirect

Takes the payment without the buyer ever leaving the site: the card is exchanged for a token in the browser, and the charge is made server to server while they wait. The common shape now, and a different job from the redirect kind - one call decides the order, so there is no second visit in which to correct a wrong answer, and a timeout is a genuinely ambiguous state that has to be asked about rather than guessed at.

VAT handler #

Tool: /setup/handlerextension/vat

What rate of tax applies to what, for whom.

Shipping handler #

Tool: /setup/handlerextension/shipping

What delivery costs, and what the options are.

Basket info handler #

Tool: /setup/handlerextension/basketinfo

What a basket line says about itself: name, price, and what it is.

Exchange rate handler #

Tool: /setup/handlerextension/exchangerate

Where the rate between two currencies comes from.

Users, access and language #

Who gets in, what they may do, and in what language.

URL alias filter #

Tool: /setup/handlerextension/urlfilter

Runs over every url this system generates, before it is stored, and may rewrite it. The nearest thing here to an output filter over addresses: every alias, for every object, in every language, passes through it as it is made.

Mobile device filter #

Tool: /setup/handlerextension/mobilefilter

Decides whether a request came from a phone and what to do about it. The one that ships matches user agent strings against patterns, which ages badly; a filter of its own can use a header a proxy sets or a hint the browser gives.

REST pre routing filter #

Tool: /setup/handlerextension/restprerouting

The earliest place there is to see a REST request. Nothing has been matched and no controller chosen, so a request can be rewritten or turned away before anything has committed to answering it - and before authentication, so about a caller nobody has identified.

REST request filter #

Tool: /setup/handlerextension/restrequestfilter

Runs once the request object is built and the route is known, so it knows which controller is about to answer. Where a header is read, a parameter normalised, or a request refused on grounds that depend on what it asked for.

REST result filter #

Tool: /setup/handlerextension/restresultfilter

Runs after the controller has worked out its answer and before it becomes json or xml. The result is still ordinary php here, so it can be added to or reshaped once for every format rather than in each renderer.

REST response filter #

Tool: /setup/handlerextension/restresponsefilter

The output filter of the REST layer: the last thing that happens before an answer leaves. A header on every response, a body wrapped, a content type changed, without touching a controller.

REST prefix filter #

Tool: /setup/handlerextension/restprefix

What decides where the api lives and which version of it a request asked for. The one that ships reads a regular expression; replacing it is how the api moves off /api/ or takes its version from somewhere other than the path.

User login handler #

Tool: /setup/handlerextension/login

Where a user is checked against when they log in - a directory, another system, anything.

Additional extension roots #

Tool: /setup/settingsextension

Where extensions may live, beyond extension/. A second root - extension_src/ is the usual name - separates what a project wrote from what it took from elsewhere, so ownership is readable off the directory layout rather than off a list somebody maintains. An extension of the same name in a later root shadows the one before it, which is how a vendor package is forked without being edited.

Extension root filter #

Tool: /setup/kerneloverride

The last word on which roots are searched, in code rather than in settings. Redefining it is how a root is worked out at runtime - from an environment variable, from which machine this is, from what a deployment put on disk - rather than written into an ini that has to differ per installation.

Site extension #

Tool: /setup/settingsextension

One extension carrying a whole site: its design, its siteaccesses, its grouped settings overrides, its modules and its code. What makes this possible rather than merely tidy is that an extension can now hold settings/siteaccess/<name>/ of its own, so the siteaccess travels with the thing that defines it instead of living in settings/ on one machine.

Writing settings from code #

Tool: /setup/settingsextension

Changing an ini file from php rather than by hand: what the settings editor in the admin does, and what an installer or an upgrade script needs. Since 6.0 a direct access write keeps the comments and the ordering of the file it edits rather than rewriting it as bare key and value, so a generated change can be read afterwards by whoever has to maintain it.

Siteaccess settings extension #

Tool: /setup/settingsextension

Settings that apply to one siteaccess only, kept with the extension rather than in settings/.

Translation #

Tool: /setup/contentextension

The words the interface uses, in another language.

RSS import handler #

Tool: /rss/list

What an imported feed item becomes once it has been fetched.

Keeping it true #

The catalogue is data, not prose: expRADCatalogue::points(). A point added there appears on the RAD page without the page being edited. This document is generated from the same catalogue; when the two differ, Setup > RAD is current.

Related pages #

• RAD extension surface: the survey
• RAD tool security
• Commands, cronjob parts and module views as classes
• Extensions guide