# Webflow Site Configuration

**Sygnal DevProxy** works by swapping out `<script>` and `<link>` source references at the reverse-proxy level.

## Code Constructions&#x20;

We specify the setup we want using code constructions.

Here is a typical CSS link and script reference that you might have in your Webflow site. It happens to be for Sygnal's new SA5 Modals feature.&#x20;

{% code overflow="wrap" %}

```html
<!-- Sygnal Attributes 5 | Modals --> 
<link rel="stylesheet" href="https://cdn.jsdelivr.net/gh/sygnaltech/webflow-util@5.4.1/dist/css/webflow-modal.css">
<script defer src="https://cdn.jsdelivr.net/gh/sygnaltech/webflow-util@5.4.1/dist/nocode/webflow-modal.js"></script>
```

{% endcode %}

When we want to support DEV, TEST and PROD mode distinctions here, we adjust these to code constructions that look like this;&#x20;

{% code overflow="wrap" %}

```html
<!-- Sygnal Attributes 5 | Modals --> 
<link rel="stylesheet" 
  href="https://cdn.jsdelivr.net/gh/sygnaltech/webflow-util@5.4.1/dist/css/webflow-modal.css"
  dev-href="http://127.0.0.1:4000/dist/css/webflow-modal.css"
  test-href="https://cdn.jsdelivr.net/gh/sygnaltech/webflow-util-test@5.4.1/dist/css/webflow-modal.css"
  > 
<script defer 
  src="https://cdn.jsdelivr.net/gh/sygnaltech/webflow-util@5.4.1/dist/nocode/webflow-modal.js" 
  dev-src="http://127.0.0.1:4000/dist/nocode/webflow-modal.js"
  test-src="https://cdn.jsdelivr.net/gh/sygnaltech/webflow-util-test@5.4.1/dist/nocode/webflow-modal.js"
  ></script>
```

{% endcode %}

Note the differences;

* There are now additional attributes named `dev-src` and `dev-href`.&#x20;
* And attributes named `test-src` and `test-href`.&#x20;

{% hint style="info" %}
The line breaks and indents shown here are not necessary, but they make the CC easier to read and adjust. &#x20;
{% endhint %}

## How DevProxy Works

Generally speaking, DevProxy is setup to be in one of three modes;

* DEV mode, in which source code is running on the developer's local machine or development server.
* TEST mode, in which source code is running from a test server.
* PROD mode, in which source code is running as usual from the production environment.

When DevProxy is in DEV mode;

* It will look for `<link>` elements that have a `dev-href` attribute. When found, it will overwrite the `href` attribute with the value from the `dev-href` one.&#x20;
* It will look for `<script>` elements that have a `dev-src` attribute. When found, it will overwrite the `src` attribute with the value from the `dev-src` one.&#x20;

The same process occurs when DevProxy is in TEST mode, but using the `test-` prefixed attriutes.&#x20;

In PROD mode, DevProxy does nothing, and leaves the attributes untouched.&#x20;

{% hint style="info" %}
We typically use `dev-` and `test-`, but in fact DevProxy can have any number of different modes you want, if you have a use case for it.&#x20;
{% endhint %}

## DevProxy Groups

**CC's can also be grouped into control sets, using another attribute, `dpx-group`.**

Early incarnations of DevProxy had a global on/off state, but we found that wasn't practical for more complex sites. In some cases we might need some CC's to be in a PROD state while others are in DEV and still others in TEST.&#x20;

A common example is when we are using both SSE and Sygnal Attributes 5 ( SA5 ) together in the same site, both with DevProxy CC's. In those cases, a global switch didn't work.&#x20;

This is the purpose of groups.&#x20;

When a CC contains the `dpx-group` attribute, DevProxy *adds* the ability to set the DevProxy state at the group level.

Let's suppose your page has various DevProxy CC's on it, some which have group `group1`, some which have `group2` and some which lack the `dpx-group` attribute and therefore have no group.&#x20;

DevProxy configuration will recognize 3 different settings, for a total of 9 possible configurations.&#x20;

* `group1` elements can be in DEV, TEST, or PROD mode.&#x20;
* `group2` elements can be in DEV, TEST, or PROD mode.&#x20;
* All other elements can be in DEV, TEST, or PROD mode.&#x20;

This makes it easy to isolate your development and testing to different parts of your infrastructure.&#x20;

Here a real-world example where we use this;&#x20;

These CC's have a group of `sa5`.

{% code overflow="wrap" %}

```html
<!-- Sygnal Attributes 5 | Modals --> 
<link rel="stylesheet" 
  href="https://cdn.jsdelivr.net/gh/sygnaltech/webflow-util@5.4.1/dist/css/webflow-modal.css"
  dev-href="http://127.0.0.1:4000/dist/css/webflow-modal.css"
  devproxy-group="sa5"
  > 
<script defer 
  src="https://cdn.jsdelivr.net/gh/sygnaltech/webflow-util@5.4.1/dist/nocode/webflow-modal.js" 
  dev-src="http://127.0.0.1:4000/dist/nocode/webflow-modal.js"
  devproxy-group="sa5"
  ></script>
```

{% endcode %}

While this one has a group of `sse`.

```html
<!-- Site Engine (SSE) -->
<script 
  src="https://my-site.netlify.app/index.js"
  test-src="https://my-site-test.netlify.app/index.js"
  dev-src="http://127.0.0.1:3000/dist/index.js"
  devproxy-group="sse"
  ></script> 
```

In this way, we can develop just one part in isolation, or both concurrently.&#x20;


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://engine.sygnal.com/devproxy/webflow-site-configuration.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.