FirstSpirit Online Documentation - Debugging: Is an error present? How can errors be avoided?

Online Documentation

Start page / Template development / Debugging / Are there errors?

Is an error present? / How can errors be avoided?

Contents

• Searching for and analyzing errors in the template code

• Extended error logging mode

• Prompting an error message/setting a marker

• Client log

• Show logfile of the preview page

Errors in the programming of FirstSpirit templates, and/or unwanted consequences or results, can occur in different locations and can be diagnosed and, in some cases, avoided:

Phase	Category	Information about error
Development of forms and rules	Appearance and function / Preview	It is possible to check whether forms, with associated rules if applicable (exception: ONSAVE and ONLOCK), look and function as required directly in the integrated preview on the “Form” tab.
	Syntax errors	Some syntax errors on the form and rule tab are identified during the development stage. If, for instance, parameters or attributes are used incorrectly, the templates cannot be saved and a relevant reason for the error is displayed. The code completion function automatically ensures that only the parameters and tags that are available for the relevant input component are used.
	Editor instructions, reduction of incorrect entries	Form definition allows the developer to take various steps at the development stage, including adapting the functional scope of an input component to the needs of the project and the editors, restricting selection options, and defining mandatory fields, default values, and fallback values (see also Variables in templates).
	Editor instructions, reduction of incorrect entries	Rules can be used to influence particular properties or elements of forms. For example, they make it possible to check entries and respond accordingly. See the Rules chapter.
Output development	Coding conventions	To enable developers to work together efficiently in one project, for example, “meaningful” names should be used as far as possible for all templates and variables and developers should add comments to their own code (on template set tabs: $-- Comment --$).
	Coding conventions	To get a better overview of the variables used in a project, it is advisable to integrate a variable prefix into the identifier which indicates the definition location. This also ensures that variables are not overwritten. See also Coding conventions for variables.
	Appearance and function / Preview	To directly view the entries on the template set tabs and their effect using existing content, a page reference can be defined on the “Properties tab” in the “Preview page” field (for page templates, see Properties tab) that renders the content of the affected templates and is to be used as the preview for the output.
	Appearance and function / Preview	The Multi Perspective Preview (→Documentation FirstSpirit SiteArchitect) (“MPP”) makes it possible to check how website content looks in different display sizes, for special user groups, or at particular times.
	Syntax errors, logical errors, missing references	Any syntax errors in templates can be displayed in the project itself using the “Display preview errors” context menu function on pages and page references in SiteArchitect (see Context menu - Special (→Documentation FirstSpirit SiteArchitect)). Clicking on this will take the user directly to the spot with the error in the affected template.
	Syntax errors, logical errors, missing references	During a generation process, any syntax errors are recorded in a special log file: fs-schedule.*.log. General information on the operation of the FirstSpirit server as well as on actions and errors in projects is contained in the files fs-server.log (“Server log”) and fs-wrapper.log, as well as other log files in the ~\log directory.
	Editor instructions, reduction of incorrect entries	Instructions/functions such as $CMS_IF(...)$, if(...), or $CMS_FOR(...)$ can be used to respond to the values entered by the editor; for example, for empty/null checks, case differentiations, etc.
Testing, quality assurance, operation		Despite utmost care, some errors are only found once the template is physically used in the project. It is therefore recommended to develop and test the templates on a test system and only to use them in production after successful testing. Functions such as ContentTransport or Introduction (→Documentation “External Synchronization”) help the template developer in this regard.

Searching for and analyzing errors in the template code

Extended error logging mode

For the template development phase at least,

$CMS_SET(#global.debugMode,true)$

can be used to output detailed information about errors (“stack trace”) in the log on the output tab. This primarily concerns the generation log (fs-schedule.*.log); this additional information is always available in the preview (“Display preview errors” context menu entry on pages and page references).

Refer to the page on preview-based #global calls

The extended error logging mode can also be set in the template used for the Project settings (under the “Global settings” node in SiteArchitect). (De)activation of the extended error logging mode can be queried/controlled via the following form, for example, and will then apply to the entire project:

<CMS_INPUT_TOGGLE name="ps_debugMode" type="radio">
    <LANGINFOS>
      <LANGINFO lang="*" label="Debug mode"/>
      <LANGINFO lang="DE" label="Erweiterte Protokollierung"/>
    </LANGINFOS>
    <OFF>
      <LANGINFO lang="*" label="Disabled"/>
      <LANGINFO lang="DE" label="Deaktiviert"/>
    </OFF>
    <ON>
      <LANGINFO lang="*" label="Enabled"/>
      <LANGINFO lang="DE" label="Aktiviert"/>
    </ON>
</CMS_INPUT_TOGGLE>

The status (ps_debugMode variable) can then be queried in the required template(s):

$CMS_SET(#global.debugMode, ps_debugMode)$

If there are lots of errors, activating the extended error logging mode may adversely affect performance. To deactivate it, set #global.debugMode to “false” or remove it from the templates.

Prompting an error message/setting a marker

For direct debugging, the following line can also be added temporarily to the templates:

$CMS_VALUE(#global.logError("A severe error occurred!"))$

The position at which this error message was added can be identified quickly in the log (e.g., fs-schedule.*.log or “Display preview errors”). Variables can also be output instead of the text (in quotation marks), e.g.:

$CMS_VALUE(#global.logError("id: " + #global.id))$

(returns the ID of the node currently being rendered, e.g., page, section, etc.).

The methods

logInfo
logDebug
logWarning

can be used to set other log levels.

The following syntax is used in scripts:

context.logError("A severe error occurred!");

Script logging can be activated via the “Extras” / “Extended logging” menu in SiteArchitect. See Scripting chapter.

Client log

The client log may contain relevant log messages, too. You can open it using the menu “Help”. See also Help (→Documentation FirstSpirit SiteArchitect).

Show logfile of the preview page

To show the logfile of a preview page, simply add the parameter /showLog=1 to the preview page URL manually.