Sorry, we don't support your browser.  Install a modern browser
This post is closed.

Merge "Change Title" and "Change Slug"#26

It happens very often that when customers operate the CMS themselves, they change the title but forget to change the URL.

So URLs often come out

example.com/test
example.com/did-this-work
example.com/i-add-the-title-later

Possibly an (optional) dialog would be conceivable that appears when changing the title whether the URL should also be changed. A small dialog would be conceivable “should the URL also be changed?”. Below that the new URL and 2 buttons with yes or no. Or maybe merge simply the two dialogs as in 90% of all cases, the slug will also change when the title changes.

This could possibly be a new option for the config

This would also harmonize with the idea of ​​neildaniels
Github 362

4 years ago

This indeed is a constant headache with editors.

Yet, it also needs to be considered that changing the slug of an already published page may break a lot of things. Wordpress automatically establishes a redirect for old slugs to new slugs, but since Kirby does not, this requires quite some awareness and care by editors (I remember a discussion about this in the context of the Retour plugin a few months ago, in which we determined the intricate complexity of this, but cannot find it any more; might have been on Slack and vanished).

4 years ago

@sebastiangreger I think any discussion about redirects is separate from this idea - the issue you describe applies to the current situation just the same (btw the Retour discussion is here: https://github.com/distantnative/retour-for-kirby/issues/169)

Personally, I find the idea to merge both dialogs without any automisation most convincing. Automatisation or nudging could lead to increased undesired slug changes indeed. But letting the use see right there that the slug would still be the same when he changes the title (with the option to manually changing the slug as well or re-generate it form the new title) is the right degree of agency IMHO.

4 years ago

@Nico Yes, sorry: on re-reading it, I realize that my comment was rather ambiguous without further explanation of why I added it here …I’ll blame it on my Sunday brain :D

First of all, I very much concur: the redirect discussion as such does not belong here, neither was that my intention.

I wished to highlight that, while this is indeed most welcome for reducing cases like example.com/i-add-the-title-later, it may also increase cases of “I changed the URL of this article our marketing team shared on all the social media channels two hours ago” without editors’ awareness that they may break things. As you point out, the situation would technically be no different from the current state. But by making the slug setting significantly more prominent in the context of another user task, such UI change may amplify this underlying challenge - a potentially unintended consequence.

letting the use see right there that the slug would still be the same when he changes the title (with the option to manually changing the slug as well or re-generate it form the new title) is the right degree of agency IMHO.

It is. But what the user does not see (neither currently nor with this UI improvement as such; I’ve solved this with customizing the Panel in the past) is that keeping it the same may in many sitations be favourable (yet, should remain possible, i.e. setting changeSlug to false is not practical). So my point - that indeed was not clear enough in above posting - is to motivate a discussion whether this “risk of breaking things” should/can be addressed on the UI level as this feature is being worked on? That’s why I considered the redirect issue on-topic here.

For example: Could there be a note that appears in the context of the slug field of published pages; this could be optional, with a customizable string, to be configured in a page blueprint?

4 years ago
Changed the status to
In upcoming releases
3 years ago
1
Changed the status to
Completed
3 years ago