Velo: Testing and Troubleshooting Your Code

Wix provides several tools for testing and debugging the code in your site. You can start by testing your site in Preview mode before publishing. If you see errors or your site is not running as expected, there are more tools you can use to debug the code in your site: 

• Developer Console: Debug in Preview mode.
• Functional Testing: Trigger and debug backend code in the code editor.
• Developer Tools: Debug your published and test sites.
• Logs: Debug in Preview or Published mode.

Testing in Preview Mode

Test your site by entering Preview mode. To preview your site:

• Wix Studio: Either click the Run button in the code editor toolbar, or the preview button on the top right.

  

• Wix Editor: Either click on the Run button in the code editor toolbar, or the Preview button in the Editor on the top right.

  

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've finished 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 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.

Differences Between Preview and Published Site

Although your can view your pages and interact with your site and data in Preview mode, the site doesn't behave exactly as it does when published:

• When previewing your site, you are assigned the Admin role. That means you are granted all possible permissions. Users of your live site might have different permissions and therefore 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, only have the live database version. Any changes you make to these collections in Preview mode are reflected in your published site.  
• Backend events and several other APIs don't necessarily work when previewing your site.

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. If you are new to debugging code, click here to learn how to log messages to the console.

Each message displays the page where 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.

Viewing the Developer Console

To view the Developer Console, open your site in Preview mode. The Developer Console appears at the bottom of the page.

If the console is minimized, click the arrow to expand it.

Clearing messages from the console

Click on the console menu bar.

Filtering 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.

Functional Testing for Backend Functions

Debugging code from the backend is challenging because you need to invest effort to trigger the code and test it, such as calling functions from the client side on a test page in your site. To save you time and effort, Velo enables quick testing of backend functions directly from the code editor. The output you see in the test tab is the same as the output you would see in the Developer Console if you previewed your site and triggered the function.

HTTP Functions

You can debug HTTP functions by adding console.log() calls to them. The information you log appears in the function output when using functional testing (Wix Editor) and in your site's Logs.

Debugging with Your Browser's Developer Tools

Velo allows you to debug your site's code as you would any modern JavaScript web-based application, by using developer tools to set breakpoints, log to the console, and more. These tools are not part of Wix - they come with your browser. If you are new to debugging, learn how to log messages to the console.

You can debug:

• Your fully published site's code directly.
• A test site. To view a test site:
  • Wix Studio: Click the preview button on the top right. Then click Preview as Test Site.
  • Wix Editor: Click Preview on the top right. Then click Test Site. Learn more about creating a test site.

Here are a few things you need to know before you start debugging:

Accessing Client-Side Source Files

You can open a copy of your site's client-side code files in the browser's developer tools.

Here are the ways you can locate your code:

Searching for the file by name

1. 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.

2. Browse to your test or published site and open your browser's developer tools.
3. Open the file search bar. To do this in Chrome press command/Ctrl+O. In Firefox, open the Debugger panel in the developer tools and press command/Ctrl+P.
4. Type the name of your code file and select it from the search results to open it.

Using the debugger

Adding the debugger statement to your code halts code execution at that point and prompts your browser to display the code file in developer tools.

1. Add debugger; at the point in your code where you want the debugger to run.

2. Open your browser's developer tools and browse to your published site. The Sources panel opens to your code file and points to the line where you added debugger.

   

Expected Behaviors when Debugging Certain Velo Features

Note the following when debugging certain Velo features:

• Backend Code

  • Because of security concerns, messages in backend code might not be logged to the browser's console on the published version of your site.
  • For test sites, messages in backend code are not logged to the browser's console. Either the version of the event handler in your published site runs, or, if one does not exist yet in the published version, the event handler never runs.

• HTTP Functions

  • Because HTTP functions are not browser-based, messages might not be logged to the console when viewing the published version of your site. You can use Logs to view console messages in backend code and HTTP functions on your site.
  • For test sites, either the HTTP function in your published version runs, or, if one does not exist yet in the published version, clients are not able to reach that function.

• Scheduled Jobs For test sites, when you schedule jobs in your site's backend, only the jobs scheduled in your published site run. The jobs scheduled in your test site revision do not run.

Source Maps

When you debug your code in the browser it looks just like your original source code. In reality, the code 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. But if you're curious to know, this is what's happening.

Velo supports writing code using the ES2017 standard. But until this standard is fully implemented in all browsers, your code is transpiled from ES2017 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 Logs

Wix's Logs tool allows you to debug your site by generating and tracking logs. You can access the Logs tool directly from Preview mode. To get to the Logs tool, click on Live Site Logs then Wix Logs in your Developer Console.

Live Logs

You can view logs in real time in the Wix Logs 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 Wix Logs window.

You can click the log to view more information:

Google Cloud Logs

For more robust log analysis, you can easily connect your Wix Logs to Google Cloud Logs, an external monitoring tool.

Learn more about: 

• Viewing logs in your Wix Logs window
• Connecting to Google Cloud Logs
• How to generate a log using Logs
• Logs logging details

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 Logs 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.

   Copy

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 Logs) to gain insight on how your code is behaving.

Bypassing permissions with wix-auth elevate()

If you are receiving a 403 or FORBIDDEN error when you run a function, try using the elevate() function to bypass permissions.