# development

Source: https://zotonic.com/docs/1456/development

URI: https://zotonic.com/id/1456

Language: en



Provide the development admin's settings, tracing controls, observer lists, dispatch information, and editor integration.

For structured site inspection use <a href="/id/doc_model_model_development_tools" class="doc-reference doc-reference-model"><code>model#development_tools</code></a>. For browser capture sessions use <a href="/id/doc_model_model_development_capture" class="doc-reference doc-reference-model"><code>model#development_capture</code></a>. 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:

```django
{% 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 <a href="/id/doc_model_model_development_capture" class="doc-reference doc-reference-model"><code>model#development_capture</code></a>.

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 <a href="/id/doc_module_mod_development" class="doc-reference doc-reference-module"><code>module#mod_development</code></a> 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.

License: 

Attribution: 

Related resources: https://zotonic.com/api/agent/related/1456?language=en


## API access

- [API help](<https://zotonic.com/api-help>)
- [OpenAPI specification](<https://zotonic.com/openapi.json>)
- [This resource as JSON](<https://zotonic.com/api/agent/resource/1456?language=en>)