Path-redirect as an option on the node form (add or edit)
Summit - August 20, 2007 - 12:28
| Project: | Path Redirect |
| Version: | 6.x-1.x-dev |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | patch (to be ported) |
Description
Hi,
I would like to be able to set the path-redirect in the add/node/weblink page.
Like the metatags (Nodewords.module) and other modules are able to add fields to the add/node process.
The specific item it is right now is more difficult to maintain. My most redirects belong to a node, and that would be the best place to maintian them.
Could this be possible please?
greetings,
Martijn
#1
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.
#2
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!
#3
Patch updated for latest dev version, which already includes the settings form.
#4
#227163 marked as a duplicate.
#5
Better title so people (like me) can understand what this issue is actually about. ;)
#6
hehe, even better... ;)
#7
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
#8
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.
#9
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.
#10
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 ofurl-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.
#11
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!
#12
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!
#13
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...