[ExtensionSettings]
| Setting | Summary |
|---|---|
| DesignExtensions | Sets which extensions that have designs. |
Changed in Exponential 6.0.15
Settings of this group in the settings files of Exponential 6.0.15 that this page does not describe:
| Setting | File | Default | Description |
|---|---|---|---|
| IconExtensions | settings/icon.ini | (empty) | A list of extensions which contain icon themes (under extension/<name>/icons). When an extension is listed here the kernel icon operators will search it before falling back to the default share/icons repository. |
| ExtensionDirectory | settings/site.ini | extension | |
| AdditionalExtensionDirectories | settings/site.ini | (empty) | Further places extensions may live, searched after ExtensionDirectory above. A second root separates what this project wrote from what it took from elsewhere, so who owns a package is readable off the directory layout rather than off a list somebody has to maintain. An extension of the same name in a later root shadows the one before it. That is how a package is forked without being edited - copy it across and change it there - and also how one gets shadowed by accident. The directory has to exist, and the autoload generator scans every configured root, so after adding one: php bin/php/ezpgenerateautoloads.php Nothing else: moving a package between roots is a copy, with no manifest to edit and no composer dump-autoload to run. Code should never build a path out of "extension/" and a name. Use eZExtension::extensionPath() and eZExtension::expandedPathList(), which resolve across every root. eZExtension::filterExtensionRootDirectories() is the last word, for a root that has to be worked out at runtime. See doc/eng-us/bc/6.0/AdditionalExtensionDirectories.md |
| ExtensionOrdering | settings/site.ini | enabled | AdditionalExtensionDirectories[]=extension_src Use extension reordering to avoid issues because of ActiveExtensions and ActiveAccessExtensions not being correctly defined Known issues: - Breaks clustering settings in siteaccess and extensions support Only known workaround is to disable this setting and order manually - Still loads an extension even if dependant extension is not loaded - Does not fix order issues across the two extensions settings ( ActiveExtensions and ActiveAccessExtensions ) |
| ActiveExtensions | settings/site.ini | xrowmetadata | A list of active extensions, add new ones to activate them The extension itself will then have it's settings directory read (if any) and any extra configurability is done automatically. |
| RequiredExtensions | settings/site.ini | expui | Extensions the kernel's own designs need. Each one that is installed is active in every siteaccess, ahead of ActiveExtensions[], whatever an override sets there; one that is not installed is left out without an error. The admin designs request the script packs of Exponential UI (expui, which the kernel package requires: exp::core::shared, exp::io, exp::datatable ...) for the sub-items table, relation search, uploads and date fields; without it ezjscore answers "Not a valid ezjscServer function" for each of them. A project that resets ActiveExtensions[] (a Platform Legacy project's override) keeps it. |
| ActiveAccessExtensions | settings/site.ini | (empty) | Same as ActiveExtensions but will be loaded after the siteaccess is chosen. This allows for activating different extensions on different siteaccesses |
| SOAPExtensions | settings/soap.ini | (empty) | Extensions for SOAP functions. SOAP functions must be registered under soap/initialize.php |
In this section
Contributors
- Frederik Holljen
- Graham Brookins Updated
Comments
Add a comment