development
Provide the development admin's settings, tracing controls, observer lists, dispatch information, and editor integration.
For structured site inspection use model#development_tools. For browser
capture sessions use model#development_capture. Those models have dedicated
administrator and non-production checks; this older model has per-path access
rules, described below.
Calling the model
Templates access paths through m.development, for example:
{% if m.development.show_trace_button %}
{# Render the development trace control. #}
{% endif %}
HTTP uses /api/model/development/<method>/<path>. Browser MQTT uses
bridge/origin/model/development/<method>/<path>. GET payload fields are HTTP
query arguments or MQTT payload fields. The tables below omit these prefixes.
Flags and diagnostic information
| GET path | Result and access |
|---|---|
is_dbtrace | Whether database query tracing is enabled in the current context. |
debug_includes, debug_blocks, enable_api, libsep, trace_button, hide_trace_button, livereload, nocache | Boolean module configuration flags. |
function_tracing_enabled | Global function-tracing setting; restricted to the built-in administrator (user 1). |
show_trace_button | Whether the current page may show the floating trace button, considering module access, environment, and hide/show settings. |
list_observers | Registered notifier observers; requires use mod_development. |
record_info/RECORD | Runtime record-field metadata, or no value for an unknown record. |
dispatch_info | Active dispatch rules with source information; requires use mod_development. |
GET callbacks accept trailing segments for further model lookups. RECORD is a
variable path segment, not literal text to send.
Template trace relationships
These GET paths read the existing human template trace and require
use mod_development. Supply template as a source filename in the payload.
| Path | Result |
|---|---|
template_trace_parents | Parent relations for the selected template. |
template_trace_children | Outgoing relations for the selected template. |
template_trace_filename_menu | Relations grouped into extends_overrules and includes. |
Parent/child queries accept optional line, column, and type filters.
A missing template argument returns missing_arg. These paths do not create
or control the separate capture sessions exposed by model#development_capture.
Legacy build and cache actions
These GET paths perform actions; they do not merely report configuration.
They are disabled unless mod_development.enable_api is true and return
disabled otherwise. When enabled they do not require authentication. Use them
only on trusted development installations; they are not needed for the newer
inspection or capture models.
| GET path | Action | Success result |
|---|---|---|
recompile | Start recompilation asynchronously. | started |
flush | Flush caches. | flushed |
reindex | Reindex modules and reload translations across running site contexts. | reindexed |
Source editor integration
| Method and path | Purpose |
|---|---|
GET editor | Editor discovery on development sites; requires module access. Other environments return browser-only information without local probes. |
GET can_open_directory | Whether this administrator can open a known installation directory on the server desktop. |
GET config_source/FILE | Signed editor location for an existing node or current-site config file; requires administrator and development-site access. |
POST editor/preference | Save the machine editor choice using payload {editor: ID}. |
POST editor/open | Open an indexed template or signed source/config location. |
Editor POST operations require the development environment and
use mod_development. Containers and browser-only configuration disable local
launches. Config locations additionally require administrator access and must
still belong to the node's Erlang init, Zotonic, or current-site configuration.
See module#mod_development for local editor and browser URL setup.
Opening directories
The System Information directory buttons invoke open_directory/2 through a
signed postback. They require an administrator with module access on a
development site, an available desktop opener, and no container/browser-only
restriction.
Accepted keys are files_dir, data_dir, log_dir, config_dir, security_dir,
work_dir, home, and root. Paths are resolved on the server; arbitrary paths
are not accepted. The directory opens on the server desktop, not the browser's
computer. macOS uses open, Linux desktop sessions use xdg-open, and Windows
uses explorer.exe, with arguments passed directly to the executable.