Path-redirect as an option on the node form (add or edit)

This is not a bad idea. I know my sites tend to suffer from having too many fieldsets on the node edit pages; I'd almost want the ability to disable this feature. You'd need to have a table of all of the redirects to the current node, since it's a many-to-one.

Here is a patch which also contains the features from #154925. It's a work in progress, at best. If anyone would like to take over this feature, please have at it!

Patch updated for latest dev version, which already includes the settings form.

#227163 marked as a duplicate.

Better title so people (like me) can understand what this issue is actually about. ;)

hehe, even better... ;)

I need this functionality for a site I'm building, so I picked up the torch here and got this pretty much finished. Changes since the previous patch:

A) Fixed broken db_query() usage ($nid is an int, so we should use %d not %s).
B) Fixed broken Operation links that were pointing to the wrong paths.
C) Added destinations to the edit and delete operation links so that you return to the node edit form.
D) Added some additional key help text when adding a redirect on the edit node form that you should not include the leading slash.
E) Since the previous patch went through the trouble to introduce a path_redirect_node_redirects() function for the query to find all redirects for a given node, we now reuse that in _path_redirect_node_form_list(), too.
F) Fixed some code style spacing issues for string concatenations.

Under all my testing, this is RTBC, but since it's my own patch, I'll let someone else decide that. ;)

Can we get this in ASAP? This is a great feature for this module, and I'd love to see it committed upstream.

Thanks!
-Derek

After a little more testing and experimenting with this on a real site, here's a new version with different (IMHO better) behavior. Previously, if the node had a path alias, the redirect would point to that, otherwise, to 'node/N'. However, if you change the path alias, path_redirect isn't smart enough to notice that and update the redirect accordingly. Instead of adding that complexity, I just made it so that in hook_nodeapi(), whenever we save a new redirect, we always point it to node/N. Through the magic of Drupal, the redirect always sends you directly to the current path alias for that node, if any. So, I think this is superior in every way.

The change in #8 makes sense to me. That is what Pathauto does as well.

I'm testing this out on a site now. I'll let you know how it goes.

Wonderful! It appears to work as advertised. My one suggestion is that the div class be path-redirects, as it is on the admin page, instead of url-redirects.

I'd like to get 1.2 out in the next day or so, and this looks like it should go out in that release.

Hrm, this module is rather inconsistent about that. In the UI, these form elements are called "URL redirects" and all the menu paths have titles using "URL", although the actual paths use "admin/build/path-redirect". The module name is "path_redirect". In some cases the div class matches the module and in others, it matches the UI. :(

Can everything be called "path redirect"? Module name, admin URLs, UI, and div classes? If not, I think I'd rather the classes were consistent with the UI (form elements, menu paths) but I could argue both sides if I had to. The problem is the wider inconsistency, which seems out of scope for this issue. If you want to change the div before you commit, it wouldn't bother me. Here's a trivial new patch for that if you prefer. But, IMHO, this needs a bigger cleanup in another issue.

I'm glad to hear you're planning to commit this for 5.x-1.2, that's great. Thanks!

I agree there are larger issues here, but my logic for Path Redirect (so far--keep in mind I inherited this :-) is that on the backend it's path and on the frontend it's URL. All I base that on is what I saw when I started working with the code, along with my vague impressions of what the core path module seems to do.

Anyway, pretty weak justification, but I think internal consistency is better than overall correctness in this limited case. I think it would be worth opening a ticket to discuss your suggestion of settling on "path redirects" for the admin/theme strings and whatnot.

I committed the class="path-redirects" version. I'll try to get this ported to 6.x before that branch's first official release, but I need to spend some time on the "automatic cleaning" patch first.

Thanks much for getting this working properly; I think this will be a very welcome feature!

Glad to help. Thanks for committing this! I agree, it'll be a highly-welcome feature.

That said, I have no time to work on a 6.x port of this anytime soon, so I'm unassigning myself...

I needed this functionality for a current project. Here's a ported patch for 6.x-1.x-dev.

I added a permission "set per-node redirects." This allows users to set the redirects, but not edit them.

Similar to the general "Add Redirect" form, validation exists when a user tries to add a redirect that already exists, a redirect that matches an existing path alias, a redirect matches an existing path, or a redirect contains an #anchor.

For the general "Add Redirect" form, these error messages display links to edit the conflicting redirect or delete the conflicting url alias. I added a setting to prevent these links from appearing in the node form error messages. The purpose of this is for the following scenario: If a user submits a node that throws an error due to the redirect, you might not want the user to click away from the form because the user would lose their changes. (Experienced users, of course, could simply open the link in a new browser tab such not to lose their node changes).

I like this. I've kind of neglected the module for a while with the D7 freeze and XML sitemap work but I'd love to come back and clean this module up before getting it ported to D7.

I've noticed a few minor bugs. One is that I forgot to account for l() changes between D5 and D6. :P

I'll have a revised patch for review this week.

Here's the fixed patch for review.

Subscribing.

@archimedes - can you test the patch? http://drupal.org/patch/apply is how to apply these.

FYI I've been committing changes that should help this go a little smoother. There is now a path_redirect_validate_redirect() function in path_redirect.module. That is used by the add/edit form in the module and can be re-used by this.

The latest D6 patch mostly works. However, it's giving me validation errors about not being able to add a redirect for a valid path if you don't enable the 'Enable in node edit form:' setting at admin/build/path-redirect/settings or try to edit something as a user without the 'set per-node redirects' permission...

Haven't looked closely at the patch, but still keenly interested in this feature. ;) Just in the middle of putting out a major fire now, so I don't have time to fix this. And, since for now the only people editing these nodes will have this permission, so the bug here doesn't bother me enough to work on it as part of my fire-fighting... ;)

Committed a simplified version of this to CVS with vertical tabs support. Attached screenshots of the interface. Also see CVS commit http://drupal.org/cvs?commit=294542.

Yay, than this is fixed, no? Thanks!

I think this is a good compromise between nothing and a much more complex be-able-to-edit-all-redirects-directly-on-the-node-form solution. Not saying that it's not a bad idea, just that this was much easier to implement.

Now you're in trouble. This feature has been very very handy and I'm addicted. It needs to be extended to taxonomy...

I am using beta 5 and redirects appear in the node edit screen if the redirect is to node/nnnn. Redirects do not appear when they are to the path alias. Is anyone testing with path aliases?

@peterx: You should have your redirects point to the actual URL and not aliases. When the redirect happens it will lookup the alias for you and redirect to the aliased path.

I'm seeing the URL redirects on node edit, but not on node add forms. Once I go back in to edit it, it shows up. It woudl also be nice to edit the weight of this form item. It's not showing up in our manage fields sections.

@frankcarey: The first part is by design as not-yet-created nodes do not yet have a path, so we can't show a list of redirects. Please file a separate issue for your second part. It's a valid addition.

@Dave Reid: I just noticed #30 here while looking closely at all this while working on a D6 site. The D5 version can happily add a new redirect during node add, since you can always define the redirect to be node/N. I don't see any harm allowing that to work here -- obviously if there's no node yet, there are no existing redirects, so you don't have to worry about your whole table. However, on this site I'm working on (and presumably many others) it's nice to be able to add a redirect from a legacy URL while you're creating a new Drupal node. Do you want me to open that as a new issue or should we continue discussing that here?

Thanks,
-Derek

New issue please.

Gladly: #1212012: Define a redirect while adding a node

Thanks,
-Derek