# 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;