Debugging

Troubleshoot setup issues, verify your configuration, and monitor real-time script activity through the browser console.

Logging

The TronDesigner Web Integration Script includes a built-in logging mechanism to help you debug and monitor editor behavior. Logging is client-side only (browser console).

Log levels

  • info: High-level information about normal operations.

  • warn (default): Non-fatal issues, configuration problems, missing attributes, etc.

  • error: Failures that prevent the Editor from working correctly.

  • debug: Most detailed information about internal behavior (for local development).

Messages with a severity lower than the current log level are not printed:

  • Level = warn → you see warn and error.

  • Level = error → you see only error.

  • Level = debug → you see everything.

Changing log level

Via JavaScript. You can adjust the log level at runtime using the JS API: (See More)

Example
// Set log level window.tronDesigner.setLogLevel("debug"); // allowed: "debug" | "info" | "warn" | "error" // Read current level const level = window.tronDesigner.getLogLevel(); console.log("Current TronDesigner log level:", level);

Via HTML. You can set the initial log level via the data-td-log-level attribute. See Reference.

What gets logged

The integration script tracks these key events in the browser console:

  • Script Startup: Logs from the automatic initialization process, including API Key verification and Target Environment (API URL) detection.

  • Attribute Detection: Identification of HTML elements using data-td-action and the parsing of their data-td-* values.

  • Manual Calls: Execution details for window.tronDesigner.openDesigner(...).

  • Validation Warnings: Feedback on missing or invalid data (e.g., supplier, product) required to launch the Editor.

  • Network & Security: API communication logs, including authentication (401), network connectivity, and invalid server responses.

  • Execution Failures: Internal errors or logic breaks that prevent the Editor from opening or completing an operation.

Best Practice

  • Development & QA: Use debug or info levels to verify your configuration, parsed attributes, and API traffic. This is essential when first implementing data-td-* attributes or openDesigner() calls.

  • Production: Use warn (default) or error levels to reduce console noise. This keeps the focus on critical issues while hiding normal operational logs from your end-users.

👉 For the exact values and definitions used in logging, refer to our auto-generated documentation: Full Tech Reference.