Testing and Debugging Your Code

Tools for testing and debugging the code

Testing in Preview mode

Test your site by entering Preview modePreviewmode. You can perform any actions that you would be able to perform on your live site. When testing your site, you can check if any errors appear in the Wix Developer Console.

When you finish previewing and return to the Editor, interactions you had with your site are not maintained. Your site returns to the state it was in before you entered Preview mode. The only exception is your optional sandbox database.

If you interact with data from your collections, you will be using the optional sandbox (and not a live) version of your collections. Changes to data that result from interactions with your site in Preview mode will persist in your optional sandbox database.

Velo functionality is only available when you enter Preview mode from the Editor and not from the Site Actions dropdown in the Dashboard.

Differences between Preview mode and Published site

Although your can view your pages and interact with your site and data in Preview mode, the site will not behave exactly as it will when published:

• When previewing your site, you are assigned the Admin rolePermissions give you control over which visitors are allowed to interact with the data in your collections and what they are allowed to do.. That means you are granted all possible permissions. Users of your live site might have different permissions and therefore will have more restricted access.

• When previewing your site with Sandbox enabled, you will be working with the data in your site’s optional sandbox database. Users of your live site will be working with your live database.

  • Wix app collections, however, are read-only and only have the live database version. Any changes you make to these collections in Preview are reflected in your published site.

• Backend events and several other APIs don’t work when previewing your site.

You can test a release candidate of your Published site on a small percentage of visitors using the Release Manager. This is helpful for testing functionality that only works on a published site without exposing that functionality to all site visitors.

Debugging with the Developer Console

The Wix Developer Console is available at the bottom of the page when you are previewing your site. The console displays information that is useful when debugging, such as errors, warnings, and other messages.

It also displays debug messages that you added to the code using any console method.

Each message displays the page the relevant code can be found and a clickable link to the specific line of code that triggered the message. Note that even if Velo is not enabled, your code will run when you preview your site.

To view the Developer Console:

In Preview mode, click the arrow at the bottom of the page.

Note: The Developer Console is collapsed by default unless your code has errors or you logged messages to the Console.

To clear messages from the Console:

Click Clear Console on the Console menu bar.

To filter Console messages:

Click Default View on the Console menu bar, and then choose which kinds of messages you want to see.

• Verbose: System log messages that can help you debug low-level code problems.
• Debug: Messages you have logged to the console.
• Info: Informational messages that require no action.
• Warning: Messages about potential problems in your code. These are highlighted in yellow.
• Error: Messages about actual errors in your code. These are highlighted in red.

Backend code

Debugging code from the backend is more challenging because you don’t have direct access to the backend itself. To make debugging of backend code easier, errors and debug messages from your backend code are sent to the Developer Console when possible.

HTTP functions

You can debug HTTP functions by adding console.log() calls to them. The information you log appears in your site’s Developer Console when previewing your site. Since message logging only runs in preview, you need to call the testing version of your endpoints to see what is logged.

To debug using console.log() in an HTTP function:

1. Add the call to console.log() in your HTTP function’s code.
2. Save your site.
3. Preview your site.
4. Call the testing endpoint (the URL with _functions-dev) from an external application.
5. The logged messages appear in your site’s Developer Console.

Note: You can also debug HTTP functions using Site Monitoring.

Debugging with developer tools

Velo allows you to debug your published site’s code as you would debug any modern JavaScript web-based application: by using the developer tools of your browser. However, there are a few things you need to know before you start debugging.

Client-side source files

You can debug your client-side code using developer tools. These tools are not part of Wix; they come with your browser. You can debug it as you would debug any other site by setting breakpoints, logging to the console, etc.

After this, you open the files using your browser’s developer tools. First, identify the names of the files that contain your site’s client-side code. The names of these files appear in the Wix Developer Console when you preview your site.

Then open the files using your browser’s developer tools.

Backend code & HTTP functions

Because of security concerns, messages in the backend code are not logged to the browser’s console on the published version of your site.

Because HTTP functions are not browser based, messages are not logged to the console when viewing the published version of your site.

You can use Site Monitoring to view console messages in the backend code and HTTP functions on the published version of your site.

Source maps

When you debug your code in the browser, it looks just like your original source code. In reality, the code that you write is not the actual code that is run. The usage of source maps means that you don’t need to worry about what’s going on behind the scenes.

Velo supports writing code using the ES2019 standard. But until this standard is fully implemented in all browsers, your code is transpiled from ES2019 code to ES5. Your code is also minified, and source files are combined to make their delivery from the server more efficient.

So the code that’s actually being run on your site is transpiled, minified, and combined. You don’t want to have to debug that generated code. You want to debug the code you wrote originally. That’s where source maps come in.

A source map is a file that maps the lines of code that the browser is actually running to the lines in your original source code. When you want to debug some code, the source map lets you find the code in the original version that you wrote, even though the debugger uses the source map to run the corresponding generated code.

All this should happen without you having to do anything. If you’re having trouble, check your browser’s developer tools settings and make sure that source maps are enabled.

Debugging with Site Monitoring

Wix’s Site Monitoring tool allows you to debug your site by generating and tracking logs. Site Monitoring is located in your site’s dashboard under Settings.

Notes:

• You can use site monitoring to generate logs from client-side code, backend code, public code, HTTP functions, or anywhere else in your site.
• You can monitor site logs in both Preview mode and on your Published site.

Live site events

You can view event logs in real time in the Site Events window. Simply add a console message to any code in your site, trigger the code in Preview mode or on your published site, and the log will appear in your Site Monitoring site events window.

You can click the log to view more information:

Google Operations

For more robust log analysis, you can easily connect your Wix site events to Google Operations, an external monitoring tool.

Logging messages to the console

If you’re not familiar with logging messages to the console to debug your site, follow the instructions below to log messages to the Developer Console, Developer Tools, or to the Site Monitoring tool:

1. Add any console message to the code you want to debug.

   For example, let’s say you have a function called myFunc() that performs an operation on a variable called myVar. You want to check whether the function is being called and whether the operation on the variable is performed as expected. You can add the code below to your function. When the console message runs, the text within the quotes will be displayed as well as the value of the myVar variable.

2. In Preview mode or on your Published site, perform whatever action will trigger myFunc().
3. View the message in your tool of choice (Developer Console, Developer Tools, or Site Monitoring) to gain insight into how your code is behaving.