The editor is flexible in that it allows you to both modify existing code or add your own. Doing this allows you to extend the functionality of the platform and provides you with additional features. For example, you can add a custom calendar widget or even a third-party custom contact form for taking payments on your site.
Warning
Developer mode is not available when you are editing the site in flex mode in the Classic Editor. You must exit flex mode to access Developer Mode.
There are several ways you can add custom code: via developer mode or the HTML widget. Following are instructions on how to access both.
Note
Custom code that is intended to be visible in the site should be added using a HTML widget. Custom code that is not should usually be put in the header. In general, it is always best to first follow the directions provided by the code's writer before adding it to your site.
Developer Mode gives you access to edit and change your site's HTML and CSS. Adding custom code allows for advanced customization that is not possible with the drag and drop editor, however this should only be performed by advanced users with a solid understanding of web development code.
To access Developer Mode:
The HTML widget is the easiest method of adding custom code to your site. Depending on where you place your HTML widget, it will either appear on all pages of your site or just a single page. If you place the HTML widget in either the header or the footer, it will be placed on all pages of the site at the same time. This is because every site shares the header and footer. If you place the HTML widget anywhere else, it will appear only in the body.
In the side panel, click Widgets, and drag the HTML widget into a column or row into your site and paste in your code.
You can place code in the site-wide header or the header for an individual page.
Note
Consent management apps are not able to prevent code from running prior to consent when the code is placed in the header HTML. This is because we optimize the structure and order of how content loads, based on performance best practices on the site. We place scripts and CMP banners lower on the page, in order to improve the performance of primary content. Because of this, it is recommended to place code in the body-end when using a consent management app.
It is common for pixel tracking codes to disappear when placed in the header. The head section <head> does not accept any code that is <img>, <iframe>, and more. It normally only takes <link>, <script>, and <meta>.
If you have to paste code that's not being saved in the head section, paste it in the header or in the body-end.html. To do so, follow the steps in the Custom Code After the Opening Body Tag section of this article.
We currently do not have a feature to place code directly right after the opening body tag. However, you can paste code directly into the body-end.html file. There are two ways to do this, in developer mode or in settings.
To paste code directly into the body-end.html file in developer mode:
-
Click the Developer Mode icon (
) in the top bar.
-
Click Site HTML / CSS to expand the selection.
-
Click body-end.html.
-
Paste your code into the last line here.
-
Click Save and Done.
To paste code directly into the body-end.html file in settings:
Many elements, including rows, columns, and widgets offer the ability to access its HTML/CSS.
If you are in Classic Editor using flex mode or in Editor 2.0, you can edit the CSS of flex containers (section, column, inner column, and advanced grid). If you are in Editor 2.0 you can also edit the CSS of headers and footers.
To add any code to any element or widget:
-
Right-click your widget or element to bring up the context menu. If you are in flex mode in Classic Editor or Editor 2.0, click to select the flex container, header, or footer.
-
Click Edit HTML/CSS. If you are in flex mode in Classic Editor or Editor 2.0, click the three dot icon in the floating menu, then select Edit CSS.
-
Edit or add code here, as needed.
-
Click Update.
The browser may need to be refreshed to see the change.
The current style update mechanism does not support CSS at rules. If you want to use CSS at rules in Flex Mode or Editor 2.0, you need to add them via developer mode, which can be accessed by clicking the developer mode icon in the top navigation bar.
The following at rules are only supported in developer mode:
-
@import: Used to import external stylesheets.
-
@media: Defines style rules for different media types/devices.
-
@font-face: Allows custom fonts to be loaded and used.
-
@supports: Applies styles based on feature support.
-
@keyframes: Defines animations.
-
@page: Used in paged media, such as printing.
-
@namespace: Declares a namespace for XML documents.
-
@charset: Specifies the character encoding.
-
@counter-style: Defines custom counter styles.
-
@document: (Obsolete) Applied styles to specific URLs.
-
@layer: Used in CSS Cascade Layers.
-
@property: Defines custom properties with specific types and initial values.
Following are recommended guidelines to follow when working with custom code and Developer Mode.
General Guidelines
-
Always create a backup of your site before adding custom code.
-
When working with custom code, always use your editor from this link: http://my.duda.co?nossl
-
You can preview code outside of an iframe by changing the editor link from https://my.duda.co/home/ed/site/xxxxx/page to https://my.duda.co/site/xxxxx/page?preview=true
-
Before placing code in the header, test on a separate test site first. You can do this by making a duplicate of your site to test custom code on.
-
For code that needs to be placed on a page, create a test page and place the code there.
-
Preview uses HTTPS, while your live site may not. This will often break custom code.
-
Make sure you stay within the columns. Our responsive sites are based on a row-column structure. This means that each row contains columns which ultimately hold the content. When adding or editing your own HTML, make sure it is inside a column.
Developer Mode specific guidelines
-
Make sure you stay within the columns. Our responsive sites are based on a row-column structure. This means that each row contains columns which ultimately hold the content. When adding or editing your own HTML, make sure it is inside a column.
-
Leave the classes in place. The editor relies on the many classes that are added to elements. If you see an existing class (usually starts with dm), leave it in place. If you remove classes, the Site might not look the same when you go to preview it.
-
Notice the class sizes. Columns have a size value that is added as a class, such as large-6 or small-12. This determines the size of columns inside that row. You'll want to leave these in place, as they are the core of sizing the row on different devices.
-
Avoid editing extensions if possible. In the HTML, you will see placeholders of elements on the page already. If you can, avoid editing these, especially the data-values held within them. Editing these can break the widgets once you head back to the editor.
If you have added custom code to your site that's impacting its performance or preventing you from editing it, it is most likely due to the code not being formatted correctly or not being HTTPS compliant.
Caution
Duda Support cannot troubleshoot custom code.
-
Custom code is very unpredictable. There are many factors as to why your custom code may not be working with our platform. If you need help getting the custom code working on your site, it might be worth hiring a Duda Expert to help you get your code working on your site.
-
Consent management apps are not able to prevent code from running prior to consent when the code is placed in the header HTML. This is because Duda optimizes the structure and order of how content loads, based on performance best practices on the site. We place scripts and CMP banners lower on the page, in order to improve the performance of primary content. Because of this, it is recommended to place code in the body-end when using a consent management app.
Following are troubleshooting solutions for issues you may encounter while working with custom code.
Restore a backup of your site to a point before the custom code was added (even if you haven't created a backup, the editor creates one for you when you publish or enter developer mode).
To restore a backup:
Following are specific error messages and what they mean:
-
DUPLICATE_ID. Every element must have a unique ID. -
INVALID_ELEMENT_LOCATION. All elements must be in a column which must be in a row. -
BAD_PROPORTION. Columns in a row must add up to 12. -
INVALID_CLASS_FOR_ELEMENT. A class has been added to an invalid element.
If you have code that's not working on the site, it's most likely due to the code not being formatted correctly or not being HTTPS.
If you have any links in your code (http:// or //) and your site is using HTTPS or you're in the preview, then you will have to change that so that it's https:// instead. The reason for this is because the non-HTTPS code will not work in an HTTPS loaded connection (site preview, editor, etc).
If you are unable to access the editor when your site loads initially, try accessing your editor on a new page by entering a different URL in your editor link, such as https://my.Duda.co/home/site/XXXXXXX/about. When you get there, you can delete and re-add the page that is causing problems, or access developer mode to fix the issue on the site's code.
Or, if the editor is broken, try to force open the editor by using the keyboard shortcut for the element inspector. For Mac the shortcut is Command+Option+C. For PC the shortcut is Ctrl+Alt+C
Page speed optimization affects how certain scripts are run. We run PageSpeed optimization on most pages, which can cause issues with your custom code.
To determine if your custom code is being affected by a page speed issue:
-
Duplicate the page with your scripts.
-
Change the URL to "testing_scripts."
-
Publish and then check the page on your live site.
-
If your code works on that page, contact support to turn off page speed optimization for your site.
If you are using a script, you can also try making sure your script runs asynchronously—it is not guaranteed, but it sometimes can solve the issue with scripts not executing properly in the browser.
To enable async on scripts, alter your code using the following:
-
Old code:
<script src="https://example.com/script.js"></script> -
New code:
<script src="https://example.com/script.js" async defer></script>