Download & Extend

URL aliases not used after saving a page

Project:Revisioning
Version:6.x-3.4
Component:Miscellaneous
Category:feature request
Priority:normal
Assigned:RdeBoer
Status:closed (fixed)

Issue Summary

First off, I just want to say that this is a great module - thanks for developing it! I've always wondered why similar functionality isn't included in the Drupal core.

As for the issue, I noticed that the URL Alias for a given node is not used after saving any changes made to it. Instead, it only uses the system URL, plus some revision information. For example, instead of going to mysite.com/about after saving changes I make to the current version of my About Us page, I'm taken to mysite.com/node/74/revisions/79/view

Since the URL is different, any and all blocks assigned to show on that page won't be there until I type in the right URL or click a menu link. I know I can get around this by assigning the blocks to show on that specific system URL/path (node/74/*), but this can be very time consuming if you have a lot of pages and blocks. Is it possible to use the URL alias instead (i.e. mysite.com/about/revisions/79/view)?

Thanks,
Chris

p.s. - This might be similar to this issue submitted by cdale, but I couldn't follow everything said in that conversation.

Comments

#1

Assigned to:Anonymous» RdeBoer

Thanks for your support, Chris!
What you say makes sense. Hope to incorporate your request when I have time to work on the module some more.
Rik

#2

Exactly the same problem :)

#3

Same issue here too. Looking forward to your updates.

#4

To make a long story short, this is not so much a Revisioning issue (although you noticed it first when using Revisioning), this is a general issue with core's path aliasing system.
Below is a beta version of a module I have just completed to address this issue across your site.
Take it for a spin and let us know if it works for you.
Before enabling the module please follow the instructions in the enclosed README.txt.
Rik

AttachmentSize
path_alias_xt.tar.gz 3.99 KB

#5

Status:active» needs review

#6

Hello,

Thanks for this module.

I just tried it and it seems to work in a way.

But It's only replace "node" by the alias.

When you click on "View", you have node/1254/view.

With your module enable, you have [alias]/1254/view.

I think the apropriate behaviour should be to have only [alias]/1254. Without "/view".

But It's certainly enough for the page visibility problem.

Anyway I'm going to continue to test it this days :)

#7

Hi Junro,
It only does that (append "/view" to the URL for the View tab), when Smart tabs is enabled. Smart tabs needs to do this in order to be able to distinguish a click on the View tab (localhost/[alias]/view) from a click on a normal link to the page (localhost/[alias]).
In the first case Smart tabs should simply go to the clicked View tab, in the second case it should go to the tab that was last active on that page, which may or may not be the View tab (could be the Edit or Revisions or Track tab).

Which reminds me: you must download the latest version of Smart tabs or you may run into trouble when using path_alias_xt.
Rik

#8

Hi Rik,

thanks for making this module. I love it. However, I must agree with the other users that the /vid/view is bothersome.
It first occurred after upgrading to 3.7. Is it really a pathalias problem?

#9

Hi Baris,
Thanks for your support! You are mentioning "/vid/view".... Are you referring to a specific revision (i.e. "node/nid/revisions/vid/view") or are you referring to the "normal/current" revision (i.e. "node/nid" which defaults to "node/nid/view")?
People seem to refer to subtly different issues....
Keep this in mind: the only aliases supported by core is for "node/nid", e.g. "about-us". Core does not support an alias for "node/nid/edit", i.e. you won't see "about-us/edit" UNLESS you use the path_alias_xt module provided earlier in this thread.
Rik

#10

Hi Rik,

I already rolled back to v2.7 (our previous which was working) but my browser history tells me that the urls were formatted as:

http://www.domain.com/node/61/revisions/2214/view

#11

That's consistent with what I mentioned in #9...
You may expect to see http://www.domain.com/about-us/revisions/2214/view -- and it is not unreasonable to expect that. However core does not implement insertion of aliases for the extended paths. You need the path_alias_xt module (attached in comment #4) for that.
So again, the only alias you get for URLs of the form http://www.domain.com/node/61/.... is the base one, i.e. the one for http://www.domain.com/node/61, e.g. http://www.domain.com/about-us.
Nothing to do with Revisioning.

#12

I really don't understand why this should not be unreasonable.
With version 2.7, after a save I get send to the url_alias, say /about-us. With 3.4, after a save I get sent to /node/61/revisions/1221/view

Why should I expect to see about-us/revisions/2214/view instead of about-us if revision 2214 is the latest revision?

#13

Status:needs review» fixed

I have rewritten and improved path_aliax_xt as published in #4 and have created a project for it: Extended Path Aliases.
Please post any further questions there.

#14

Status:fixed» closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.