This one brings-in active path aliases, and an easy interface to edit all aliases of a system path on same page, per language. Pages are redirected automatically to active alias. There are about 4 functions which were moved from common.inc to path.inc(documentation may need changes?). This patch's most inspiration comes from chx's new patch alias interface at http://drupal.org/node/106094. Maybe i should post over there, but didn't want to hijack that thread. Please review code...

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Gurpartap Singh’s picture

FileSize
33.06 KB

Here's a screen shot of edit interface.

Gurpartap Singh’s picture

Just noticed, chx has updated his issue with 'only' the interface for alias editing, which i assume would be done "better". Maybe I should follow with this patch over there. Will talk to chx about it. Btw, this patch includes the last patch at: http://drupal.org/node/141526

Still would be good if someone reviews the patch, it'll help :)

Gurpartap Singh’s picture

Status: Needs review » Closed (duplicate)
Gurpartap Singh’s picture

Title: Active path alias, and common path interface per language » Active URL alias, common path edit interface per language
Status: Closed (duplicate) » Needs review
FileSize
42.97 KB

Back to this issue as per chx's suggestion, because the above issue discusses some unrelated stuff, like tab or pop-up.

Please review..

ChrisKennedy’s picture

Did you address any/all of my comments in #62 from the previous issue?

Gurpartap Singh’s picture

Yes, all. Please review, there were some more features to the interface like a "Delete all" button, to delete all aliases for a system path in certain language.

ChrisKennedy’s picture

Status: Needs review » Needs work

The system.install update number needs to be incremented.

But when I manually fix that error and try to add a path alias via node/X/edit the alias is never saved.

moshe weitzman’s picture

Very nice functionality, especially needed for proper SEO.

CODE REVIEW
- i think + if (isset($_POST['op']) && ($_POST['op'] == t('Delete all'))) can be removed in favor of adding a handler just to the delete all button. thats new for fapi3.
- why are we implementing hook_user and hook_comment? does something autocreate aliases for every user and comment? i am missing something here.
- "Optionally specify an alternative URL by which this node can be accessed.". I would remove the word 'alternative', given the fine redirect that this patch does.

Gurpartap Singh’s picture

Status: Needs work » Needs review
FileSize
43.86 KB

This one applies to new HEAD revision.

node/X/edit actually sets the alias, but when editing it shows only active alias. so the alias which you wasn't set as active. With this patch, alias set at node/X/edit will be set as active.

moshe weitzman’s picture

Also, I would rather not include all of filter.module this early in bootstrap. did you do that just because we need filter_xss_bad_protocal? if so, consider moving that function to bootstrap.inc instead.

Gurpartap Singh’s picture

A total of 5 functions were needed from filter.module, so rather than moving to path.inc or bootstrap.inc, we just included filter.module. The patch now uses submit handler for Delete all button, the fapi3 way. Also fixed deleting path alias by path ID. hook_user, hook_comment, and hook_nodeapi, are used to delete aliases assigned to comment, user or node path, when they are deleted from database(op=delete), because the comment or user no longer exists, it's of no use keeping the aliases for them.

Gurpartap Singh’s picture

Sorry, here is the patch.

moshe weitzman’s picture

- i can only find one minor UI glitch. I see Alias 1 repeated even for the 2nd alias listed for a given node. I actually suggest getting rid of these titles. the system url and new alias titles are helpful, but the numbered ones are not IMO.
- "$_GET['destination']) ? $_GET['destination'] : 'admin/build/path'". can you just try admin/build/path' here. i think the form submission code wil just use destination if it is on the URL. no need to handle it.

Gurpartap Singh’s picture

  • Fixed user access to path edit form.
  • Removed Alias 1.. Alias 2..., prefix from alias fields.
  • Fixed the destination code as suggested above. When new alias is added, user is redirected to edit form for that alias so the he/she may add more, etc, otherwise redirect to overview page.
  • Fixed some bugs with filter form.
  • Slight text changes.
Gurpartap Singh’s picture

Sorry, above patch included some jquery.js stuff. Use this instead.

moshe weitzman’s picture

Status: Needs review » Reviewed & tested by the community

Works for me.

Dries’s picture

I haven't looked at the code yet -- I started by looking at the screenshot.

Essentially, I'm confused by the Language drop down menu at the bottom. It's not clear what the current workflow is like, or what would happen if I changed the language drop-down menu. Would that cause duplicate path aliases to be inserted?

My suggestion #1: shouldn't there be a drop down menu next to each alias' textfield? That would provide me with a better overview of all the aliases, and it would allow me to translate aliases faster.

My suggestion #2: shouldn't there be a mechanism to remove a path alias from that list?

My suggestion #3: I'd use this interface on the 'add path alias' page but also in a fieldset in the 'edit node' page.

Gurpartap Singh’s picture

How the language thing works:
# User chooses a language(in select list) on add alias form. Proper validation is done, if the alias exists in that language. If not, the alias is added to that language.
# Edit screen is by language, i.e. if user is editing aliases for german, he won't see aliases for 'all' or any other languages. On aliases overview table, the edit link under Operations links to ?q=admin/build/path/edit/all/node/1, where 'all' is language, and the rest part is the system path. say the same for german would be ?q=admin/build/path/edit/de/node/1. The language select list's attribute is set to disabled as here it's just for user's information that he's editing alias for foo.

A language select list per alias would really be causing hick ups at validation, or at least it would take lots of code changes, making it hard to review.. :P

# To remove an alias, clear the alias from field and submit. A help text stating that should go in.

# On node edit page, only the active alias is shown and can be set currently. In whole table on that page, user permissions, as currently set, won't let the node owner edit the aliases, he can only add new if he has 'create new aliases' permission. Is it worth displaying the whole table?

Dries’s picture

Status: Reviewed & tested by the community » Needs work

I still think there is room for UI improvements here. Putting all translations on the same UI really helps when you're the single translator (like many people in Belgium are).

Marking this 'code needs work' until some of these suggestions have been tested/implemented. Thanks.

Gurpartap Singh’s picture

Status: Needs work » Needs review
FileSize
43.29 KB

This patch is just a re-roll. As discussed on IRC, the interface showing language drop downs for each alias field didn't prove well at end user's understand factor. Here's the screenshot: http://img2.freeimagehosting.net/uploads/d9775a8a5a.png It's just confusing for one who just started with these things.

So, chx suggested to have tabs for each language, like an "English" tab would appear on top, clicking which shows aliases for that language, default tab being 'All languages'(all is not every language). It's easy to accomplish this with the new menu system, but in that, we could fetch only the first part(i.e. before a slash), of the source path. i.e. suppose we are on this page ?q=admin/build/path/edit/all/forum/1 and our menu tab item in hook_menu for english language is: admin/build/path/edit/en/%
so that wildcard is only a keyword within slashes, whereas we need all the part of url after that. so that tab would link us to: admin/build/path/edit/en/forum

the reason for explaining this is if there's anyone with an idea for the interface when we are dealing with multilingual aliases? could a feature request be made to menu system to allow a new wildcard which is placed at end of path and it passes the rest part of url to the callback?

only new thing with this patch is, delete operations link in edit path interface, and removed "delete all" button.

alpritt’s picture

FileSize
57.96 KB

Note: I don't really know how languages work in general in Drupal 6, so this may not make total sense in context. However...

- Languages are all on one page.

- There is a drop down menu next to all the aliases allowing easy selection of language

- It is only possible to select one permanent/default/active URL per language. In other words there will be no error message since it is impossible to enter more than one default per language.

- Aliases and permanent URLs are separated to make it clear they are different.

- Easy to delete aliases (not necessarily a good thing, but hey)

- No need to validate user input for alias language. The drop-down list, next to redirects, only contain languages that have a permanent alias associated with them already.

Gurpartap Singh’s picture

Title: Active URL alias, common path edit interface per language » Active URL alias, new path edit interface
FileSize
47.71 KB

This one implements using tabs, and works against current HEAD revision. Screen shot coming ahead.

Gurpartap Singh’s picture

the screenie.

moshe weitzman’s picture

would be nice to get this one in D6.

catch’s picture

I really like both the concept and the UI (tabs version). Would be good to get it in.

dmitrig01’s picture

Status: Needs review » Needs work

Love it, but patch doesn't apply :x

chx’s picture

Status: Needs work » Needs review
FileSize
45.36 KB
catch’s picture

Status: Needs review » Needs work

fresh 6.x tarball, patched it, installed.

Cannot redeclare system_update_6024() (needs to be 6025)

fixed that manually in system install, patched, installed.

I created two nodes. Added path alias on node add form for each - this was fine.

Went to path admin, added an extra path, worked fine.
Redirect from non-active to active alias is fine. And I love the way it finds existing paths when you add a new one.
Added a third path - WSOD.

admin/build/path/add works
admin/build/path/edit/all/4?destination=admin%2Fbuild%2Fpath - WSOD when I save any changes at all - either a new alias or changing the "redirect to" radio.

Everything about it is great apart from these bugs. Didn't test any of the multi-language stuff at all.

Gurpartap Singh’s picture

Which of the following interface is better, and simple to understand(for novice starter)?
Screenshot 1
Screenshot 2
Screenshot 3

IMO, 1st one is as simple as it could be, and the basic one.
2nd one too much complicated, although it allows quick and advanced users to complete their task as quickly as possible.
3rd is same as the 1st one, just each language's tab appears at top allowing the user to set aliases for each language under each tab.

so... which one do you vote for? maybe we can get this into core as soon as possible, before there's the next feature freeze.

moshe weitzman’s picture

#3 look good to me. glad we are still working on this.

catch’s picture

I like #3.

catch’s picture

Should expand. Last time I tested the patch, #3 was the interface, and it was very, very easy to use and behaved exactly how I'd expect. Massive, massive improvement on the current interface.

Gurpartap Singh’s picture

Status: Needs work » Needs review
FileSize
49 KB

Very much hopefully this patch covers most of tiny tod bugs, which were caught while testing this time. and hopefully we get this in soon :)

Gurpartap Singh’s picture

Review? :'(

catch’s picture

Fresh Drupal 6.x-dev tarball. Installed first, patch applied cleanly. System update ran with no problems, didn't generate any errors at all while I was going through.

The user interface is a massive improvement on the existing one, I'd go so far as to say it's ergonomic - adding multiple aliases becomes very, very easy, because you immediately see all aliases for a path, so you get an overview of what's there. Also the default radio selections make loads of sense and save some mouse clicks in most situations.

This is considerably better than having to go through over 500 pages of aliases on my current site. There's no way, to find all aliases related to one system path at the moment without looking through manually (the new filter only applies to aliases themselves).

Also, the active path functionality works fine, is 100% necessary for these UI improvements, and also sits well with possible path lookup optimisations elsewhere in the queue (splitting out of 'object' paths etc.).

Gurpartap Singh’s picture

Title: Active URL alias, new path edit interface » UI: New alias edit interface; Active URL aliases
Gurpartap Singh’s picture

Sorry the above patch included outdated .htaccess changes. And screen shot, of what we have without the locale module, to follow in next post.

Gurpartap Singh’s picture

Screen shot of interface, with locale module disabled.

Stefan Nagtegaal’s picture

Status: Needs review » Reviewed & tested by the community

First of all, nice patch!

I tested the patch on latest HEAD and this really make things straight forward. I cannot come up with any improvements about coding style, (error) messages or any functionality this patch offers that isn't the way I expected it to be.

So, I'm setting this RTBC..

Very nice!

Gurpartap Singh’s picture

Fixed a minor bug in hook_nodeapi. Language was not being set for aliases when inserting or updating.

Thanks for the review Stefan!!

Dries’s picture

Status: Reviewed & tested by the community » Needs work

* I like screen #2 best. It makes it faster to manage multi-lingual content. Belgian translators have asked me for _exactly_ this UI.

* Looking at the screenshot, the page title looks wrong. It should probably be 'Edit $path' or something.

* Patch no longer applies.

alpritt’s picture

Asking people what UI they want is never going to lead to something they actually do want. Most people are not UI designers. I presume what they actually want is an easy to grok, but fast and efficient interface. They are not going to get that combination with any of these options.

Option 2 would be a compromise with a bias towards speed of operation. But it is completely non-intuitive, so you are serving up another learning curve with this. Make sure you are aware of the dichotomy here.

Gurpartap Singh’s picture

Can we run the Advanced Path alias edit interface as a contrib :P
i was confused using that interface too. if you really have more thumbs for that interface, then will update the patch as soon as possible. Need feedback from others please.......

catch’s picture

I still like #2 for the interface. Don't like the idea of checkboxes in a single language situation for a start (assuming they don't revert to radios if only one language).

Gurpartap Singh’s picture

Waiting for http://drupal.org/node/157510 to get committed.

catch’s picture

Version: 6.x-dev » 7.x-dev
Gábor Hojtsy’s picture

The patch this issue was hold off on got committed, so this might be the time to review this issue. (Not for Drupal 6 unfortunately).

moshe weitzman’s picture

OK, it was sad we missed D. But lets get this into D7? Anyone up for refreshing this?

Gurpartap Singh’s picture

Title: UI: New alias edit interface; Active URL aliases » New URL-Aliases admin UI

I'll submit the active alias feature as a separate patch, and only after improved interface patch gets in.

Gurpartap Singh’s picture

Status: Needs work » Needs review
FileSize
18.33 KB
kika’s picture

subscribe

lut4rp’s picture

Status: Needs review » Needs work

Wish I figured out where its going kaput, but this isn't working out. On patching a clean HEAD, it isn't allowing me to edit any alias or add an alias and gives a 'Page not found' error. Still, going over the code...

basicmagic.net’s picture

subscribe

Gurpartap Singh’s picture

Title: New URL-Aliases admin UI » New URL aliases UI
Status: Needs work » Needs review
FileSize
21.49 KB

Now with compatible path.test.

Gurpartap Singh’s picture

Issue tags: +Screenshot
FileSize
60.46 KB

Here's a screenie with some langs enabled.

Status: Needs review » Needs work

The last submitted patch failed testing.

Gurpartap Singh’s picture

Status: Needs work » Needs review

But the test "Path aliases with translated nodes" works absolutely fine with latest HEAD.

catch’s picture

Issue tags: +Needs usability review

Status: Needs review » Needs work

The last submitted patch failed testing.

Gurpartap Singh’s picture

I really don't believe bot's response. Can anyone else confirm this?

Gurpartap Singh’s picture

Issue tags: -Screenshot +Usability
Gurpartap Singh’s picture

Status: Needs work » Needs review
Gurpartap Singh’s picture

Syncing with HEAD.

chx’s picture

Status: Needs review » Needs work

You can use %menu_tail for the argument instead of the func_get_args stuff because then you can keep the one argument passing in which can be doxygen'd and stuff. I severely disliked the breadcrumb mungling, why is that necessary? The system path totally needs to out of the table or separate better it's rahter confusing right now.

cburschka’s picture

Status: Needs work » Needs review

Comments about the screenshot (http://drupal.org/files/issues/Picture%2013_8.png):

- Any AHAH for generating more fields? Having to reload the form for each new alias added or deleted is /so/ Drupal 5. ;)

- The headings are misleading. They claim that "System path" applies to the three paths above, although only the first entry is the system path and the other two are aliases.

Gurpartap Singh’s picture

@chx That's truly a hack to come up with a preview. Really, how would I go to avoid "Edit alias" to appear in the bread crumb when Locale module(+ a language) is enabled? Anything inconsistent in hook_menu()?

webchick’s picture

Status: Needs review » Needs work

Note: In order to not influence my interpretation of the screenshot at http://drupal.org/files/issues/Picture%2013_8.png, I have deliberately NOT read this issue for now, since everyone else who sees this screen will be in the same boat later on.

a) I see from the breadcrumbs that this interface is at Administer >> Site building >> URL Aliases. I actually think that it's much more intuitive to do this kind of management *within* the context of the page you are trying to re-locate. IOW, I would expect this interface at node/1/edit, not at admin/build/path.

b) To me, what this screen appears to be lacking is a way for me to specify which of the 3+ paths is the "real" one. Each page should only have one "real" URL, and the remainder should be 301 redirected to it. For example, if I go to http://en.wikipedia.org/wiki/http, it will automatically send my browser to http://en.wikipedia.org/wiki/Http, the "real" URL of the page.

Gurpartap Singh’s picture

Status: Needs work » Needs review

@webchick
a) That would be too complex for the end user who simply wants an alias for the node being created, where language is chosen contextually. Maybe more complex with permissions checks for (b) (below). And maybe, on the node edit form, some admin may not want to reveal what secondary aliases he/she has set for a node, to users with node edit access. (Remember, that alias might not be the "real" one).
b) That's on the plan of this issue. Patches upto #40 for D6 have had that feature, but I split them and decided to work on them in series.

Status: Needs review » Needs work

The last submitted patch failed testing.

webchick’s picture

Status: Needs work » Needs review

Right, after reading the issue I realize that this is just for the global path administration interface, not the interface within individual pages. But I still think that we need a way for people to get to this interface *from the node*, rather than forcing people to go to a completely different section of the website. It's fine if it's a tiny link in the URL Alias fieldset or something, but there should be something.

Also, I'm all for the preservation of kittens, but I'm not sure why it makes sense to split this feature along those lines. Making the addition of multiple URL aliases for the same path easier doesn't really make any sense to me unless you can also mark only one of them as the "real" one. Am I missing something here? I admit to not being a translator...

Finally, do you still happen to have a copy of "screenshot #2" from http://drupal.org/node/147143#comment-561310 for comparison?

catch’s picture

Users, taxonomy terms, various other paths are all incredibly different to administer url aliases for. So for a UI that's available around the site, it'd be great to find something which will work on any page - or at least include the same widget which is applied to node forms to users and taxonomy terms as well. But that looks like a follow-up issue.

Gurpartap Singh’s picture

@webchick I like the idea to link from node/X/edit page. But it would only be useful when editing nodesand will cost a simple query to fetch the pid. Worth it?

This UI along with the "active alias" feature made the patch to be 50 KB in size, which was really hard to manage, since all the re-rolls required only UI related changes and it turned out harder to keep it synced with HEAD.

Here's how I intend to make use of the UI. "Redirect to" is not-so-self-explanatory term, but we'll decide for it on it's turn.

I'm afraid I might have lost screenshot #2. I'll have to search my desktop's hard drive for it. I really regret not posting the patch for the screenshot #2, to keep a track of code.

@Arancaytar Good idea, but I might take that as a follow up issue.

Anyways, rerolled with a new interface to separate actual aliases from "System path" heading. Screenshot attached.

Status: Needs review » Needs work

The last submitted patch failed testing.

Gurpartap Singh’s picture

Status: Needs work » Needs review

Ok, I guess the test needs to "add the french language" to pass. Other than that, please review the rest.

Dave Reid’s picture

Following for review later.

eigentor’s picture

FileSize
139 KB

I got a similar Impression as Webchick has. Thinking from a beginners Perspective, this actually adds cmplexity instead of reducing it.

Find attached my commented screenshot, sorry for the confusing array of arrows. Argh, I hope for allowance of inline images on issue followups after d6 redesign...

Will provide a Mockup of what I think is better later.

dmitrig01’s picture

I disagree with the blue arrows. how do you know what a path is. this simplifies it IMO.

yoroy’s picture

What baffles me most with this patch is that it doesn't change the bit that seems the most counter-intuitive to me:

1. You get to this page by clicking the 'edit' link next to an alias in the 'URL aliases' page…

"click"…

2. Huh? Change system path?

All signs were indicating that I was going to change the alias, and the first editable thing I get is changing the system path.
Why is this? Is it a more common scenario to change the 'original' that all your aliases are pointing to?

To me, the first thing I'd expect to see is a text field to change the name of the alias that I clicked the 'edit' link for on the previous page.
As there might be more aliases for the same system path, I think the list of know aliases should probably be the first item on this page. bonus points for focussing or sorting on the one you actually clicked the edit link of.

To me the most natural order of actions seems to be:

- change the wording of existing aliases
- add a new alias
- change the sysyem path all listed alias point to.

But I don't visit these screens all to often so let me know if you think that for example changing the system path is a more likely task users want to complete here.

yoroy’s picture

Status: Needs review » Needs work

This summarizes how I think this ui should work:

Gurpartap Singh’s picture

yoroy that's an excellent work. I had actually done that long time back, just that "add new alias" and "system path" were exposed as editable textfields just like existing aliases.

Where it failed for me was:

1) when setting "active aliases". The interface turned way too cluttered and confusing with checkboxes in first column. The validation checked for only 1 active alias per language.

2) Setting "system path" as default/active path will take effect for "any" language.

but nevertheless the above mock up rocks. I _want_ to work on exactly this thing. Take it as my request to overcome above caveats somehow? :D

yoroy’s picture

Dang, I'm still putting the system path first there. Weird, that's what confused me at first. hmm.

Gurpartap asked me to try and incorporate the functionality of making a certain alias the active one (this means that any alias for the same path also resolves to the active one). Maybe we should name it the "default alias"? A default alias can be defined for each language.

Before looking into that, one more look at the layout without it. Getting tricky with the system alias info, still shown on top but made part of the description…

Noyz’s picture

Yoroy: As I was reading this thread, I was assembling the same UI in my head. Glad I didn't have to put it together. +1

eigentor’s picture

I'd also say #81 is perfect. The balance is better if the system path is small, like the other paths.

I still wonder under which circumstances it is possible to change the system path. The node you come from: you cannot change its system path.

Go Yoroy.

yoroy’s picture

Issue tags: +ui-pattern

and another tag. I have an idea for the 'make active' functionality, will try to post that soon

yoroy’s picture

What I was thinking to do is already showing up in Mark's designs as well:

From here: http://www.flickr.com/photos/mboulton/3569318373/sizes/o/in/pool-903403@N22/

Make it show (and clickable) on hovering the table row

Gurpartap Singh’s picture

And is already there in list (and smileys - but not on hover) module that I co-maintain:

Mentioning just if anyone wants to adopt code or images from it. Pretty nifty if this is accepted in core!

Any issue/d7ux blog link where these UI features are being talked about?

elvis2’s picture

#81, great work. I agree with others though, that this functionality should be central to the path module, allowing user, taxonomy, node, - anywhere else where aliases can be handed out, to hook into the path module and create aliases.

So, on node/1/edit, near the bottom (I am sure there is a name for this section, I am still new at d7 stuff), your path alias screenshot would be an option, within the node.

If the user is also using tags, on node/x/edit, then path module would sever up an alias option too.

The same goes when on admin/structure/taxonomy/1/add, give the user a path alias option, and if local is installed give them aliases per language.

catch has mentioned the user/x/edit too, letting users change their user name account path. (koodles for the idea). Here too, your path alias mockup could apply.

I think this idea is powerful, but lots of code rewrite to do... I am not sure how likely it is to get this type of functionality into d7... Maybe it should be a goal for d8?

Dave Reid’s picture

Version: 7.x-dev » 8.x-dev

Bumping to D8.

gaelicWizard’s picture

+1

Bojhan’s picture

Issue tags: -Needs usability review

yes

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

jibran’s picture

Title: New URL aliases UI » Add new URL aliases UI
Version: 8.6.x-dev » 9.1.x-dev
Assigned: Gurpartap Singh » Unassigned
Issue summary: View changes
Status: Needs work » Active
Related issues: +#3007832: Convert custom path alias forms to entity forms

Do we still need this after #3007832: Convert custom path alias forms to entity forms? Moved to 9.1.x as it is a new feature and 8.8.x is alpha ready.

Berdir’s picture

Status: Active » Closed (won't fix)

We did our best to keep the UI just like it was before with the entity forms, so it's not really related to this except that it isn't possible to build such a UI with entity forms.

I'd suggest to won't fix this. More than one alias per system path is IMHO discouraged, except when it is about different translations and the UI doesn't seem to be mention that. The last working screenshots here are 10 years old ;) No idea what was on those redesign screenshots as they don't work anymore ;)

And no comment since 2011 doesn't exactly indicate that people are still interested in this.