Change URL field behaviour in 3.0?

393 views
Skip to first unread message

Ingo Schommer

unread,
Mar 9, 2012, 10:37:15 AM3/9/12
to silverst...@googlegroups.com, fel...@silverstripe.com
Currently, changing the title in an "Edit page" view brings up this annoying JS alert asking for confirmation to change the URL as well. That's much too intrusive.

I suggest that we do the following:
 * Move the URL below the "Page name" field, so changes to it are directly visible where they are caused
 * Make the field readonly by default (or replace with standard text styling)
 * Add small "edit" button to the right of the URL which reveals the input field
 * Once the input field shows, also show a button labelled "update from title"
 * This new "URL edit view" could also show further help text by default, for example noting that old URLs will still be found and redirected (an important and little known fact to authors)
 * Note: The field already updates/rewrites the value dynamically via ajax, to apply transliteration and other rules defined through URLSegmentFilter (which now actually supports UTF8 URLs if configured this way)

Do you guys think this is a good idea?
I can't promise to actually have it happen in 3.0 (definetly not in beta),
but it seems like a good point in time to change an important piece of the UI for the better, right?
Maybe somebody wants to have a crack at it?

Also posted to http://open.silverstripe.org/ticket/6981

Aram Balakjian

unread,
Mar 9, 2012, 12:29:43 PM3/9/12
to silverst...@googlegroups.com, fel...@silverstripe.com
I think that sounds like a great idea.

Aram


--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/IN0MPc73W0IJ.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

Fred Condo

unread,
Mar 9, 2012, 1:27:46 PM3/9/12
to silverst...@googlegroups.com, fel...@silverstripe.com
Yes, this is an excellent suggestion.

Sam Minnée

unread,
Mar 9, 2012, 2:24:03 PM3/9/12
to silverst...@googlegroups.com, silverst...@googlegroups.com, fel...@silverstripe.com
The update from page title button sounds good but I'm trying to understand why the field should be read-only by default.

Also, the update from page title button would be useful whenever the page title differs from the URL, not just when the page title is actually changed. Eg, you might want to reset the URL after editing it manually.
--

Ingo Schommer

unread,
Mar 9, 2012, 2:57:13 PM3/9/12
to silverst...@googlegroups.com, fel...@silverstripe.com
Readonly mainly to de-emphasise it (less contrast due to not having a white background, and no frame).
It'll also fit nicer visually if laid out next to the (always readonly) base URL.
Its not something I feel too strongly about, the important bit is getting rid of that JS alert.

Good idea to show the "update from title" button conditionally.
We can check on the server if the URL segment regenerated from the current title
matches the stored on pretty easily.
I imagine a button styling similar to this from harmonyapp.com:

The other way to get rid of the alert would be opt-out rather than opt-in,
so change automatically, and show an undo button.
But I guess its more common to keep the URL than to update it to the new title, right?

Sigurd Magnusson

unread,
Mar 9, 2012, 4:19:30 PM3/9/12
to silverst...@googlegroups.com
Good idea, one extra thing: it still needs to be automatically set first time.

When the page is new how about the readonly URL updates visibly as each character is typed into page name? Then your behaviour kicks in after the page has first been saved?

All up this will be an appreciated improvement in SS3

Sig


--


On 10/03/2012, at 4:37 AM, Ingo Schommer <ingo.s...@gmail.com> wrote:

--

Ingo Schommer

unread,
Mar 9, 2012, 4:22:27 PM3/9/12
to silverst...@googlegroups.com
It needs to do an ajax request with about 100-300ms delay,
because the URL generation logic got more complex than a simple RegEx in JS.
Update-as-you-type is possible, but won't be instantaneous.
Good idea though, its like built-in training for the authors to make good URLs ;)

> > To post to this group, send email to silverst...@googlegroups.com (mailto:silverst...@googlegroups.com).
> > To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com (mailto:silverstripe-d...@googlegroups.com).


> > For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
>

> --
> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

> To post to this group, send email to silverst...@googlegroups.com (mailto:silverst...@googlegroups.com).
> To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com (mailto:silverstripe-d...@googlegroups.com).

Sam Minnée

unread,
Mar 9, 2012, 4:24:12 PM3/9/12
to silverst...@googlegroups.com, silverst...@googlegroups.com
I think if we were to do update as you type Ajax wouldn't be appropriate - you'd need the logic in JS for that.

> To post to this group, send email to silverst...@googlegroups.com.
> To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.

Siddharth Menon

unread,
Mar 10, 2012, 10:50:04 AM3/10/12
to silverst...@googlegroups.com, fel...@silverstripe.com
I feed good about this.

Also would like to point out is that when we play around with URL it also effect Facebook comments, Twitter etc.
May be once a page is published we could discourage the change of URL automatically when title is edited.

Just a thought.

Cheers
Siddharth Menon

Nicolaas Thiemen Francken - Sunny Side Up

unread,
Mar 10, 2012, 3:57:54 PM3/10/12
to silverst...@googlegroups.com
On 11 March 2012 04:50, Siddharth Menon <siddhar...@gmail.com> wrote:
I feed good about this.

Also would like to point out is that when we play around with URL it also effect Facebook comments, Twitter etc.
May be once a page is published we could discourage the change of URL automatically when title is edited.



Hi Siddharth

I wold not worry too much about that because Silverstripe automatically redirects from a "previous" url to a "current" url. 

Ryan Wachtl

unread,
Mar 10, 2012, 4:03:55 PM3/10/12
to silverst...@googlegroups.com
Hi Nicolaas

While SilverStripe does handle the redirection from the old to new URL quite well, the Facebook 'Likes' that were associated with that page are usually lost after the page URL is changed. At least that is my experience with it.

- Ryan

Liam Whittle

unread,
Mar 10, 2012, 4:13:09 PM3/10/12
to silverst...@googlegroups.com
Ya +1 for not having it automatically updated when you change the page title.

In addition to the FB likes, if you're using InSection() in your templates, it can mess things up when a client doesn't realize what they're doing.

Sam Minnée

unread,
Mar 10, 2012, 4:54:32 PM3/10/12
to silverst...@googlegroups.com, silverst...@googlegroups.com
Yeah, the redirection is nice, but I go with Berners-Lee on this: cool URLs don't change.

Potentially we could have it automatically update with an "undo" button on pages that have never been published?

Ryan Wachtl

unread,
Mar 10, 2012, 5:59:37 PM3/10/12
to SilverStripe Core Development
I agree that the default state for the URLSegment should be readonly
and that users should have to make an active effort to change the URL
for a page. I can see it working like this...

1. Create a new page.

2. After a page Title is entered go ahead and auto-populate the
URLSegment for the user; no prompt and URLSegment field remains
readonly.

3. Now that the URLSegment is populated there is an 'Edit' button next
to the field.

4. Clicking on 'Edit' will remove the readonly attribute and allow a
user to change the URLSegment. To complete the action a user can click
'Update' or 'Cancel'.

5. After confirming the 'Update' the URLSegment is validated and the
field is returned to a readonly state.

6. Further changes to the page Title would not prompt to change or try
to change the URLSegment.

I have a simple little prototype of the actions above here:
http://invis.io/2E25FRXZ

I believe that would be a good start to handling the URL. After that
is all sorted and working we could look at adding in the 'Update from
Title' action.

- Ryan

On Mar 10, 3:54 pm, Sam Minnée <s...@silverstripe.com> wrote:
> Yeah, the redirection is nice, but I go with Berners-Lee on this: cool URLs don't change.
>
> Potentially we could have it automatically update with an "undo" button on pages that have never been published?
>
> On 11/03/2012, at 10:13 AM, Liam Whittle <lee...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Ya +1 for not having it automatically updated when you change the page title.
>
> > In addition to the FB likes, if you're using InSection() in your templates, it can mess things up when a client doesn't realize what they're doing.
> > On Saturday, 10 March, 2012 at 4:03 PM, Ryan Wachtl wrote:
>
> >> Hi Nicolaas
>
> >> While SilverStripe does handle the redirection from the old to new URL quite well, the Facebook 'Likes' that were associated with that page are usually lost after the page URL is changed. At least that is my experience with it.
>
> >> - Ryan
>
> >>> On 11 March 2012 04:50, Siddharth Menon <siddharthme...@gmail.com> wrote:
> >>>> I feed good about this.
>
> >>>> Also would like to point out is that when we play around with URL it also effect Facebook comments, Twitter etc.
> >>>> May be once a page is published we could discourage the change of URL automatically when title is edited.
>
> >>> Hi Siddharth
>
> >>> I wold not worry too much about that because Silverstripe automatically redirects from a "previous" url to a "current" url.
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
> >>> To post to this group, send email to silverst...@googlegroups.com.
> >>> To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
> >>> For more options, visit this group athttp://groups.google.com/group/silverstripe-dev?hl=en.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
> >> To post to this group, send email to silverst...@googlegroups.com.
> >> To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
> >> For more options, visit this group athttp://groups.google.com/group/silverstripe-dev?hl=en.

Ingo Schommer

unread,
Mar 15, 2012, 11:39:23 AM3/15/12
to silverst...@googlegroups.com
Hey Ryan,

Thanks for the prototype, says more than a 1000 mailinglist posts! ;)

The issue with an explicit "update"+"cancel" button combination is that
the interface implies saving the edit permanently, which is not the case:
You still have to press the "Save" button to save the whole page record.
We could save the URLSegment individually via Ajax of course.
Adds a bit of technical complexity, but seems to be the more expected behaviour.
What do you think is the more expected behaviour?

Also, you might want to update the notification text to include something about the URL character limitations.
I guess authors would be confused by the conversion magic, e.g. keep typing a space,
just for it to magically change into a dash.
Suggestion: "Some special characters are converted automatically to make the URL valid and friendly".
A bit generic, but you can configure those rules (e.g. allow Umlauts without transliteration, underscores, etc),
so this text covers them all.

Ingo 

Ryan Wachtl

unread,
Mar 15, 2012, 12:52:20 PM3/15/12
to silverst...@googlegroups.com
Ingo,


The issue with an explicit "update"+"cancel" button combination is that
the interface implies saving the edit permanently, which is not the case:
You still have to press the "Save" button to save the whole page record.
We could save the URLSegment individually via Ajax of course.
Adds a bit of technical complexity, but seems to be the more expected behaviour.

I agree. If there are action oriented buttons like "update" the expected behavior is that those changes would take effect without having to "save" or "save and publish" the entire page. That's one of the details I'm working through yet.

Sigurd Magnusson

unread,
Mar 15, 2012, 5:25:59 PM3/15/12
to silverst...@googlegroups.com

Hey Ryan,
Thanks for the prototype, says more than a 1000 mailinglist posts! ;)

Agreed :)
 

The issue with an explicit "update"+"cancel" button combination is that
the interface implies saving the edit permanently, which is not the case:
You still have to press the "Save" button to save the whole page record.

Solution: After changing the URL, the yellow help text becomes "The new URL will be applied when you save and publish this page."

Ryan Wachtl

unread,
Mar 15, 2012, 9:47:22 PM3/15/12
to silverst...@googlegroups.com
Hi Sig,

That sounds like a good solution to get started. Here is an updated prototype with that behavior.


I've had a look at how Expression Engine and WordPress handle this. It appears EE always updates the URL when the page is renamed, with no warning. WordPress creates the URL for you after you enter the page name and then presents an Edit button to change the URL manually, no option to update from page name after that. The approach I take in this prototype is to make the new page creation process quick, by auto-populating the MenuTitle, MetaTitle, and URLSegment as the user is typing in the Page name (Title). This "Live Updating from Title" behavior will remain in effect until the page is published for the first time. After the page is published the Page name (Title), MenuTitle, MetaTitle, and URLSegment would remain independent (unaware of each others changes) and the URLSegment field would have a button with option to EDIT. After which a user can UPDATE to commit their changes to the field (with a note about having to save the page to apply), CANCEL, or UPDATE FROM TITLE.

- Ryan

Ingo Schommer

unread,
Apr 10, 2012, 4:44:02 AM4/10/12
to silverst...@googlegroups.com
Hey Ryan, how's the URL field changes coming along?
Our window of opportunity for including this in 3.0 is rapidly closing.

Thanks!
Ingo

Ryan Wachtl

unread,
Apr 10, 2012, 8:50:13 AM4/10/12
to silverst...@googlegroups.com
Hi Ingo,

I'm still on it. If I can get something I'm comfortable with completed by the 17/18th will that fit within the release schedule?

I have a question about page creation. When a new page is created how important is it to pre-populate the `Title` and `MenuTitle` with "New Page"? Would it cause any issues if those fields were empty when a page was created and the cursor was placed in the `Title` field ready for a user to input the `Title`?

- Ryan

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/Kra8w3BBV6cJ.

Sigurd Magnusson

unread,
Apr 10, 2012, 2:51:04 PM4/10/12
to silverst...@googlegroups.com
Thanks Ryan, as that's only one week away I suspect Ingo will be fine with that... over to him on that.

In my opinion blank field states are fine, perhaps when the user leaves the first field, if it had been left blank it can be "New  Page" then...

Cheers
Sigurd

Ingo Schommer

unread,
May 2, 2012, 7:37:44 PM5/2/12
to silverst...@googlegroups.com
 Hey Ryan, the 18th has passed a bit already :)  Are you still on this? We'd need it pretty much in the next week, or it'll miss the 3.0 release.

Ryan Wachtl

unread,
May 2, 2012, 9:38:59 PM5/2/12
to silverst...@googlegroups.com
Hi Ingo,

Sorry I've been a bit quiet on this. Spent more time fumbling around with git than coding, but I'm close to having things under control.

Two questions you can perhaps answer… (where I'm stuck right now).

1. Is there a class applied anywhere or any other attribute I can look for (within my JS)  to identify if a page was just created (a new page) but not yet saved?

2. Where (what file/class) is the "New Page" text (populates the Title field when a new page is created) originating from?

Thanks,

- Ryan

On May 2, 2012, at 6:37 PM, Ingo Schommer wrote:

 Hey Ryan, the 18th has passed a bit already :)  Are you still on this? We'd need it pretty much in the next week, or it'll miss the 3.0 release.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/tMjNpMNlh_sJ.

Ingo Schommer

unread,
May 3, 2012, 8:01:28 AM5/3/12
to silverst...@googlegroups.com
Hey Ryan,

Thanks for keeping at it, we're getting there :)

On 3/05/2012, at 3:38 AM, Ryan Wachtl wrote:
>
> 1. Is there a class applied anywhere or any other attribute I can look for (within my JS) to identify if a page was just created (a new page) but not yet saved?
$('.cms-edit-form :input[name=ID]').val()
>
> 2. Where (what file/class) is the "New Page" text (populates the Title field when a new page is created) originating from?
CMSMain->getNewItem()

Thanks
Ingo

Ryan Wachtl

unread,
May 9, 2012, 8:40:28 PM5/9/12
to silverst...@googlegroups.com
Thanks Ingo,

The page already has an ID when it is created, but I think I found a reliable way of of checking for a new page using a combination of:

.cms-edit-form input[name=URLSegment] and .cms-edit-form input[name=LiveURLSegment]

I issued a pull request for what I've done so far (the basic Opt-in changes to the URLSegment). Looking forward to feedback as this is the first time I'm working with entwine.

- Ryan
> --
> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

Ingo Schommer

unread,
May 10, 2012, 8:58:22 AM5/10/12
to silverst...@googlegroups.com
Pull request merged, with some improvements:
Thanks Ryan!
Reply all
Reply to author
Forward
0 new messages