Allow override of PURL excluded_paths

Bumping the priority of this one. I'm not sure I like using a variable to store this stuff, but I can see the need to have a way to change these paths.

So, I took another look here and currently to do this by extending a Space type class, and altering the registry.

For example you could extend `space_og` and then implement `hook_spaces_registry_alter()` to have all OG spaces use your class and not the default one.

Does that work for you?

It is very nice on a development server to be able to disable this for "admin" when developing views. This allows us to test a view in preview while inside a space. It is a little weird but works. Essentially we comment out the line with "admin" and then go to {url}/{purl}/admin/build/views/edit/{viewname}

I'd also find this very useful if we could add additional paths like the payment processor and ajax callbacks that tend to break within spaces. Variables seem like a good way to do this as it will probably need to be fairly variable.

subscribe - this is invaluable for debugging/working with views in spaces!

Invisible variables are a bit meh. This should likely have a settings page. However, the information would likely be stored in a string instead of an array in that case unless the submission is handled custom (ie not using system_settings_form).

static $paths;
if (!isset($paths)) {
  $paths = explode("\n", variable_get ... );
}
return $paths;

Other than that, agree that it would be a useful functionality for features to have out of the box; I can think of a few paths I'd want to exclude.

edit: I disagree with myself; whatever the setting form is, as long as it doesn't use system_settings_form, it can do the explode then variable_set there. screw exploding on each check.

drupal_match_path() will process a string a la block visibility paths with no explosions anywhere.

Also, I'm not sure if you should allow anyone to remove the existing blacklisted paths. Those should perhaps be added to whatever the variable contains.

Someone expressed the desire to remove /admin temporarily; it seems with enough warning that it is desired

Maybe control over the cooked in paths should be done via separate UI, such as checkboxes. That way you can provide the option, but not risk a misclick delete creating unexpected behaviors.

I like having the overrides in settings personally. that way they can be version controlled :)

Attached file is more or less a reroll of #9, except now it expects newline delimited paths as standard output from excluded_paths().

I was looking at how to provide a UI, and I'm thinking this should go somewhere around admin/build/spaces. This seems like a confusing and therefore dangerous setting to expose at /features. As there is no facility for spaces type plugins to introduce configuration, I stopped there. And added #1327092: Add a Spaces configuration page for non-preset related settings.

Attached is a re-roll of #19 against 6.x-3.3, integrated with the patch from http://drupal.org/node/933634#comment-5412508. The reason I integrated these two patches is that the issues are related and touch the same lines of code.

In the above patch, I overlooked the incompatibility between the patch from issue #933634 and the change in #19 to a string with newline separators. That change is also incompatible with class space_og, so this patch changes the return from excluded_paths back to an array.

Is there any reason to dont allow "admin" path's on a space? Or why we should not simply remove "admin" and "admin/*" from the returned array?

Regards