Spaces/PURL has an annoying "bug" at the moment (at the very least, unexpected behavior). I recently converted my OG-based site to spaces/features/context. After doing that, I noticed that spaces tend to "drift" to unexpected places. Once a space is set, it stays set until another space takes over or the purl preset is disabled. This is a /good/ thing most of the time (that's what it's designed to do) but in a few contexts it's really annoying namely searching and user pages.

This bug is easy to see on Open Atrium. Go to a user profile page and then click on a link, say to a book page. When you go there, spaces/purl thinks you're still in the user space instead of where you're actually at, a group space where the book page was created.

What I did was add this snipped of code to purl.module

function purl_url_rewrite(&$path, &$options, $original) {
  static $global_elements;
  
  $user_page = strpos($_GET['q'], 'user');
  $search_page = strpos($_GET['q'], 'search');
  ($user_page === false) ? "" : $options['purl']['disabled'] = true;
  ($search_page === false) ? "" : $options['purl']['disabled'] = true;

It'd be nice though if there was an admin page where we could set these variables.

CommentFileSizeAuthor
#28 608916.28-purl-disable-path.patch9.64 KBmrfelton
#27 608916.27-purl-disable-patth.patch9.25 KBmrfelton
#18 purl_608916_20100917.patch11.19 KBdtarc
#15 purl-608916-20100617.patch8.96 KBowen barton
#5 608916_20100423_2.patch11.12 KByhahn
#3 purl-exclude-urls.patch5.71 KBwebflo

Comments

marcushenningsen’s picture

marcushenningsen commented

I'd also like to know if this is intended behaviour, and I'd probably prefer a more generic solution. I'm also not sure if this is related to purl of spaces.

Another very simple example of this annoying behaviour is when trying to reach a page outside a space from within a space. Say our viewing some content inside the group "employees" and want to go to the regular page /contact through a primary menu link, purl automatically renames the url /employees/contact.

Shouldn't purl only rewrite url's within spaces?

Marcus

yhahn’s picture

yhahn commented
Assigned: Unassigned » yhahn
Category: feature » task

Will look into this. I think it's a good idea (to exclude PURL rewriting by path) but I need to figure out how it will work -- a set of paths per provider perhaps?

webflo’s picture

webflo commented
StatusFileSize
new purl-exclude-urls.patch5.71 KB

This patch is a first very raw version. You have to create a new table called purl_rules with 2 colums.

1. mode [type: tinyint (4)]
2. urls [type: text]

With this patch it is possible to excude path from rewriting (like admin/*). This hole path-matching is inspired/copied from block module. Please review and comment. This patch is for DRUPAL-6--1-0-BETA10

kyle_mathews’s picture

kyle_mathews commented

Seems like a reasonable approach. It'd be great to get this in as it's a fairly common source of bugs / inconsistencies. I'll try to find time to test this next week.

yhahn’s picture

yhahn commented
StatusFileSize
new 608916_20100423_2.patch11.12 KB

I've done some work on this patch and refactored it quite a bit.

Summary

  • Switching storage from custom table to a variable. Given that disabled path checking will occur on every page, might as well use a variable.
  • Refactored UI -- you can add pathsets at admin/settings/purl/disabled and determine which providers each applies to granularly.
  • Added a drupal_alter() for purl_disabled_path so providers can programmatically exclude paths.

Would love some testing.

kyle_mathews’s picture

kyle_mathews commented

The patch isn't applying cleanly. What version of PURL is the patch from?

yhahn’s picture

yhahn commented

CVS checkout of DRUPAL-6--1 ?

kyle_mathews’s picture

kyle_mathews commented

Figured it out. Patching noob error. Used patch < file.patch instead of patch -p0 < path/file.patch.

Anyways, it's working as billed! I added users/* and now the purl prefixes are being removed from links to user pages.

Is it possible for the paths to match against the system paths not path aliases? I entered user/* first but that didn't work. I had to use my pathauto aliases instead.

vaartio’s picture

vaartio commented
Version: 6.x-1.0-beta4 » 6.x-1.0-beta11

Why does the latest release (beta11) not include this patch?

yhahn’s picture

yhahn commented

We're still testing and looking for feedback on this feature, as it's quite a significant change (and introduces a slight performance hit).

Let me know if you have some feedback on it!

kyle_mathews’s picture

kyle_mathews commented
Version: 6.x-1.0-beta11 » 6.x-1.0-beta12

Was going to re-roll the patch but it applies cleanly still against beta12.

Also, I've been using this patch in production for the past month without any known problems.

kyle_mathews’s picture

kyle_mathews commented

Another thought -- would it be possible to use Context to disable purl? That'd allow for more sophisticated purl disabling.

penguininja’s picture

penguininja commented

I'm still wrapping my head around PURL+Context, but it seems like having a Context reaction to disable PURL rewriting could add a lot of flexibility. Unfortunately I'm not able to contribute code, but I'd be happy to test and give feedback if this is something that makes sense to pursue.

mxt’s picture

mxt
Primary language Italian
Location Milan
commented

Subscribing

owen barton’s picture

owen barton commented
Status: Active » Needs review
StatusFileSize
new purl-608916-20100617.patch8.96 KB

Reroll of #5

cwaring’s picture

cwaring commented

Subscribing

kyle_mathews’s picture

kyle_mathews commented
Version: 6.x-1.0-beta12 » 6.x-1.0-beta13

Tested this patch and it applies cleanly still to beta13.

Any reason why this hasn't gone in yet? Young, are you thinking about meeting this need in a different way?

dtarc’s picture

dtarc commented
StatusFileSize
new purl_608916_20100917.patch11.19 KB

I couldn't get the patch in #15 to apply cleanly to beta13 (purl_subdomain.inc failed)

I have rerolled that patch in #5 here.

Paths are getting properly excluded, no ill effects so far.

nenad.scekic’s picture

nenad.scekic commented

YES it helps and work like charm that ;)

/admin/build/menu-customize/navigation/edit
Persistant URL behavior:
"Discard" doesn't work

5x clean install with diferent order of setup. but every time when i have instaled og, spaces_og,menu og , purl (path, subdomain...)... when i try /admin/build/context/add or /admin/build/features/create i get redirection loop.

1. I patched purl.
2. /admin/settings/purl/disabled add entry admin/* ()

and now it' working !!!

P.S. is there other way to fix problem with purl beside of patch ?

ukrdrupal’s picture

ukrdrupal commented

...subscribing

...I find this whole issue really annoying, right out of the box. I *had* to install PURL, just to use Spaces, which is required by yet another module. Doesn't make sense to me at all. I already use pathauto, which is very powerful.

I am having a real problem now. I had already set-up the creation of my organic groups to have their names (paths) automatically created, based on the title of the group that the user chooses. Now PURL is totally messing that up and is REQUIRING me to enter another path.

I tried to *uncheck* "Path" from here: admin/settings/purl/types

The little asterisk, which signifies being required goes away on the group's creation page node, but yet it is STILL required! Can someone help?! What am I not getting here?

Thanks!

ukrdrupal’s picture

ukrdrupal commented

I did take the time to watch this great presentation:

http://www.archive.org/details/TheHeartOfOpenAtriumContextPurlAndSpaces_782

I do see the *need* for PURL. ...But how to get everything to play nicely. This is breaking my brain right now. And it does seem that there is a real conflict in play here.

ukrdrupal’s picture

ukrdrupal commented

I have been experimenting with the PURL and the use of the Query String and setting a key. Things seem to go smoother. However, it seems like this PURL is more like a spider web you get caught in, rather than a persistent URL that is beneficial. Once you get in to the PURL of a group, the whole site then takes on this group PURL. I don't like this at all and I think it will not be intuitive for my users one bit. What I need to know is how to get it to work when I want it to work, but have it off 99% of the time. Again, I only installed PURL, because I was *required* to, not because I actually want to use it. Please help.

dtarc’s picture

dtarc commented

According to the Spaces module page PURL is only recommended, not required

owen barton’s picture

owen barton commented

I think ukrdrupal was meaning spaces_og, where purl is indeed required:
http://drupalcode.org/viewvc/drupal/contributions/modules/spaces/spaces_...

ukrdrupal’s picture

ukrdrupal commented

The module that I actually was needing to install was views_gallery, which has a module for og. So, this is where the spaces_og would come in, I think, and then therefore the PURL. Regardless, I think there is a conflict, as described in this thread. I see practical problems, where PURL just takes over the site, once you enter into a group area (space).

designtodigital’s picture

designtodigital commented

I've got this patch from #18 running on a live site. Works great. I highly recommend that this be committed to the main trunk.

mrfelton’s picture

mrfelton commented
StatusFileSize
new 608916.27-purl-disable-patth.patch9.25 KB

Here is the same patch as #18, rerolled to apply cleanly to code in git.

mrfelton’s picture

mrfelton commented
StatusFileSize
new 608916.28-purl-disable-path.patch9.64 KB

Previous patch didn't include the new files. Revised patch attached.

mrfelton’s picture

mrfelton commented

So I gather this thread is about not rewriting the URL on output in certain situations, to help ease the process of switching out of purl context. It seems to be kind of linked to a problem that I'm facing, but not quite as the problem I'm facing is with URL's being written on incoming requests when thy shouldn't be. For example, if a system path happens to contain the purl path prefix in it's path, it becomes impossible to access that url, since the path prefix gets stripped off and you end up getting sent to a non-existant path (the original path minus the purl prefix), resulting in a 404.

Would it make expand the scope of this patch so that you could also disable paths from being rewritten on incoming requests (rewrite_inbound) as well as in rewrite_outbound?

foredoc’s picture

foredoc commented

I have a similar "drift" problem here.

I am using spaces og, and have a block "my groups" enabled. If I try to navigate to another group(B) from current group(A) context by clicking the link in "my groups" block, spaces/purl will still keep me in the group(A) space.

Looks to me that EXCLUDE URL is not the proper solution for my problem.

Any ideas?

Thanks.

foredoc’s picture

foredoc commented

@kyle_mathews, I did not experience the "drift" problem on :

https://community.openatrium.com

Basically, in my user page, when I hover to one issue that I created, the link looks like:

https://community.openatrium.com/node/[nid]

When I click it, it tooks me to:

https://community.openatrium.com/issues/node/[nid]

Any ideas how to accomplish this?

Thanks.

fuzzy76’s picture

fuzzy76 commented
Issue summary: View changes
Status: Needs review » Reviewed & tested by the community

Numerous people have run this in production now, for all intents and purposes this patch has been ready for years.

liquidcms’s picture

liquidcms commented

D7?

liquidcms’s picture

liquidcms commented
Version: 6.x-1.0-beta13 » 7.x-1.x-dev
Assigned: yhahn » Unassigned
Category: Task » Feature request
Status: Reviewed & tested by the community » Active

doesn't seem like this is ever going to be committed to D6 so figured it might be ok to change version over to D7 and see if we can get it done there. i'll likely look at doing up a patch for this in the next couple days.