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

sampattuzzi’s picture

Version: » 6.x-1.0-alpha4

This is a problem. I'm struggling to find a way back to the main page without doing an absolute path.

avdp’s picture

Hi, 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)

yhahn’s picture

Assigned: Unassigned » yhahn
Priority: Normal » Critical

This is high on my list.

There is currently an API for disabling prefix rewriting (read: you need to code) -- you add $options['purl']['disabled'] = TRUE to the options array for any calls to l() or url().

I will look at adding a checkbox or option in the admin/build/menu interface for disabling specific menu items from getting path rewriting.

schoeller’s picture

hi 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

schoeller’s picture

Dear 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'] = TRUE to 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

jmiccolis’s picture

Project: Spaces » Persistent URL
Version: 6.x-1.0-alpha4 » 6.x-1.x-dev
Component: Code » User interface
Status: Active » Fixed

Hi 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

yhahn’s picture

The fixes aren't in a tag yet, but should be soon.

Lies. http://drupal.org/node/503124

Status: Fixed » Closed (fixed)

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

MichaelP’s picture

Status: Closed (fixed) » Active

I 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.

yhahn’s picture

Status: Active » Fixed

MichaelP: Please read comment #3.

MichaelP’s picture

Thanks 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

function mytemplate_preprocess_page(&$vars){
 // Avoid purl rewrite of <front>
 $vars['front_page'] = url(null, array('purl' => array('disabled' => TRUE),)); 
}

Status: Fixed » Closed (fixed)

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

nicks’s picture

Thanks 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:

  • Features: PURL > maintain
  • Other menus: PURL > discard

What do you think?

nicks’s picture

ok - I'm guessing you're not meant to add comments to closed issues, so I've posted this thought as a new issue