Closed (fixed)
Project:
Persistent URL
Version:
6.x-1.x-dev
Component:
User interface
Priority:
Critical
Category:
Bug report
Assigned:
Reporter:
Created:
8 Aug 2008 at 16:30 UTC
Updated:
25 Jan 2010 at 12:20 UTC
If I create a group/space called steindemocrats, when I view that space, all of the site's menu items get their path prefixed with steindemocrats/. Since those menu items relate to the top level of the site and none have any relation to the local groups, they need to remain unprefixed. Only the individual features of the space and related nodes should be prefixed.
Comments
Comment #1
sampattuzzi commentedThis is a problem. I'm struggling to find a way back to the main page without doing an absolute path.
Comment #2
avdp commentedHi, this is a problem for me as well.
Would be great if this was possible.
(e.g. the home link in the header-logo should link to the main page, not a og-space)
Comment #3
yhahn commentedThis is high on my list.
There is currently an API for disabling prefix rewriting (read: you need to code) -- you add
$options['purl']['disabled'] = TRUEto the options array for any calls tol()orurl().I will look at adding a checkbox or option in the
admin/build/menuinterface for disabling specific menu items from getting path rewriting.Comment #4
schoeller commentedhi yh,
it would be lovely to have anything of the like "disable URL rewrite" within the menu as an additional functionality in order to have switching of spaces being much easier. I am trying to setup a community site for engineers without borders germany as a non-specialist/volunteer. spaces in combination with features/context is very much the thing I was looking for, but swapping spaces has given me a headache so far. I just do not get my head around it.
anyhow thanks for all this interesting work.
best wishes from germany
sebastian
Comment #5
schoeller commentedDear all,
I have tried to trace back the URL rewrite topic to the database entries within the menu system. I have created a test page with a menu entry. Afterwards I traced the menu entry in the database. There is an options field which has the following entries:
a:1:{s:10:"attributes";a:1:{s:5:"title";s:8:"Testpage";}}I translate this into
a:1 -> array of the length 1
s:10 -> string of the length 10
and so forth.
Thus the entries form an array structure. My question now is whether I can manually add the mentioned
$options['purl']['disabled'] = TRUEto the options field. If so, maybe somebody can tell me how I would do that using a field as seen above.Just trying to make my way.
Best wishes
Sebastian
Comment #6
jmiccolis commentedHi all,
I've resolved this issue as part of purl. A couple of patches submitted yesterday and today added a UI to manipulate the purl=disabled flag in the menu system, as Sebastian identified above. The fixes aren't in a tag yet, but should be soon.
Two UI's are added, one to control behavior menu wide. like this -> http://img.skitch.com/20090626-nbb9y858x6byc51dfixhwdeuef.jpg
One to control rewriting for an individual menu item, like this -> http://img.skitch.com/20090626-ptpygdkr7rqmxukfnw2nnt3w11.jpg
Comment #7
yhahn commentedLies. http://drupal.org/node/503124
Comment #9
MichaelP commentedI have reopened this issue as I have the same problem as 2: How to exclude the home link in the header / logo from a purl rewrite (points to current space "home" rather than site home).
From #3 I understand I could call the Purl API to do this. If someone can point me in the right direction I'll gladly do so?!
Many thanks,
Michael.
Comment #10
yhahn commentedMichaelP: Please read comment #3.
Comment #11
MichaelP commentedThanks for pointing that out Young.
For anyone else as daft as me, to avoid rewriting the logo / front page url, in my template.php file I created the hook_preprocess_page with the following
Comment #13
nicks commentedThanks for this, I had the same problem, and this solved it.
I'm not sure if I should start a new thread for this point, so apologies if this isn't the drupal.org way!
I wonder if there is still a problem because this behaviour is not clear to users, and I ended up opening a new thread because I could not find the solution. I therefore think we could improve the settings or instructions to help users understand this better.
I suspect that for most users of the Spaces module, they will configure the menus so that the PURL context is maintained for the features menu, and disabled for all others. Any other settings will tend to make a site that feels broken, or else would need significant customisation to make them make sense. I would therefore suggest that the defaults for the items in menus be set as I just described:
What do you think?
Comment #14
nicks commentedok - I'm guessing you're not meant to add comments to closed issues, so I've posted this thought as a new issue