CEP Sveltia Migration Tracking

Stripes · October 16, 2025, 11:03am

I wanted to create a thread to track my contributions to the wiki, since I work less with page content and more with behind the scenes. As we wait for SveltiaCMS to offer open authoring so it can be a viable replacement for DecapCMS, I’m working on an overhaul of the Hugo templates so that build times are faster and that we have a theming system in place so that users can choose the layout that works best for them.

My original test for a redesign can be found here: https://www.plushypuppy.club/sandbox/cheese/ but I’m thinking of going back to the drawing board and simplifying it, rather than cluttering it. I’ll keep sharing updates here and I’m open to any feedback to incorporate what people want to see.

The move to SveltiaCMS will also help us adjust the page creation “wizard” so that we can capture data for pages more intuitively. I’ll outline some of my findings in my next post!

Stripes · October 29, 2025, 1:55am

Below I will be sharing some of my setup steps as I work to test changes on the “v2.0” CEP.

Hugo Site Setup

First, I created a blank repository and used the hugo new site command to create a barebones structure. I’m using the latest version of Hugo, and I’m following the latest version’s directory structure as to avoid any deprecated features.

Here is what my directory structure is, and notes about the directory structure and its contents:

/content/_index.md
/content/wiki/_index.md
/layouts/baseof.html
/layouts/list.html
/layouts/single.html
/layouts/_partials/display-citations.html
/layouts/_partials/generate-site-csv.html
/layouts/_partials/generate-site-json.html
/layouts/_shortcodes/cite.html
/layouts/_shortcodes/wiki-link.html
/static/style.css
/static/photos/
/static/sveltia/index.html
/static/sveltia/config.yml

The content folder is solely meant to store articles – I have simplified this down to just wiki articles for now and will expand each section as I make it compliant with the new site development standard.

The layouts folder is meant to hold all template information – based on my research, a separate theme directory is not required, neither is a separate default folder, and I have only created the bare minimum to get a site going – baseof.html is the core page template including HTML declarations, headings, stylesheets, etc. and is used to call the generate CSV/JSON partials (simply embedded HTML), while list.html dictates the page format for lists (the _index.md pages) and single.html dictates the page format for individual articles.

In the layouts/partials folder, I created HTML templates to output citations on pages and generate CSV and JSON for the entire site. In the layouts/shortcodes folder, I created shortcodes to make page editing easier based on currently existing codes on the site (in fact, I used this testing site to roll out those changes on the main site, so that is why they are there).

My goal is to reduce the number of templates needed to achieve the same result so that our build time goes down (it is currently around 7-8 minutes), so changes reach the main website more quickly.

Lastly, the static folders contain a spot for photos to go to (from SveltiaCMS), and then the SveltiaCMS access folder which includes a single HTML page and a configuration file. More on that in the next post.

As of writing this, I wonder if the generate CSV/JSON partials should be moved, else they’ll run on every page.

DigitalOcean Setup

DigitalOcean provides free hosting for static sites hosted in GitHub repositories. To begin, I created a free team on DigitalOcean (I linked my GitHub account with it for signing in), and then within the team implemented a free app through the “App Platform” it provides.

When I created the app, it asked me for a deployment source. In this case, I selected the GitHub repository where the Hugo site was being stored. To match CEP’s configuration, I selected the main branch and ensured that auto deploy was enabled.

Before creating the app, I was shown what looks like a checkout screen. There I saw all of the settings – DigitalOcean recognized that it was a Hugo build and set up the defaults accordingly. I did not change any defaults so that it is using the latest version.

The app was ready, and I was immediately given a URL. I could’ve stopped there but I had custom domain, so I went through the trouble of setting that up by going to the settings and adding another domain.

SveltiaCMS/Cloudflare Setup

This section is less about the setup in Hugo, more about setting it up so I can connect it to GitHub with authentication so I can use SveltiaCMS in the browser just like we would use DecapCMS on the current CEP site.

I had to go to this repository: https://github.com/sveltia/sveltia-cms-auth and follow the steps it provides. I had to create a Cloudflare account. Having the personal domain helped with setting up the OAuth app in GitHub.

Once that was setup I was good to continue, which brings us to sometime in August.

In my next post, I’m going to outline some of the preliminary changes I’ve already made with SveltiaCMS as our primary editor and what I’ve found useful to make the site easier to work with in the future.

Stripes · November 17, 2025, 2:20am

Sorry it has been a while, but it works out as this post comes off the heels of the news that CEP has moved towards automated table creation/tagging of stages, remodels, and more.

We’ve been tinkering with this for a while, but only now has 64th done the work needed to actually generate the content for the page rather than just the infobox.

Let’s take a look at how we’ve configured DecapCMS to add citations:

The configuration is as follows:

Meaning we can create a list of text fields, that ultimately create the citations we see on the page code:

Now, one of the issues I have with the parameterization of remodels/stages/etc. is that everything is just a long string split by a pipe (“|”) – it’s hard to edit and hard to read.

Decap (and Sveltia) offers what is called an object: Widgets | Decap CMS | Open-Source Content Management System

An object is essentially a list of bundled things. So let’s say for each showtape, we need credits – who the actor is, and the role they played:

Name = string
Role = string

By using objects in our configuration instead of a single string field (“Name|Role”), I can create multiple objects with their own name and role field, which presents better in the editor.

Here’s an example with the stage parameter we currently use on location pages:

And with configuration changes (including date field validation):

Going with this would be easier on the editor, but would also require slight configurations to templates to navigate through data. However, this provides us with a more programmatic approach overall and less concern about string formats.

I need to do some more testing, and I also have a Google Sheet that lists all of the different metadata elements on the wiki (as of September 2025, at least) which is going to help me set up our Sveltia configuration (which, BTW, can also be used on Decap) to prepare us for next year’s release.

Stripes · November 17, 2025, 2:23am

Oh and here’s that link CEP Locations Chart - Google Sheets