Text
Browse by topic
Explore related documentation through its most useful keyword groups.
1342 items
Grouped by Architecture
A named transformation applied to a value inside a template expression.
Explore this clusterA typed event or request exchanged between decoupled Zotonic components through the notifier.
A server-defined browser action or event binding connected through Zotonic wires.
Explore this clusterA namespaced interface for retrieving or changing data and invoking operations in Zotonic or browser-side components.
Explore this clusterAn OTP application or site component that adds Zotonic behavior templates data and configuration.
Explore this clusterA server-side template_compiler document that renders data into HTML text email or another representation.
Explore this clusterA request handler that maps web requests to responses and coordinates authorization rendering or data transfer.
Explore this clusterA route declaration that matches a URL pattern and selects a controller with arguments.
Explore this clusterThe central Zotonic entity that represents content users media categories and other addressable objects.
Explore this clusterDocumentation not covered by the other keyword groups in this split.
Explore this clusterCheck media-process isolation and decide whether to run conversions on a separate service.
Prepare translations before making a language visible to visitors.
Request a backup and verify its completion and scope.
Adjust group upload limits and test with an ordinary account.
Set a relay at the correct scope and test a real site message.
Find the relevant failure without exposing credentials or personal data.
Test version-specific changes and establish a recovery point.
Verify host, role, database, and schema before restarting a site.
Separate environments and record how the site is operated.
Monitor the user-facing service as well as its processes.
Change module activation and verify the affected workflow.
Trace one message from request to recipient.
Separate node, site, database, and application failures.
Use revisions or deleted-page recovery for an editorial mistake.
Apply a tested revision and check the site from a visitor’s perspective.
Coordinate changes and verify service before reopening access.
Keep original uploads accessible across deployments and restarts.
Give the next operator enough context to continue safely.
Choose the right configuration layer and verify the effective value.
Run Zotonic under the installation’s service manager.
Prevent an acceptance workflow from emailing real users.
Recover code and data to a compatible state.
Align DNS, site selection, and certificate termination.
Restore into isolation and verify content, media, and access.
Choose recovery coverage, retention, and an owner.
Locate the failure in permission, storage, or processing.
Decrypt a local encrypted backup file.
Find obsolete access and verify who can administer the site.
Reset a site rate limiter.
Install the native tools, prepare PostgreSQL, and build a local checkout.
Prepare a site database and schema.
Test the configured PostgreSQL connection.
Connect an Erlang shell to the running node.
Restart one site.
Generate gettext translation template files.
Open the site URL in a browser.
Use the right management surface and account.
Inspect active Erlang processes.
Start Zotonic in the foreground without an interactive shell.
Set a global runtime Zotonic value.
Start a selected site on the node.
List configuration files selected for a site.
Compile, load, flush, and rescan the server.
Inspect dispatch rules or trace a URL.
Remove login methods and permissions without deleting their authored content.
Start Zotonic in the foreground with an Erlang shell.
Run site tests using an isolated test schema.
Stop one site.
Print recent lines from a configured log file.
Stop the Zotonic node.
Run selected core test modules.
Give an account the permissions required for its work.
Check a rule change before it affects everyone.
Enter the supplied OTP 28 development shell, prepare PostgreSQL, and build.
Show a site application directory.
Restart Zotonic and all sites within the current VM.
Display a site configuration resolved from files.
Start Zotonic in the background.
Load changed BEAM files.
Flush site caches.
Create and check the database used by a native development installation.
Wait until the node answers a ping.
Check whether global configuration files can be read.
Show node and site state.
Call an exported Erlang function on the node.
Identify where the site's archive files, generated previews, backups, and security files are stored. These have different retention and recovery needs.
Check each stage in order: the edited file, build output, loaded application, active module, selected template, and browser response.
Open Cross-reference check of templates in the Development page and run the check. Read each reported reference with the active module set in mind.
Define what must be recovered: database, original media, configuration, and security material. Check which parts the selected backup includes before depending…
Keep domain logic in small functions that accept explicit inputs. Test expected results, boundary values, and meaningful error cases without starting a full…
Choose roles that exercise the operation's permission boundary: anonymous visitor, limited editor, and administrator. Use separate browser sessions or an…
Choose checks for a change.
List selected global configuration files.
Open Dependency graph of all available templates from the Development page. Use the graph to understand inheritance and include relationships before changing a…
Keep development and production settings distinct.
Run bin/zotonic status to distinguish an unavailable node from a stopped or failing site. Inspect the relevant startup log before repeatedly restarting it.
The Development page has an option to enable an API for recompiling and rebuilding Zotonic. The model implements actions for recompiling, flushing caches, and…
Measure one representative request and identify whether time is spent in the browser, network, or server. Compare an initial request with a repeated request to…
Open the Development page's Live dependency graph of templates tool. Start a trace for your session, then load the page or path you want to inspect.
Check the requested path and compare its binary segments with the model callback patterns. Confirm that the callback returns the unused path in the required…
Render the changed page with realistic content. Include missing optional fields, a long title, several list items, and a second language when applicable.
Open Show an overview of all observers from the Development page. Find the notification and inspect the registered callbacks and their order.
Open the Development function tracing tool as the admin user. Enter a module, optionally a function, and a small limit on the number of calls.
Open System → Development and enable live reload. The page also enables separate CSS and JavaScript files when needed.
Change a dependency when you can identify the required fix or feature and the affected callers. Read its version constraints and inspect the resulting lockfile…
Reproduce one action with the browser console and network panel open. Check for a JavaScript error before the request, a failed request, or a successful…
Open the Development page's dispatch tools. Inspect the list of active rules, then trace the path that produces an unexpected result.
Open a site in Chrome.
Start with the symptom and use the smallest tool that explains it.
Use bin/zotonic setconfig only for a global setting that supports a runtime change. The command changes the running configuration and does not save the value…
Create a site application from a skeleton.
Open module management for the correct site. Check whether the module is disabled, waiting for a dependency, or failing during startup.
Check that the module is an Erlang application in a discovered project directory. Confirm the application name, .app.src, main mod_... module, and successful…
Enable module#mod_server_storage if the Development page says it is needed for database tracing. On the Development page, enable Trace all database queries for…
Prepare an isolated copy of the previously released application and database. Add representative edited content, then apply the new code and schema changes.
Sign in to the local site's admin as an administrator. Open the module management page, find Development (mod_development), and activate it if necessary.
Confirm the hostname, site, and path from the actual request. Use the dispatch trace to see the selected rule and any rewritten path.
First check which file is selected and whether the changed code compiled. Then repeat the request with the relevant cache disabled or flushed.
Recompile one Erlang source file.
Display configuration resolved from files.