|Change URL field behaviour in 3.0?||Ingo Schommer||3/9/12 7:37 AM|
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
|Re: [silverstripe-dev] Change URL field behaviour in 3.0?||Aram Balakjian||3/9/12 9:29 AM|
I think that sounds like a great idea.
|Re: [silverstripe-dev] Change URL field behaviour in 3.0?||Fred Condo||3/9/12 10:27 AM|
Yes, this is an excellent suggestion.
|Re: [silverstripe-dev] Change URL field behaviour in 3.0?||Sam Minnée||3/9/12 11:24 AM|
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.
|Re: [silverstripe-dev] Change URL field behaviour in 3.0?||Ingo Schommer||3/9/12 11:57 AM|
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?
|Re: [silverstripe-dev] Change URL field behaviour in 3.0?||Sigurd Magnusson||3/9/12 1:19 PM|
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
|Re: [silverstripe-dev] Change URL field behaviour in 3.0?||Ingo Schommer||3/9/12 1:22 PM|
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 ;)
> Good idea, one extra thing: it still needs to be automatically set first time.
> On 10/03/2012, at 4:37 AM, Ingo Schommer <ingo.s...@gmail.com (mailto:ingo.s...@gmail.com)> wrote:> > 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:email@example.com).
> --> 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:firstname.lastname@example.org).
|Re: [silverstripe-dev] Change URL field behaviour in 3.0?||Sam Minnée||3/9/12 1:24 PM|
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.
|Re: Change URL field behaviour in 3.0?||Siddharth Menon||3/10/12 7:50 AM|
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.
|Re: [silverstripe-dev] Re: Change URL field behaviour in 3.0?||Nicolaas Thiemen Francken - Sunny Side Up||3/10/12 12:57 PM|
On 11 March 2012 04:50, Siddharth Menon <siddhar...@gmail.com> wrote:Hi SiddharthI feed good about this.
I wold not worry too much about that because Silverstripe automatically redirects from a "previous" url to a "current" url.
|Re: [silverstripe-dev] Re: Change URL field behaviour in 3.0?||Ryan Wachtl||3/10/12 1:03 PM|
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.
|Re: [silverstripe-dev] Re: Change URL field behaviour in 3.0?||Liam Whittle||3/10/12 1:13 PM|
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.
|Re: [silverstripe-dev] Re: Change URL field behaviour in 3.0?||Sam Minnée||3/10/12 1:54 PM|
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?
|Re: Change URL field behaviour in 3.0?||Ryan Wachtl||3/10/12 2:59 PM|
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
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:
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
> >>> On 11 March 2012 04:50, Siddharth Menon <siddharthme...@gmail.com> wrote:> >>> For more options, visit this group athttp://groups.google.com/group/silverstripe-dev?hl=en.
>> >> For more options, visit this group athttp://groups.google.com/group/silverstripe-dev?hl=en.
|Re: Change URL field behaviour in 3.0?||Ingo Schommer||3/15/12 8:39 AM|
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.
|Re: [silverstripe-dev] Re: Change URL field behaviour in 3.0?||Ryan Wachtl||3/15/12 9:52 AM|
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.
|Re: [silverstripe-dev] Re: Change URL field behaviour in 3.0?||Sigurd Magnusson||3/15/12 2:25 PM|
Solution: After changing the URL, the yellow help text becomes "The new URL will be applied when you save and publish this page."
|Re: [silverstripe-dev] Re: Change URL field behaviour in 3.0?||Ryan Wachtl||3/15/12 6:47 PM|
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.
|Re: [silverstripe-dev] Re: Change URL field behaviour in 3.0?||Ingo Schommer||4/10/12 1:44 AM|
Hey Ryan, how's the URL field changes coming along?
Our window of opportunity for including this in 3.0 is rapidly closing.
|Re: [silverstripe-dev] Re: Change URL field behaviour in 3.0?||Ryan Wachtl||4/10/12 5:50 AM|
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`?
--To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/Kra8w3BBV6cJ.
|Re: [silverstripe-dev] Re: Change URL field behaviour in 3.0?||Sigurd Magnusson||4/10/12 11:51 AM|
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...
|Re: [silverstripe-dev] Re: Change URL field behaviour in 3.0?||Ingo Schommer||5/2/12 4:37 PM|
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.
|Re: [silverstripe-dev] Re: Change URL field behaviour in 3.0?||Ryan Wachtl||5/2/12 6:38 PM|
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?
|Re: [silverstripe-dev] Re: Change URL field behaviour in 3.0?||Ingo Schommer||5/3/12 5:01 AM|
Thanks for keeping at it, we're getting there :)
|Re: [silverstripe-dev] Change URL field behaviour in 3.0?||Ryan Wachtl||5/9/12 5:40 PM|
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.
|Re: [silverstripe-dev] Change URL field behaviour in 3.0?||Ingo Schommer||5/10/12 5:58 AM|
Pull request merged, with some improvements: