Skip to main content
With the $wsTestMode module, you can check whether test mode is active and control content accordingly. In test mode, you can test new functions, designs, or products without them being visible to regular visitors. In addition, the module indicates whether debugging is enabled, whether payments in test mode should be simulated as failed, whether the storefront should use the test API of the WEBSALE search, and whether the shop compiles the views from the template sources on every request. In this section, you will learn how to query the test mode and display test-specific content.

Module overview

Example / excerpt of $wsTestMode
JSON output
Variables overview

Templates

Using the template engine, certain content can be made specifically visible for test mode. This makes it possible to test special functions or designs without them being visible to regular visitors of the shop. A special view template in the views directory is required for password entry to activate test mode. Which template the shop uses is defined by the template parameter under general.testMode. Without a custom value, the name is testModeLogin.htm. In the WEBSALE themes, the template is called testMode.htm. This name must then be stored in the template parameter. The template can be renamed. The new template name must then be stored in the template parameter. The setting is located in the admin interface in the same place where the password for test mode can be stored and changed. If test mode is to be controlled from a custom storefront, the endpoints of the Storefront API test mode are available.

Variables

$wsTestMode.active

Returns whether test mode is enabled.

$wsTestMode.debug

Returns true if extended debugging is enabled. In debug mode, additional information, for example on variable values or loading times, is displayed.

$wsTestMode.makePaymentFail

Returns true if payments in test mode are simulated as failed. The simulation is switched on when test mode is activated via the makePaymentFail parameter of the TestModeOn action and can then be changed via the TestModeChange action. This causes orders to run into the error case on purpose, so that the templates and workflows designed for it can be checked.

$wsTestMode.searchTestApi

Returns true if the storefront should use the test API of the WEBSALE search instead of the production API. The switch is set when test mode is activated via the searchTestApi parameter of the TestModeOn action and can then be changed via the TestModeChange action. The switch does not change anything in the shop itself. The shop does not call the WEBSALE search itself but merely passes the value on. Based on this value, the storefront decides which API of the WEBSALE search it addresses.

$wsTestMode.compileTemplates

Returns true if the shop compiles the views from the template sources on every request instead of loading them from the precompiled theme. This makes changes to the templates visible immediately in test mode. Because compiling on every request takes time, the switch is only suitable for testing. It is set when test mode is activated via the compileTemplates parameter of the TestModeOn action and can then be changed via the TestModeChange action.

Methods

No methods are available for $wsTestMode.

Actions

No actions are available for $wsTestMode.

Examples for using test mode

The link can be sent once you have informed the shop operator that changes have been integrated in test mode and that they can view them via the following link:

Check whether test mode is active

Deactivating global test mode

An option to deactivate test mode can also be offered directly in the online shop in order to switch back to the online shop.
More practical examples for implementing the test mode page can be found here:
→ Practical examples: test mode