New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make sluggification visible, customizable, and fail-safe #445

Open
erquhart opened this Issue Jun 6, 2017 · 24 comments

Comments

@erquhart
Member

erquhart commented Jun 6, 2017

Default sluggification is simplistic, relying on a title field and performing no inference whatsoever.

With no field named "title", entries currently fail to save.

The ideal fix is to simply make slugs editable in the editor UI.

Considerations:

  • Slug editing can be switched off through config
  • If slug editing is switched off, each collection config must be validated on CMS load to ensure a slug can be derived
  • Prepopulate with the same best guess or configured slug template result that we currently use
  • Only valid characters may be entered in the slug field
  • Slugs and filenames are not always the same, so it should be possible to provide them separately somehow (see comment below for example)
@Benaiah

This comment has been minimized.

Contributor

Benaiah commented Jun 6, 2017

@erquhart how does the slug entry in collections affect sluggification - is it functional anymore? (I've been working under the assumption that the current behavior is that the title field is sluggified and turned into the {{slug}} part of the slug template).

@erquhart

This comment has been minimized.

Member

erquhart commented Jun 6, 2017

Yep, that's the default behavior, but date segments can be used for some light slug templating:

const slugFormatter = (template = "{{slug}}", entryData) => {
const date = new Date();
const identifier = entryData.get("title", entryData.get("path"));
return template.replace(/\{\{([^\}]+)\}\}/g, (_, field) => {
switch (field) {
case "year":
return date.getFullYear();
case "month":
return (`0${ date.getMonth() + 1 }`).slice(-2);
case "day":
return (`0${ date.getDate() }`).slice(-2);
case "slug":
return slug(identifier.trim(), {lower: true});
default:
return slug(entryData.get(field, "").trim(), {lower: true});
}
});
};

@erquhart erquhart referenced this issue Jun 28, 2017

Closed

Feature Request: Edit entry slugs #377

0 of 2 tasks complete

@erquhart erquhart added this to the 1.0 milestone Jun 28, 2017

@erquhart

This comment has been minimized.

Member

erquhart commented Jun 28, 2017

May happen in tandem with #180.

@tech4him1

This comment has been minimized.

Collaborator

tech4him1 commented Sep 19, 2017

We currently overwrite any existing entry when a new entry is created that has the same slug. This is probably best fixed along with this issue.

@tech4him1

This comment has been minimized.

Collaborator

tech4him1 commented Sep 20, 2017

I also think we should throw an error if the slug is going to be blank.

@aperep

This comment has been minimized.

aperep commented Sep 20, 2017

It is a bad idea to silently overwrite entries. If a user creates multiple entries on same day and does not bother about titles, then all entries except last will be lost without any notification. This is easily the worst imaginable behaviour.

@erquhart erquhart removed the priority/P2 label Dec 8, 2017

@nytyp

This comment has been minimized.

nytyp commented Dec 17, 2017

I wonder if we should change or prioritize how we visualize the 'title' field to imply it's importance

@erquhart erquhart removed the help wanted label Dec 19, 2017

@erquhart

This comment has been minimized.

Member

erquhart commented Dec 22, 2017

We're actually looking to eliminate it's importance. Right now it's critical because it's used for automated slug creation, which the user can't see or influence. This issue calls for making slug creation interactive. We could pre-fill with whatever's in a title field, but if there's no field (or the slug is blank for any other reason), the entry would fail validation and could not be saved.

@bjrn

This comment has been minimized.

Contributor

bjrn commented Feb 16, 2018

Hi! What's the status on slug editing, anyone working on a suggestion?

@robsonsobral

This comment has been minimized.

robsonsobral commented Mar 30, 2018

May I point something? Some SSGs allow us to overwrite the filename based slug. This is speacially useful for Hugo multilingual files. We can have a travel.en.md file with slug: "travel" on front matter and a travel.pt.md file with slug: "viagem".

Can we avoid conflicts between the two things?

@erquhart

This comment has been minimized.

Member

erquhart commented Apr 2, 2018

@robsonsobral I'm not sure what you're saying Netlify CMS should do differently to accommodate for this. Can you explain further?

Update:
Your comment on #1063 made it click for me, you're saying filenames and slugs shouldn't be assumed to map 1:1. This is a great point, I'll add it to the OP.

Would you have time to write up some thoughts on what setting both custom slugs and filenames could look like from your perspective?

@erquhart

This comment has been minimized.

Member

erquhart commented Apr 3, 2018

Actually, @robsonsobral, that already works. If you need a "slug" frontmatter property for Hugo, just add it to your config and the CMS won't pick it up or use it at all. Slugs, for our purposes, are related to the source file name only, and your SSG is concerned with the slug for the built file name.

@robsonsobral

This comment has been minimized.

robsonsobral commented Apr 4, 2018

Thank you for your attention, @erquhart . Please, forgive my late answer.

What will happen if there's a slug field on front matter, after you allow the edition of slug? How to deal with two fields with the same name?

@erquhart

This comment has been minimized.

Member

erquhart commented Apr 4, 2018

The editable slug will be an internal value, we won't output it to frontmatter. It should be made available for reuse at some point, though, as requested in #450 and #1063.

@tech4him1

This comment has been minimized.

Collaborator

tech4him1 commented Apr 4, 2018

As I see it, you can use it in frontmatter if you want, but you could also set your own string.
I'm not saying this is exactly how it will work, but a possible config format would be:

# No output to frontmatter.
- {label: "Slug", widget: "slug"}

# Save generated slug in frontmatter.
- {label: "Slug", widget: "slug", name: "slug"}

# Manual slug in frontmatter.
- {label: "Slug", widget: "string", name: "slug"}
@robsonsobral

This comment has been minimized.

robsonsobral commented Apr 12, 2018

Can we customize the field label? If we have a slug field on frontmatter, we could and with confusing labels.

@erquhart

This comment has been minimized.

Member

erquhart commented Apr 12, 2018

I'm not expecting there to be a typical field configuration for the slug editor, but I may be underthinking things. Either way, I'd expect output of the slug and other internal/meta values to be made available to fields as placeholder values via #450. So you could do:

- {name: slug, widget: hidden, default: "{{slug}}"}
@erquhart

This comment has been minimized.

Member

erquhart commented Apr 18, 2018

@tech4him1 I wouldn't expect a slug widget - here's your example as I'd expect it:

# No output to frontmatter.
# (automatic)

# Save generated slug in frontmatter.
- {label: "Slug", name: "slug", default: "{{slug}}"}

# Manual slug in frontmatter.
# (same as above since the slug is editable as a meta field)

I can't think of a use case for allowing the slug to be configured as a field. You?

@tech4him1 tech4him1 added this to Ready For Development in 2.0 Release Jul 24, 2018

@tech4him1 tech4him1 moved this from Ready For Development to Requested in 2.0 Release Jul 24, 2018

@mistermantas

This comment has been minimized.

Contributor

mistermantas commented Aug 8, 2018

This should be tagged high priority or something.

I’ve just had to redo my entire frontmatter because of this single issue. Posts couldn’t be created and it wasn’t even obvious why.

I don’t think there needs to be a super special UI for the slug — perhaps the default behavior, as it is now for title, would be showing the slug in small lettering underneath that with an edit button? I think something like that is done with WordPress. Otherwise just expose it like any other field.

@tech4him1 tech4him1 added this to Triage in Priority Issues Aug 8, 2018

@tech4him1

This comment has been minimized.

Collaborator

tech4him1 commented Aug 11, 2018

Starting in v2.0 there is an error message for this -- at least an improvement on the silent breakage we had before.

@mistermantas

This comment has been minimized.

Contributor

mistermantas commented Aug 12, 2018

That’s… not really the case in my experience. If there was no field like title (even if there was Title) it would try to publish and throw an error in console and that’s it.

Maybe that should be taken into account too.

@tech4him1

This comment has been minimized.

Collaborator

tech4him1 commented Aug 12, 2018

@mistermantas That should already be throwing an error. Would you mind opening a new issue with an example config so that I can get that to at least throw an error?

@therealshark

This comment has been minimized.

therealshark commented Aug 22, 2018

It would also be nice if there was another placeholder like {{random}} generating a random string to use in the slug. I'd like to create a collections with items having no unique field, and just using a slug like slug: "{{year}}-{{month}}-{{day}}-{{hour}}_{{minute}}_{{second}}" feels a bit risky.

Another possibility to minimize the chance of colliding would be to add milliseconds as another field.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment