FR: Member Groups: Handle format validity

[robzor]

Description

Hi there, I would like to be able to create a site using Member Groups and their handles.

e.g. https://example.com/{example-member-group-handle}/example/{slug}

Unfortunately, Member Group handles currently disallow hyphens, could this possibly be tweaked?

Additional info

• Craft version: Craft 3.0.0 RC4

[brandonkelly]

Handles currently don’t allow hyphens because there are cases where they are referenced as an object property (e.g. entry.fieldHandle, asset.transformHandle). And you can’t have a hyphen in a variable/property name.

There are cases where that doesn’t apply though, like user groups, where the handle is always referenced in a string. So there’s no technical reason we couldn’t allow hyphens in those cases.

The biggest argument against it that I can think of is, it overloads the word “handle” a bit, which currently has a pretty consistent definition and syntax. There is already one exception in Craft 3 – plugin handles are now kebab-cased instead of camelCased.

[robzor]

Perhaps there is scope for a new word to be added, to define a handle always referenced as a string? 'Shandle' or 'Handing' :P

I guess using 'Slug' here would be weird, as that seems to be defined always tied to the front-end?

[riasvdv]

Would it be possible to just always allow hyphens in handles with a caveat that you'd have to reference them as entry['field-name']? I doubt a lot of people will start using them that way but at least a handle would mean the same thing everywhere

[brandonkelly]

@Rias500 That’s not a bad idea, but there are a couple caveats. Currently all custom field handles get stored as public properties on the dynamically-generated ContentBehavior class, which is what element.fieldHandle resolves to, so we would need to run the handle through some sort of normalization process when reading/writing to that, which would have a performance impact. Also not sure what we’d do about custom fields’ element query params (e.g. craft.entries.myCustomField('value')). We could add a .field() method for setting custom field param values, which could be used instead if your field handle has a hyphen. But all of this seems a little silly considering there’s very little chance that custom fields would ever need to have a hyphen; so I think I’d rather just let the handle rules differ a bit depending on the context. As it is, there’s already a little bit of inconsistency, as the list of reserved words differs depending on the context.