Slug: '{{slug}}' in config.yml returns null value (used to work)

I’ve been asked to resurrect a Netlify CMS site that was created (and working) over 2 years ago using NetlifyCMS and Gatsby.

Creating pages and posts used to work fine, and the slug was auto-generated using slug: '{{slug}}' in the config.yml file.

But now when I attempt to create a new post the slug is not auto generated from the title like it used to be.

Now when I create a new post and save it, the resulting path is news/null instead of news/title-of-news-post (the collection is called news, rather than blog).

Again, this used to work automatically. When I look at my package-lock.json I seem to have two packages related to slug creation. github-slugger and unique-slug. Neither of those exist in my package.json however. And I can’t tell from the commit history if those are packages that I installed two years ago, or if they came pre-installed as part of NetlifyCMS (or Gatsby for that matter). I took a look at npmjs.com and it looks like unique-slug was published about 2 years ago, while github-slugger is only a year old (meaning it didn’t exist back when this site was built).

I can fix the problem by adding a slug field below the title like so:
fields:
- { label: 'Title', name: 'title', widget: 'string' }
- { label: Slug, name: slug, encoding: "ascii", required: true, widget: string, hint: 'remember-to-use-lowercase-and-dashes' }

But ascii encoding doesn’t seem to work. So a user could use spaces and mixed case and their slug path would look something like news/Top%20Stories where the spaces are replaced with %20. Again, in the past if the title was “Top Stories” the slug would have been converted to lower case and the spaces to dashes to become news/top-stories. To get around this I’ve added hint: 'remember-to-use-lowercase-and-dashes' but that seems really clunky and I know users will mess this step up.

I’d prefer to get back to the old way where the slug was generated automatically, but I just can’t figure out what caused it to stop working.

Any help would be greatly appreciated!

Hiya @tyleryoungblood and sorry we haven’t found you an answer for this one. Our Support team doesn’t usually provide in depth CMS help since we are frequent users but not maintainers and not familiar with all of the configuration options.

I think perhaps opening an issue on the CMS repo would be a good way to get an answer - as the maintainers do see and respond to those issues and may have some insight. Or if you want a lower-investment path, you could check out their slack, which you can find a link to from here:

They might be able to tell you “oh that was deprecated in version X” or “there is a new way to configure that” in a moment, but they don’t in general hang out in the community to see your post, and in this case our Support Engineers who make sure everything here gets an answer don’t have any other insights, so the most productive next steps for you would be to get in touch via one of those channels :slight_smile: