We are trying to use purl and spaces to provided a kind of multisite setup. There are 2 taxonomy spaces set up.

One has the purl /cats and the other /dogs.

The end goal is to be able to have two nodes, one in each space:

node/1 accessible at the path /cats/about - which is part of the cats space.
node/2 accessible at the path /dogs/about - which is part of the docs space.

In order to be able to do this you would need to be able to assign both nodes to the url alias /about, since spaces and purl deal with automatically redirecting to (and prepending) /cats or /dogs. However, its impossible to create 2 url aliases that are the same. Right now, all I can do is have /cats/about and /dogs/about2. Obviously, thats no good.

If I give the nodes the aliases /cats/about and /dogs/about then after purl/spaces has prepended the purl prefix to the path, the path becomes /cats/cats/about and /dogs/dogs/about. Again, no good.

So, it seems that either I'm missing something, or we need the ability to tell purl/spaces to ignore parts of a url alias if they match the purl path - activating the space, but not prepending the purl to the path, since its already there as part of the alias.

Comments

heacu’s picture

heacu commented

+1

this could also be an argument for using Spaces without PURL. if some property of a node or set of nodes (say, which group they belong to) determines a "space", then why not use that property to trigger behaviors? why is a PURL prefix required? you might wish all CAT group nodes to have the CAT prefix **whether or not** they have their own space. why a conceptual approach like spaces relies on the physicality of URL prefixes is not clear to me.

domidc’s picture

domidc commented

How does a product like open atrium or openscholar solve this?

domidc’s picture

domidc commented

Is there any progress on this issue?

domidc’s picture

domidc commented

Maybe storing an alias per space in a custom table and then have purl take advantage of that...

domidc’s picture

domidc commented

A workaround would be to define a replacement token to generate aliasses. You would get an alias [purl]/[node-title]. Then both paths [purl]/[purl]/[node-title] and [purl]/[node-title] are working. In the latter one you will get redirected to [purl]/[purl]/[node-title].

Due to the fact that purl comes in before aliases are created it is impossible to have the correct paths rewritten in url_outbound_alter since this is only settings a [purl] as #prefix used in the url option array. Without seriously hacking the core alias system you wont be able to rewrite the outcome of the url alias.

Yet another possibility but with also core hacking implications is:
Alllow entities to have multiple aliases stored depending on the active spaces. For example og spaces could hook into the node saving process, alter forms and allow you to store an alias per group space. So cats/about would get an alias record in the custom alias table: spaces_og_alias: entity_id|gid|alias -> 1|1|about.

So if you would go to cats/about then purl will rewrite the url to about, then the alias wil be translated to node/1 using the info in the table. Again core hacking required. To generate the urls in outboundalter. Purl gets node/1 will create [purl]/node/1 and then this will be send to the aliasing using the stored info will create the paths [purl]/about. Again core hacking required to make aliases listen to spaces.

Perhaps we could make this a core feature request that aliases should be allowed?