Nodes posted outside of groups have an incorrect path alias

URL aliases are unrelated to node access, so there's no reason content that's not visible to all users on a site shouldn't have a path alias.

Retitling to reflect that this happens with most nodes posted outside of a group, since this is a result of no value for [group-title] in a default path alias pattern equivalent to [groups]/[group-title]/[node-title] .

How should this be fixed? Currently the node gets an alias like "groups/node-title" -- seems a little wrong, but not terrible. So perhaps not a bug?

To fix, how about we add a submit handler to the theme's template.php in commons_origins_form_alter. In that handler, check if the group isset, and if if not change the alias to some thing like "site/node-title"

Ideally (and in my project), I would like to force certain role'd users to submit within a group context. Only project staff/admins can post without a group context, i.e. to a site/* alias.

To fix, how about we add a submit handler to the theme's template.php in commons_origins_form_alter. In that handler, check if the group isset, and if if not change the alias to some thing like "site/node-title"

This would be problematic because we'd be breaking the breaking the separation between the theme and module layers. In this case, a key aspect of the functionality (settings for a path alias) would change when a different theme is active.

Looks like we'll need to triage for a solid solution here.

That sounds good. There are several things (almost everything?) in the commons_origin theme's template.php that need to be copied over/modified to a custom theme's template.php, so it would be good to handle those as well.

Has anyone on the committers/Acquia dev team tried to create a custom theme? i.e. one that was not based on commons_origins. I can give you the one I am doing with with bootstrap, if you like.

I believe major is a more appropriate priority since this can create confusing aliases (non-group nodes end up with the group path alias pattern).

There are several things (almost everything?) in the commons_origin theme's template.php that need to be copied over/modified to a custom theme's template.php, so it would be good to handle those as well.

In general, that code is responsible for presentational changes, rather than functional ones. If you'd like to discuss further, let's do so in a separate issue so that this one can remain focused :).

It is not just private posts. There is nothing forcing users to post to a group, right? I am using the global/common space as a place where more privileged users can post instances of some of the commons content types at the global level.

But, yes, if is a private post your suggestion makes sense. I would like to do away with the leading commons/ . Wouldn't make sense to just use: users/(username-alias)/feed/(node-alias) ? Or if there is a need to get out of the user context, perhaps: private/users/(username-alias)/feed/(node-alias) ?

Is this still a bug? It seems users are forced to either post to a group or to trusted contacts. Is that correct?

@@ -20,6 +20,32 @@ function commons_trusted_contacts_system_info_alter(&$info, $file, $type) {
+    $alias = token_replace('users/[node:og-user-group-ref:0:name]/feed/[node:title]', $context['data'], array(

This looks like a good approach overall, but the pattern here needs work:.

- users/ is currently reserved for user accounts.
- if the node's audience changes so that it no longer is posted to trusted contacts, having 'users' in the path alias is even less appropriate.
- What's the motivation for adding 'feed' to the path alias? Perhaps I'm missing some context here.

How about just content/[node title]?

japerry and I discussed in IRC and suggested that for content posted to trusted contacts, we could use an alias such as /people/jeff-noyes/trusted-content/[node title].

However, with such a pattern we need to make sure to both change the path alias when a node is updated and goes from being posted to trusted contacts to being posted to specific groups, and vice versa. We also need to provide a 301 redirect from the old alias to the new one, while ensuring that we don't write a combination of aliases that will result in an infinite redirect loop after a node is updated in this fashion multiple times.

I tested with these steps:

1) Create a post to trusted contacts. Path alias: users/lisa-rex/trusted-content/test-123
2) Update post to be in the Engineering group. Path alias: groups/engineering-team/test-123
3) Visit original path alias from #1. Am successfully redirected to the alias from #2.
4) Edit post and send it *back* to trusted contacts. Visit path alias from #2. Get redirected to the alias from #1, but get the "Oops, looks like this request tried to create an infinite loop. We do not allow such things here. We are a professional website!" error.

This is definitely an edge case set of steps and the underlying problem is likely to be in Redirect module. However, the patches from comment #13 included code intended to work around these issues. Leaving at "needs review" and discussing with japerry.

In #14 I was missing the Commons_Misc patch from #13. However, with the patch applied I went through this cycle of path aliases.

http://localhost/acquia/commons-builds/latest-9/users/lisa-rex/trusted-c...
http://localhost/acquia/commons-builds/latest-9/groups/engineering-team/...
http://localhost/acquia/commons-builds/latest-9/users/lisa-rex/trusted-c...

Now, the current alias is http://localhost/acquia/commons-builds/latest-9/users/lisa-rex/trusted-c... but even visiting the current alias shows the Redirect "Professional website" error.

The behavior in #14 is edge case enough and preferable that of #15, so I've committed only the patch to Commons Trusted Contacts: http://drupalcode.org/project/commons_trusted_contacts.git/commit/174201a.

Let's tackle the larger Redirect edge case in a followup issue.