Adding editable regions to static sites

General
1

Back in the day I remember the visual editor supported editable regions for static sites, so it was simple to allow client users to edit the site without worrying they’d break it by entering badly-formed HTML…. make sure the user has password access and then add the class to allow the text and images to be edited and have them call me for bigger changes.

Am I right in thinking that this is no longer possible? I don’t see an obvious way to do this for static sites with the new editing workflow. Perhaps I’m missing something?

1 Like
2

@kimslawson This is still possible!

The new Editable Regions function via static HTML and vanilla JavaScript events, so any site can use them. They give you a lot more flexibility over how you can connect them to your data, and you can still connect them directly to your static HTML using Source Editable Regions.

For example, if you wanted to be able to edit the copyright text in your footer on a Jekyll site, you might have something like this:

<!-- /_includes/footer.html -->
<p data-editable="source"
   data-path="/_includes/footer.html"
   data-key="copyright"
>
    © 2025 CloudCannon
</p>

Here’s an example of how you could allow visual editing of the Markdown blog posts on a Jekyll site:

<!-- /_layouts/blog.html -->
<editable-text data-props="@content">
  {{ content }}
</editable-text>
2 Likes
3

Maybe my question is more fundamental and I’m missing one or many prerequisites for visual editing. I’m unsure what to put in config for a static HTML site. I have simple needs right now (one-pager that the client can edit certain regions of).

I uploaded an existing plain HTML static site. Never had a cloudcannon config yml file. Only had default build settings. I have only the source editor because I haven’t defined anything to allow visual editing or collections.

Starting from this basis, I believe I have to

  • Populate the config file correctly (but what for plain html?)
  • Maybe turn on config mode for my site and see what I should change? (but the config switch isn’t available in my dashboard)
  • Maybe add something to my build settings to allow for source editable regions in the HTML?
  • Make a folder to contain files corresponding to collections/editable regions
  • Add various regions to the HTML to allow for source editing, making sure the values for key and data path are correct.
  • Profit! (be able to use the visual editor on the correct parts of the page)
  • Add access for visual editing for the client. Test as the client.

Thanks for any help. I feel like CC tools are very powerful, and I want to get better at them, but right now I have basic needs and just need to orient myself. For reference I started a long time ago with CC when the workflow was simpler, and I just don’t have the right mindset to accomplish the same goal with the new platform.

4

I’ll try to address all your questions at once, sorry if this is a bit of a ramble!

If you go to your Site Dashboard, you’ll see a guide which will walk you through the steps of creating a configuration file, and it will even intelligently suggest some good starter config. You can also see this guide described in our docs here: Create your CloudCannon Configuration File | CloudCannon Documentation

I think the biggest change you’re probably seeing is the release of our new configuration format, Unified Config.

  • With our legacy config format, we would have automatically scanned your site during the build process to determine some configuration for you, and merge this with any config you’ve explicitly defined.
  • In our newer Unified Config format (released in late 2024), all your configuration needs to be explicitly defined in your config file.
    This means your config isn’t tied to your build process, which means you can tweak your config and see the results immediately without even needing to save the file. It also gives you greater clarity about exactly how the Site is going to behave, since you’ve defined it all yourself.

Older Organizations have the option to switch between the two formats, for backwards compatibility. You might see a checkbox to turn on Unified Config while creating a Site, and you can toggle it in your Site Settings under “Flags”.

Configuration Mode is only available with Unified Config, which might be why you’re not seeing the switch on your Dashboard. You also need to have a configuration file already, even if it’s empty.

See here for a full description of the motivations behind Unified Config, why it’s preferable over our legacy config, and a complete step-by-step guide for migrating older sites: :cloudcannon: Unified Configuration Migration Guide

Nothing needs to be added to your build settings :relieved_face: as long as your site is building, and outputs static HTML with the correct data attributes, it can be visually edited.

CloudCannon config is the same for all SSGs, including static HTML :partying_face: the config only determines how your site is presented / edited within the CC UI.

So, what config do you need to edit static HTML?

  1. Your editors can only edit source files via Collections, so you’ll need to configure at least one collection. If you just wanted them to have access to visually edit all HTML files on your site, you might add something like this:
collections_config:
  pages:
    path: '/'
    glob: ['**/*.html'] 
    _enabled_editors: ['visual']
  1. In order for the Visual Editor to work, CloudCannon needs to know which source file maps to which output path on the live site. By default, it does some heuristic-based guess work to determine this which often works quite well. However, if you find some of your files aren’t loading in the Visual Editor, you can configure the url field on your collection to tell CloudCannon exactly where to find the output path for each source file. Check out this guide for a much more detailed breakdown about this: Confirm your output URLs | CloudCannon Documentation
collections_config:
  pages:
    path: '/'
    glob: ['**/*.html'] 
    url: /[slug]/
    _enabled_editors: ['visual']

That’s pretty much all the config you need to start editing. From there, you can add more configuration to more carefully scope out the ways that editors/team members interact with your site… or just let them at it!

Does that all make some sense? :sweat_smile: Let me know!

1 Like