Prevent duplicate pages (active URL alias)

I like the idea a lot!

Just did a quick review. Not all features are implented yet, if you want to test it anyway you have to run alter table url_alias add column active tinyint not null default 0; in advance. The interface works as expected for the 'official' paths (node/20/paths) and looks already very clean.

I'll review again when the missing features (mainly sending out 301s for inactive paths) are implented.

Kick ass chx! This is another step in the right direction, I'll give her a spin later on.

Subscribing, more thoughts later.

For folks following along at home...

This patch removes the "administer url aliases" menu item altogether, and replaces it with a block that can be placed in one of your regions, which adds the UI shown in the initial post.

The idea is, when I'm looking at a post, I can specify the single path that should point to a given page, rather than break the workflow and go somewhere else entirely to have to edit it.

However, I'm not sure I like the particular approach...

a) The block is very wide, so can't fit into a right sidebar or something without scrolling (in Garland, anyway, at 1024x768ish browser window size
b) Because the block is collapsed by default, it's an extra click on each page.
c) The idea was to do the same type of things that wikis do, but if that's what we're trying to emulate, we should actually do it that way: let people with the correct permissions (create path?) type random urls in, and on 404 error put a button/link that says "Create page at this address"
d) Rather than removing the administer interface altogether, I think we should make it more like the admin/node interface with the shift+click/operation stuff.

Here are a couple code-related suggestions:

1. Include the db change in an update
2. Auto-expand the Administer URL alises fieldset when there is an alias defined.

Ok. After further discussion with chx on IRC, this is what this patch does:

Go here: http://en.wikipedia.org/wiki/Racoon (notice raccoon is misspelled)
It will redirect you to: http://en.wikipedia.org/wiki/Raccoon automatically

So whatever path is defined as "Active" is the one that the other paths that are _not_ defined as active will redirect to.

I'm not convinced that moving administration functionality to a block is a good thing. It's not what we usually do so I think it makes for a bad precedent. I'd prefer to keep things like that on separate configuration pages, or on the main content area. Plus, it requires that the theme supports blocks/sidebars.

What I think should happen here is that we have an admin page with groupings similar to the way admin/build/block looks. It would of course need to be paged. Here's the kicker: at the top it has a search filter. Bonus points for making it autocomplete.

Then, keep your block and simply link to a search from there, keeping the nice in-page context if the site owner wants it. Also, a link would solve the width problem.

@chx - I like the initial shot with an Alias tab on each page as opposed to the block. IMO that's more consistent with the rest of the interface. Good stuff!

One reason: mass edits.

Example: I create a few pages like "faq" and "company_profile"

I decide that these really make more sense in an entire "about" section of our site.

In order to make these "about/faq" and "about/company_profile" I need to go and visit each page, expand the block, edit the path, and then save. Repeat for each page.

Vs. an admin panel with all paths, I can quickly select the ones I want to edit, check them off using the same stuff from the admin content page, and be taken to an interface that shows several of those UIs in a row that I can edit at once.

I agree. Although the admin page right now pretty much sucks, we can deal with separate issues to allow for mass operations like users/comments/nodes do now.

Where's the right place for the UI to choose the default/active alias?

In a block?
-- definately not

On a new page or tab like node/25/path?
-- neither.

To find the right place for it, we need to consider what it does:

• it edits an element of a node
• it manages paths

Sounds a bit like the path module doesn't it. Only this way is much better. In fact, this code would replace, or at least extend the path.module, wouldn't it?

So, the right places for the UI(s) for this feature are:

• node/25/edit in the 'URL path settings' fieldset, AND
• admin/build/path

This allows for individual path editing 'per page' as an author, and mass editing as an admin.

I had a little problem to understand the attached picture (snapshot.png), about what should this form do. It is confusing what active-inactive alias means, and why the system path is displayed between aliases. Maybe I am missing something, maybe some new features I am not aware of, I don't know..

So I quickly drew a different form. What can be understund at the first look, but I am not sure, if it is the same feature what is described in this issue..

I know this would be slower on changing the active (primary) alias..

Then now is a good time to subscribe.

For the record, I see this patch as an extension to the path settings/overview pages as well as a replacement to the path fieldset box in the Edit node section? Then it only makes sense to keep using those areas and just plug in the new functionality!

chx, where do you propose is the best place for the ui for this? And why?

The path alias admin page sucks -- I agree with chx. It's totally unusable on *every* single site I manage. The only useful thing on that page is to add a new alias.

It would be significantly better to visit a page to see what, if any, alias is for the page and change it there.

Any other time I need to work with aliases I hop into the database where I can use MySQL LIKE matching to find patterns.

+1

To answer chx's question, and to carry forward webchick's argument, we can use the admin > path settings overview page for editing multiple paths. At the moment the current page just returns an overview of all the paths on your site in case you wish to scan for paths and make informed decisions with regards to SEO. What it doesn't support is mass editing/deleting of paths. This renders the page useless for people who can carry out the existing functionality through other means (look at the footnote). For D6 we can easily have a checkbox column to the overview page with Edit & Delete buttons for mass editing and deleting of selected paths. This will:
1) Add further needed functionality in order to make the page more useful (even for the skilled admins).
2) Improves the workflow and efficiency of admins, faster management of the site paths.

Generally, I view the Amin section as a tool to consolidate all the site's administration as well as enabling them to carry out mass tasks efficiently. Editing each node's path individually is OK if it's only a few pages. However, it gets more troublesome if you had to carry out this exact task on a daily basis.

Note: I didn't mention sql, phpmyadmin etc in this post - this was intentional.

subscribe

I'm beginning to understand chx's point of view now. However I think BioAlien makes a good point. Additionally mass editing of URL aliases would be really useful.

I still think a whole tab for URL aliases is perhaps a bit much. I don't see why the new interface can't replace the existing colapsable fieldset on the 'edit' tab. Unless a page has more than 10 aliases, which I think would be very exceptional, then it's going to be a small tab anyway.

chx,

I'm sorry If I seem whiney, not understanding, sheep-like, or simply a nuisance. I'm not trying to be any of those things, or any other negative thing. I'm just trying to get my head around your objective, perspective and plan for this feature, which is obviously much more advanced than my understanding and perspective. I think you're being much more objective about than I am. I suspect that a few others that seem to be opposed to 'your way' are, like me, not quite getting the idea -- perhaps they're not even conscious yet that they don't get it.

Every time you post however, it makes more and more sense to me. I agree (now) that an admin page for url aliases serves little/no purpose. In my own words; the only really useful mass task is delete, which is against the whole idea of maintaining one active path per node, and redirecting all other paths / aliases for that node to the active path. 'All other paths / aliases' includes any old alias that is no longer active. If you delete an inactive/old alias, then any bookmarks, search indexes, or links to that URL will lose the active URL and just get 404s on the old path. Hence deleting aliases is just bad practice.

Deleting paths would possibly be useful when you want to reset all of a site's paths after or during testing a site -- before publishing for the first time on the internet (probably in combination with pathauto). However this is probably best achieved differently -- i.e. not through an admin paths interface.

I still don't understand why you think a tab is necessary and/or better than a fieldset in the edit tab.

B/ :)

Aha! Damn good point!

Great ! A popup.js library would be a nice thing to have.
Wouldn't it be best in a separate thread, so it can be reviewed in itself ?

Call to undefined function: _path_get_path() in modules\path\path.module on line 95 :-)

Urgh. JS popup? We don't have this anywhere else. How does this degrade gracefully with no JS?

Adding / extending the alias form directly on the edit page (ie. if you administer path, you see all paths) is one way. I actually do like the edit tab for all aliases, tool, but that gets to be too many tabs...

Search on the URL alias with simple patch at http://drupal.org/node/141526 seems like it should go in, too.

out of my league, but I like the look of this on first glance.

couple questions

1. will redirects from non-active paths to active paths work with aggressive caching?

2. I'm guessing it's easy to add non-active urls straight in? (say I want to add a legacy url I've been getting a 404 for to redirect to the main one.) That'd remove any need for path_redirect

3. Does the 'active path' functionality also redirect from node/123? In which case that covers global redirect as well.

One more vote for mass-deletion - I get a lot of paths with something-0 at the end due to duplicate titles/terms. pathauto can easily make identical appended aliases for free-tagging vocabularies. I want to delete all of the aliases with similar paths so I don't have the system telling me I'm trying to make duplicates when I change /tags/feedback-0 to tags/feedback . Then I can add more sensible ones back in from scratch.

Having said that, if you had a "this alias is already used by node/12, setting this alias will remove the old one, are you sure?" - which'd delete the old alias before the new one is committed" as an error message, that'd cover situations like that.

Another use case for mass deletion would be replacing something like the blog module with views - to clear out thousands of user/blog and user/blog/feed aliases out so they can be views arguments instead. I'd still want to keep user/blog/node-title-alias though so the sql for that would get complicated.

*ducks*

Well, the page headers will contain a redirect so the aggressive caching I believe yes.

Very nice!

Straight in, what? You can add any number of path aliases and one is active. There is a screenshot, though.

Ok that sounds great, it wasn't immediately obvious how to set one as active from the screenshot, that's all.

If there is an active alias then it will redirect.

Now that is lovely.

You can't delete thousands of aliases from an UI anyways, so your argument is moot.

If I can check all on a screen of 50, and do that 20 times, I've deleted 1,000 aliases. That's potentially quicker than learning how to distinguish with blog/user-name blog/user-name/feed and blog/user-name/some-title with regular expressions.

But I can't fathom why it's a problem to not have link rot.

If I delete all aliases like blog/user-name for blog/[uid] and replace them views arguments like blog/user-name (blog/$arg) - then I've got no link rot. If I can't delete them, then I've got duplicate path nastiness. The existing ui doesn't have mass-delete though so nothing lost, and I could go learn regular expressions. I think it's a valid use case though. Another would be if I wanted to replace all the individual forum indexes with tabe views and arguments - that could easily be 100 aliases to delete.

Another question:
There's no blocks on rss pages, so how would you alias them with this system?
Also I think it's feasible (although I've never done it) to alias files, same question again.

Not a fan of the popup, and neither am I a fan of a separate tab. I think it should be done in a jQuery powered fieldset. However, I do like the functionality that is being proposed.

Ideally, I'd like to combine URL aliases and menu handling. Rough overview:

  Active  Name           URL alias        Menu parent
  v     [About us    ]  [about-us ]    [Navigation |V]
  o    [About us    ]  [about    ]     [--         |V]

Advantages:

1. Can manage multiple path aliases from one screen.
2. Can manage URL aliases from the same screen -- compresses the form.
3. Groups related functionality.

@chx - did you mean to set this to 'needs review'? you might want to fork into a new issue if yourpatch is much different from what was discussed earlier.

@chx I believe dries comment about a "jQuery powered fieldset" refers to a collapsible fieldset -- one that can be shrunk/collapsed into one line, and/or expanded to show fully it's contents.

I agree with dries that it is the ideal solution for nodes, however not necessarily for other pages such as taxonomy/term/123, views, contact, and other non-node pages. A tab or a collapsible fieldset could work in some cases. A fieldset works for views, but not for admin or user pages. To make an alias for user/login, admin/content/node, node/add/node_type, gallery, gallery/123 or contact, a tab in each module's settings page could work. However I'm not sure that providing a new tab in every module is appropriate as there are modules that provide no pages and therefore an 'alias' tab is not necessary. There are also potentially modules that don't provide settings pages, but still have pages.

I wonder if this is the problem that caused the admin/build/path interface to be created in the first place? I agree that edit and delete serve no purpose on this interface, but if there is no 'right' place for alias adding/editing in non-node pages, or if we are unable to generically provide tabs / fieldsets without changing module code, perhaps a centralized interface like admin/build/path/add is necessary?

i opened another issue( http://drupal.org/node/147143 ) for active alias interface and redirecting to active one. It should probably have gone over here, but i missed to see this issue's updates, so forgive about that..

now, should probably take up code from chx's last patch above and add features to redirect to active aliases. Let's see..

This one includes a working interface, only. User is not redirected to active alias. I believe this patch is ready as RTBC, but just needs the pending work, to accomplish the feature. :) Please try to review this much before the next one comes in.

an update.

Finally, this is with complete proposed features. Please review!!! :D

I only have time for a visual review unfortunately, although hopefully I can test it soon. Anyway here are a few very minor things:

$options += array( -> the closing ");" is misspaced.

$attributes= array( -> needs an extra space.

Remove a space of indentation after $form['alias'][-1] = array(.

!empty($data->language) -> extra space before the semicolon.

system_update_6022() - no need to use a switch statement if it's the same for all databases.

Moving to http://drupal.org/node/147143 as the most of discussion above, like tab or pop-up, doesn't apply to this patch.

I still think an active column in URL alias would be useful, bumping this back to CNW. See #358315: drupal_lookup_path() not respects alias' order for another problem from not having one.

of #147143: Add new URL aliases UI