> Portal Navigation:
> 
> - Append `.md` to any URL under `https://dev.wix.com/docs/` to get its markdown version.
> - Pages are either content pages (article or reference text) or menu pages (a list of links to child pages).
> - To get a menu page, truncate any URL to a parent path and append `.md` (e.g. `https://dev.wix.com/docs/sdk.md`, `https://dev.wix.com/docs/sdk/core-modules.md`).
> - Top-level index of all portals: https://dev.wix.com/docs/llms.txt
> - Full concatenated docs: https://dev.wix.com/docs/llms-full.txt

## Resource: Where Do I Put My Code?

## Article: Where Do I Put My Code?

## Article Link: https://dev.wix.com/docs/develop-websites/articles/coding-with-velo/overview/where-do-i-put-my-code.md

## Article Content:

# About Code Placement

When developing websites, it’s important to understand where to place your code so it runs in the right context, whether that’s in the browser, on the server, or across all pages. This article gives an overview of the different types of code files available, and explains when and how to use each one.

## Supported IDEs

You can store your code using the following IDEs:

- The [editor](https://dev.wix.com/docs/develop-websites/articles/workspace-tools/velo-workspace/workspaces/wix-studio-working-with-the-code-panel.md) (Wix Studio and Wix Editor)
- The [Wix IDE](https://dev.wix.com/docs/develop-websites/articles/workspace-tools/velo-workspace/wix-ide/wix-studio-about-the-wix-ide.md)
- Your [local IDE](https://dev.wix.com/docs/develop-websites/articles/workspace-tools/developer-tools/git-integration-wix-cli-for-sites/about-git-integration-wix-cli-for-sites.md)

## Frontend code

Frontend code runs in the site visitor’s browser and here you define the interactive parts of your site. This includes things like:

- Responding to user input
- Updating the UI
- Making calls to backend services

Since this code is exposed to the public, avoid including sensitive information, such as API keys or private logic.

Use frontend code for:

- Customizing how a page looks or behaves
- Listening for events like button clicks or form submissions
- Calling functions defined in backend web modules (`.web.js`)

### Running code on all pages with Global code

Global code is code that runs on every page of your site. This is logic that's shared across all pages, such as managing a universal header or footer, or controlling global UI elements like a site-wide search bar or shopping cart icon.

To add global code, edit the `masterPage.js` file. You'll find it in:

- Wix Studio: The **Page Code** section of the **Code** panel
- Wix Editor: The **Page Code** section of the **Code** sidebar
- Local IDE: The `src/pages` folder when using [Git integration](https://dev.wix.com/docs/develop-websites/articles/workspace-tools/developer-tools/git-integration-wix-cli/about-git-integration-wix-cli/.md)

<blockquote class="important">

**Important:** `masterPage.js` has its own `onReady` event handler. Be careful not to duplicate logic from individual page `onReady` handlers, as both run in parallel.

</blockquote>

#### Retaining an element's state

You can also use global code to retain an element’s state across pages. For example, if you change the source of an image element that appears on all pages, that change won’t persist when navigating to another page, or even when returning to the original page.

To make changes persistent across pages, use the [`wix-storage-frontend`](https://www.wix.com/velo/reference/wix-storage) API:

1. In the relevant event handler, call [`setItem`](https://www.wix.com/velo/reference/wix-storage/storage/setitem) to store a value that reflects the element’s new state.

1. In the `masterPage.js` `onReady` function, read the stored value and update the element accordingly.

> **Note:** Avoid importing functions from `masterPage.js` into individual page files. Doing this causes the `onReady` function in `masterPage.js` to run twice on those pages. For shared logic, create code on a separate public file and import it where needed.

### Running code on a specific page

Each page on your site has its own code file. Use these files to add functionality that's specific to that page, for example:

- Handling user input
- Customizing UI behavior
- Calling backend functions.

#### Public files

If you find yourself repeating the same code across multiple page files, it's better to move shared logic to a separate **public** file. That way, you can write it once and import it wherever it's needed: Whether in a page file, a backend file, or another public file.

To share a function across multiple files:

1. Create a public file and export the function from it.

1. Import the function into any page where it’s needed.

You can find your public files in:

- Wix Studio: The **Backend & Public** section of the **Code** panel
- Wix Editor: The **Backend & Public** section of the **Code** sidebar
- Local IDE: The `src/public` folder when using [Git integration](https://dev.wix.com/docs/develop-websites/articles/workspace-tools/developer-tools/git-integration-wix-cli/about-git-integration-wix-cli/.md)

Use ES module syntax (`import`/`export`) to access functions between files. Always include the function name in curly braces when importing a named export:

```js
import { myFunction } from 'backend/bookings.js'
```

Leaving out the curly braces attempts to import a default export:

```js
import myFunction from 'backend/bookings.js'
```

Unless `myFunction` was explicitly exported as the default, this will throw a runtime error:

```js
(0 , \_bookings.default) is not a function
```

To access all functions from a module, import the entire module without curly braces:

```js
import wixData from 'wix-data';
import wixStoresFrontend from 'wix-stores-frontend';
import wixMembers from 'wix-members-backend';
```

<blockquote class="tip">

**Tip:** Your page code, which is also publicly accessible, doesn't appear in the list of public files. To see your page code, go to the **Page Code** section and click on the page in the menu.

</blockquote>

### Responding to element actions with event handlers

Page elements like buttons, text, and input fields can trigger events when site visitors interact with them. The functions that handle these events are called event handlers.

There are following types of event handlers:

- Dynamic event handlers. Learn how to add an event handler in [Add an Event Handler](https://dev.wix.com/docs/develop-websites/articles/coding-with-velo/frontend-code/add-an-event-handler.md).
- Static event handlers (deprecated). Learn more about static event handlers in [About Static Event Handlers](https://dev.wix.com/docs/develop-websites/articles/coding-with-velo/frontend-code/about-static-event-handlers.md).

### HTML

Adding raw HTML directly in the code editor isn't supported.

That said, there are several ways to include or work with HTML on your site:

- Add marketing code using [marketing integrations](https://support.wix.com/en/marketing-tools/marketing-integrations-tracking).
- Set the [HTML property](https://www.wix.com/velo/reference/$w/text/html) of a text element to render HTML content.
- Display external HTML content by [embedding a site element](https://support.wix.com/en/article/wix-editor-using-iframes-to-display-visible-content-on-your-site).
- Insert [custom code snippets](https://support.wix.com/en/article/embedding-custom-code-to-your-site) into the head or body of your site pages.
- Use [custom elements](https://support.wix.com/en/article/wix-editor-adding-a-custom-element-to-your-site) to define and embed your own HTML-based components.

## Backend code

Backend code runs on Wix’s secure servers and isn’t exposed to site visitors. This is the place for logic that needs to be protected, like:

- Interacting with sensitive data
- Sending emails
- Handling payments
- Verifying permissions

Use backend code for:

- Perform secure database operations
- Respond to frontend requests by using web modules
- Handle server-side events and scheduled tasks
- Expose custom HTTP methods to other services

### Backend files

Backend files are where you define server-side logic. They include code that runs securely on the web server rather than in the browser. This is where you define functions from backend libraries such as `wix-pay-backend`, `wix-members.v2`, or `wix-events.v2`.

You can find your backend files in:

- Wix Studio: The **Backend & Public** section of the **Code** panel
- Wix Editor: The **Backend & Public** section of the **Code** sidebar
- Local IDE: The `src/backend` folder when using [Git Integration](https://dev.wix.com/docs/develop-websites/articles/workspace-tools/developer-tools/git-integration-wix-cli/about-git-integration-wix-cli/.md)

There are 2 main file types used in the backend:

- **.web.js:** Web modules that can be called from the frontend. You can configure permissions for each function to control who can access them. Learn more about the .web.js files in [About Web Modules](https://dev.wix.com/docs/develop-websites/articles/coding-with-velo/backend-code/web-modules/about-web-modules.md).
- **.js:** Internal backend files that can't be accessed directly from the frontend. Use these for secure server-side logic.

> **Note:** You may also see `.jsw` files in older projects. These have been deprecated in favor of `.web.js` files but are still supported. Learn more about the .jsw files in [Call Backend Code from a jsw Web Module](https://dev.wix.com/docs/develop-websites/articles/coding-with-velo/backend-code/web-modules/call-backend-code-from-a-jsw-web-module.md).

#### Accessing functions from a .js file

To access functions from a `.js` file in the frontend, import the function into a `.web.js` file first, then import that `.web.js` function into your frontend code.

Import the `.js` file into the `.web.js` file:

```js
import { Permissions, webMethod } from 'wix-web-module';
import { deleteStaffMember } from 'backend/bookings'

export const deleteStaff = webMethod(
    Permissions.Anyone,
    async (staffMemberid) => {
        return await deleteStaffMember(staffMemberid);
    }
);
```

Import the `.web.js` file in your page file:

```js
import { deleteStaff } from 'backend/staff.web'
```

If you try to import a `.js` file directly into a frontend file, you'll see this error:

```
Access to backend script 'backend/calculations.js' denied! Client-side scripts can only import web-modules from backend code context.
```

### Backend events

Many Wix modules provide built-in events that trigger when specific actions occur. For example, uploading a file to the Media Manager triggers the `onFileUploaded` event, and successfully paying an invoice triggers the `onInvoicePaid` event. These events let you run custom logic in response to key moments in your site’s workflow.

To run an event, you need to add an `events.js` file. Learn more about adding backend events in [About Backend Events](https://dev.wix.com/docs/develop-websites/articles/coding-with-velo/backend-code/events/about-backend-events.md).

### Handling HTTP requests

To expose your site’s functionality to the outside world, like enabling `GET`, `PUT`, `POST`, or `DELETE` requests from external services, you can define custom HTTP methods.

To create an HTTP function, you need to add an `http-functions.js` file. Learn more about the HTTP functions in [About Custom Site APIs](https://dev.wix.com/docs/develop-websites/articles/coding-with-velo/integrations/exposing-services/about-custom-site-apis.md).

### Using data hooks when data collection changes

Data hooks let you run code before or after changes are made to your site’s data collections. They’re useful for validating, modifying, or responding to data operations like insert, update, or remove.

To create data hooks, add a `data.js` file to your backend code. You can then define functions that correspond to specific data operations on your collections. Learn more about data hooks in [Using Data Hooks](https://dev.wix.com/docs/develop-websites/articles/databases/wix-data/hooks/using-data-hooks.md).

### Routers

By default, Wix uses built-in routers to handle dynamic page URLs and SEO. If you need more control over how incoming requests are handled, you can create your own custom router to define the logic, routing, and data for each request.

The code for both routers and data binding router hooks is defined in the `routers.js` file. Learn more about routers in [About Routers](https://dev.wix.com/docs/develop-websites/articles/coding-with-velo/routers/about-routers.md).

## Secrets Manager

For sensitive information like API keys, OAuth tokens, or configuration settings, use the [Secrets Manager](https://dev.wix.com/docs/develop-websites/articles/workspace-tools/developer-tools/secrets-manager/about-the-secrets-manager.md) instead of hardcoding values into your code. Secrets are stored securely in your [site's dashboard](https://www.wix.com/my-account/site-selector/?buttonText=Select%20Site&title=Select%20a%20Site&autoSelectOnSingleSite=true&actionUrl=https:%2F%2Fwww.wix.com%2Fdashboard%2F%7B%7BmetaSiteId%7D%7D%2F/developer-tools/secrets-manager) and can be retrieved in code using the [Secrets API](https://dev.wix.com/docs/velo/apis/wix-secrets-backend-v2/introduction.md).

Storing secrets in the Secrets Manager improves your site's security, especially when you're collaborating with others or using version control. Each secret has a unique name, and you can access it safely in backend code without exposing it to site visitors.

## See also

- [About Event Handlers in Wix](https://dev.wix.com/docs/develop-websites/articles/coding-with-velo/frontend-code/about-event-handlers-in-wix.md)
- [About the Site Backend](https://dev.wix.com/docs/develop-websites/articles/coding-with-velo/backend-code/about-the-site-backend.md)
- [Secrets Manager](https://dev.wix.com/docs/develop-websites/articles/workspace-tools/developer-tools/secrets-manager/about-the-secrets-manager.md)