Most Dubsado form code that “stopped working” was never broken. It was placed where it cannot run. Dubsado custom CSS belongs in one place, scripts and new content belong in another, and the two do not substitute for each other. When code lands in the wrong one, the form gives no error. It just ignores the code, or applies it somewhere you did not intend.
This post maps where each kind of form code goes, what happens when it goes somewhere else, and how to find the cause when two pieces of code work alone but fail together.
Two places code can live in a Dubsado form
Dubsado gives every form two separate places for custom code. Each has a defined job.
The CSS editor
Open the form from Templates, then Forms. Click Form styling (the palette icon), then Edit CSS. This is the CSS editor. Dubsado recommends it for all of a form’s CSS, and it is available on every form type.
The CSS editor accepts CSS rules and nothing else. You do not need <style> tags here. Write the rules directly.
The HTML block
The HTML block (formerly called the code block) is an element you drag onto the form itself. It accepts HTML, CSS inside <style> tags, and JavaScript inside <script> tags. Use it for anything that adds content or behavior: a slider, a custom button, an embedded video, or a script that loads from an external file.
HTML blocks are available on questionnaires, proposals, and lead captures. Dubsado does not allow them on contracts or sub agreements.
The working rule is simple. Styles go in the CSS editor. Anything that has to run goes in an HTML block.
What happens when code goes in the wrong place
Placement errors are hard to spot because nothing on the form tells you something is wrong. Three patterns account for most of them.
A script in the CSS editor never runs
Everything in the CSS editor is treated as styling. Paste a block that contains <script> tags there and the script does not load. If you inspect the live form, the code shows up as plain text inside a style tag, doing nothing.
This catches a lot of template installs. Many form templates ship a main code block that loads the template’s scripts and stylesheets from external files. If that block goes into the CSS editor instead of an HTML block, every feature that depends on a script stays inactive. Features that only need CSS may still appear to work, which makes the problem look partial and random.
HTML in the CSS editor can also break the CSS rules that come after it. If a form’s styling is half applied, check the CSS editor for anything that is not a CSS rule.
A hiding rule in the CSS editor reaches the builder
CSS in the CSS editor applies inside the form builder as well as on the live form. Dubsado notes that selectors which are too broad, or which match selectors the builder already uses, can make the builder look broken.
A common version of this: a rule meant to hide helper labels from clients also hides them from you while you edit. The labels still exist. The rule just reaches farther than intended.
The fix is scope. Write selectors that target only elements inside the form, and test any hiding rule in the builder before you rely on it.
JavaScript in an HTML block does not run in the builder
This one is expected behavior. Dubsado does not run JavaScript while you edit. A block that contains script shows a placeholder that reads “This block contains code that cannot be displayed while editing.”
The script itself is fine. Click Preview, or open the form as a client, to see it work. Any styling that depends on a script, including stylesheets loaded through an HTML block, also appears only in Preview and on the live form.
When two pieces of form code conflict
Sometimes the placement is correct and the code still fails. The usual cause is two pieces of code that each work alone but interfere once they share a form.
We fixed one of these recently in our own conditional logic code. Our form templates include a script that moves the submit button to a marked block anywhere on the form. Our conditional logic script collapses its small helper blocks so they leave no gaps on the live form. The move-submit block carried the same kind of helper label, so the conditional logic script collapsed it too. The button was moved into a block with zero height and hidden overflow. It was on the page, but no one could see it.
The symptom was inconsistent. The button showed on some page loads and disappeared on others. Dubsado builds the form a moment after the page loads, so the result depended on which script ran first. Inconsistent behavior across refreshes usually points to timing between scripts, not to the form itself.
Because the code loads from one shared file, the fix went into that file. Forms using it picked up the change on their next load, and buyers did not need to edit anything.
To find a conflict on your own form:
- Remove one piece of code at a time and preview after each change. The piece that restores normal behavior when removed is part of the conflict.
- Right-click where the missing element should be and choose Inspect. Look for inline styles such as
height: 0,display: none, oroverflow: hiddenon the element or the block around it. - Refresh the preview several times. If the result changes between loads, look at the order the scripts run in.
- Check the code source. If two snippets come from different vendors, contact the vendor whose code changes the element. Dubsado’s Customer Care does not support forms with custom code.
A placement check for any Dubsado form
Before you troubleshoot the code itself, confirm the structure around it.
- The CSS editor contains only CSS rules. No
<script>, no<link>, no HTML. - Every script and every external stylesheet link sits in an HTML block on the form.
- Hiding rules are scoped to the form and checked in the builder.
- Script behavior is tested in Preview, not in the builder.
- CSS is organized with comments so each snippet’s purpose is clear. See how to organize Dubsado CSS code with comments.
- Shared styles that repeat across forms live in one external file, so a change reaches every form at once. See how to use external CSS files for Dubsado customizations.
A note on legacy mode
Forms created before Dubsado launched its new form builder on July 12, 2022 default to legacy mode on. The setting is in Form settings (the gear icon). Legacy mode exists because the new builder changed the HTML and CSS structure clients see, and older custom code was written against the old structure.
Dubsado recommends updating code so it works with legacy mode off. If a legacy form looks wrong, turn legacy mode off, open Preview, and use your browser’s inspector to see which selectors no longer match. Save the form with legacy mode off once the code is updated. Also confirm that any images or files the form loads from another site still exist there. A form can render normally and still show blank spaces where external images used to be.
Where this fits in a structured form system
Placement is a structural decision, not a styling one. When every form follows the same pattern, CSS in one place and scripts in another, problems are easier to trace and updates reach every form the same way.
The Forms & Flows Dubsado form templates are built on that pattern, with a main code block that loads shared files and a CSS editor kept for styling. Dubsado conditional logic adds show and hide behavior through the same structure. For individual changes, the Dubsado CSS code snippets collection includes FLORA to guide each adjustment.
If you would rather have the forms, workflows, and code set up for you, Dubsado setup with Cait Potter covers the full build.
For the basics of adding an HTML block, start with how to add CSS code to your Dubsado forms.
Clear placement. Scoped rules. Code that runs where it should.
FAQ
Do I need style tags in the Dubsado CSS editor?
No. The CSS editor expects CSS rules only. Style tags are needed only when you add CSS inside an HTML block.
Why does my code block say it cannot be displayed while editing?
Dubsado does not run JavaScript in the form builder. The block is working. Click Preview to see it.
Can I add custom code to a Dubsado contract?
Not through an HTML block. Dubsado allows HTML blocks on questionnaires, proposals, and lead captures, but not on contracts or sub agreements.
Why did my form’s helper labels disappear in the builder?
A hiding rule in the CSS editor is most likely reaching the builder. Scope the rule so it targets only the live form, or remove it and check again.
Will Dubsado support help fix custom form code?
No. Dubsado’s Customer Care does not support forms with custom code. Contact the developer or vendor who wrote the code.
