Added: Added the settings, extension root and siteaccess customisation points that arrived with 6.0 to the RAD catalogue, the survey and the settings wizard.

Reading the last three releases back, six extension points had been added to
this system and written down nowhere the RAD tools could see them: additional
extension roots and the filter hook behind them, the site extension pattern
those make possible, extension resident icon themes, the Redis and Valkey cache
hooks, and writing settings from code now that a direct access write keeps the
comments of the file it edits.

Two of those are now written by the settings wizard as well as documented. It
declares a second extension root and leaves a note in it saying what the root
is for, how shadowing works, and why nothing should ever build a path out of
extension/ and a name again. And it writes an icon theme: the ini that makes a
directory a theme, a size directory per size with a file in it so the directory
survives being copied, and an icon.ini that adds the theme to the search rather
than making it current - so everything the site already draws keeps drawing.

The survey was looking at the wrong tree. Its sweep for places the kernel
searches knew five variable names and not the ones added since: it could not
see AdditionalExtensionDirectories, IconExtensions or ActiveAccessExtensions,
which is to say it could not see the newest extension points at all. It now
finds 1027 points where it found 924.

AdditionalExtensionDirectories was in the API, in the tests and in a document,
and in no ini file on this installation - so nobody would find it by reading
the configuration, which is how everything else here is found. settings/site.ini
now carries it, declared empty and documented, which changes no behaviour: the
roots resolve to extension alone exactly as before.

One fault found while writing it: the wizard was taking the leading slash off
an absolute path rather than refusing it, so /etc was quietly read as a request
for ./etc. A typo should not become a root nobody meant.

Added: Added a module wizard, so every one of the forty eight written extension points now has a tool behind it.

A module is three things that have to agree with each other - a declaration, a
script per view, a template per view - plus the two ini lines that make the
kernel look for any of it. When they disagree the failure is quiet: a view with
no script is a blank page, a view naming a policy no module declares can be
reached by nobody, and a module the ini does not list is not there at all. The
wizard writes all of it from one line per view, and refuses the third of those
by name rather than letting it be discovered later.

Views are described in the shape eZ already uses: a word in lower case is a
policy, a word starting with a capital is a parameter in the address, and a
capital word ending in a question mark is a named parameter that may be left
out. The page shows the address each view will answer at as it is typed.

The suite writes the module to disk, hands it to eZModule, and checks the
kernel accepts it, finds every view, and runs one - rather than only checking
that the file it wrote parses.

Forty eight of forty eight. The survey beside the list still counts nine
hundred and twenty four points on this installation, which is the honest
number; the forty eight are the ones worth explaining.

Added: Added a content extension wizard that writes a content class as a script rather than as an afternoon of clicking, and renamed the copyright holder to 7x / Exponential Foundation.

A content class built in the admin exists on the machine it was built on and
nowhere else, and the only record of how it was made is whatever somebody wrote
down. Written as a script it is reviewable, re-runnable, and the same on every
installation it is run on. The same extension carries custom tags for rich text
and a translation file, because all three are about the content rather than
about the machinery under it.

Two faults in the generated script, both found by running it rather than by
reading it. eZContentClass::fetchByIdentifier() answers null and not false when
there is no such class, so the guard meant to stop a second run was true every
time and the script would never have run at all - and the page refused every
identifier for the same reason. And the class has to be built as temporary and
promoted at the end: storeDefined() recreates the class group links from the
version before it, so a group added to a class that is already defined is wiped
by the very call meant to finish it, leaving a class that exists and appears
nowhere.

The suite now runs the script it writes, checks the class, its attributes, its
flags and its group are really there, runs it a second time to see it refuse,
and takes the class away again.

Forty five of the forty eight written points now have a tool.

Added: Added a settings extension wizard, and a login handler to the handler wizard, taking the written points with a tool to forty one of forty eight.

A good deal of what this system can be told to do differently is told in
settings rather than in code. None of it is hard; all of it is in a shape
nobody remembers, spread over half a dozen files, with a rule about where the
file has to live for anything to read it at all. The new wizard writes six of
them: image aliases with their filters, event listeners with the class behind
them, view cache clearing rules, what happens when a visitor fills in a form,
which operations a workflow may be bound to, and settings that apply to one
siteaccess only.

It refuses to redefine an image alias the site already has, because writing one
again does not add it - it replaces it, and every image served through it
changes size without anything saying so. It writes AliasList[] and
Listeners[] and AvailableOperationList[] as additions rather than as
replacements, because a bare Key[] line above any of those would throw away
what the kernel said and unbind content_publish, silence every listener, or
leave every template asking for an alias that no longer exists.

The login handler is the same shape as the notification ones: the class name,
the file name and the ini value are all worked out from one word, and a handler
whose three names disagree is reported missing while the default quietly
answers instead. Its examples lead on failing closed, because a handler that
lets people in when the directory it asks is unreachable is a site opened by an
outage.

Updated: Updated the extension surface survey to tell an alias from a broken registration, so sixteen healthy settings stop being reported as faults.

Several of these settings take an alias rather than a class name, and the two
cannot be told apart by looking at the setting - only by looking at the value.
Every class in this system has a capital in it somewhere and every alias is one
lower case word, so a lower case value naming no class is an alias doing its
job rather than a registration nobody wired up.

That takes this installation from seventeen apparent faults to one: an
ExchangeRatesUpdateHandler set to eZECB, which is shaped like a class and is
in fact an alias for eZECBHandler. Being told about that one is the point; being
told about the other sixteen was noise.

Added: Added a survey that reads this installation's extension surface off disk, because forty eight written points is not the size of eZ Publish.

The RAD tools page lists what somebody thought to write down. This lists what
is actually here, and on this installation that is nine hundred and twenty one
points: three hundred and sixty seven settings across three hundred and eighty
one ini files whose value names a class, ninety eight directories the kernel
searches for a handler, forty one interfaces and abstract classes declared for
somebody else to implement, and four hundred module views across fifty seven
modules. It is read fresh on every request, so an extension installed this
morning is in it this afternoon and nothing in it can go stale.

It reads without loading. Nothing in it calls class_exists, interface_exists or
reflects on anything: a class name is resolved through the autoload maps
instead. That is not tidiness - the first version used class_exists and was
brought down by one installed extension whose class php refuses, which is
exactly the sort of thing a survey ought to be able to report rather than die
of. It now reports seventeen settings on this site that name a class nothing
declares.

Two parsing faults found while building it and fixed: a bare Key[] line, which
is how eZ says "forget what anything before said about this array", was being
skipped, so every unfilled handler directory was missing; and a module was
being identified by the title it declares for people to read rather than by
its directory, so the list agreed with nothing else in the system.

The page can be searched and paged, and the whole thing is also written out to
doc/bc/6.0/rad-extension-surface.md.

Updated: Rewrote the two RAD tools that had stood unchanged since 2003, so each writes a working extension rather than handing back one php file.

The datatype wizard asked four questions and downloaded a class. eZDataType
declares over ninety methods and which of them a datatype needs depends
entirely on what it is for, so the page now asks what it has to do - editing,
class settings, searching, sorting, files, information collection, packages,
diffs, relations, cleanup, batch initialisation and the rest - and writes only
the methods that answer to that, each with a note saying what the kernel calls
it for. It also writes the templates, which the old one did not: a datatype
whose templates cannot be found loads, registers, appears in the class editor
and draws an empty field. That is what the design.ini it now writes prevents.

The template operator wizard asked five questions and ignored three of them -
the input, output and parameter answers were overwritten with constants before
the file was generated, so every operator it ever produced had the same shape.
In its place is a template extension wizard covering all four things a
template can be taught to call: operators, functions, fetch functions and
fetch aliases, in any mixture, with the registration each needs. Registration
is where this usually goes wrong, and the tool now says so: an operator lives
in an autoload array rather than an ini, and being active is not the same as
being in ExtensionAutoloadPath.

Both carry worked examples and both are covered by suites that load the class
they wrote, parse the ini they wrote with the real ini reader, compile the
templates they wrote, and run the generated operator through the template
engine.

Three catalogue entries were wrong and are corrected: the datatype one named
the wrong ini, the operator one claimed an ini registers the class, and a
template function was missing as a point of its own. Thirty four of the forty
eight extension points now have a tool.