Ran into this issue:

Site doesn't have a default language set.

Node is posted to one or more groups. The node is in the default language, but the first group it's posted in is in a different language.

When browsing directly to the node, og will set the language to the language of the group, meaning you can end up with a node posted in five English groups, one French group - but due to lack of en prefix and the French group being first, the UI will change to French. On this particular site there's no other indication of the group context, so this was being brought up as a bug by users.

Attached a patch for this, I think it wouldn't interfere too much with other use cases too much. Haven't tested this yet.

Files: 
CommentFileSizeAuthor
#17 og_set_language-spaces-conflict-998642-17.patch708 byteshefox
PASSED: [[SimpleTest]]: [MySQL] 269 pass(es).
[ View ]
#16 og_set_language-spaces-conflict-998642-16.patch943 byteshefox
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch og_set_language-spaces-conflict-998642-16.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#10 og-set_language-998642-10-D6.patch890 byteschristianchristensen
PASSED: [[SimpleTest]]: [MySQL] 269 pass(es).
[ View ]
#2 locale.png16.08 KBAmitaibu
#1 og_language.patch1.09 KBcatch
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch og_language.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Comments

StatusFileSize
new1.09 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch og_language.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

StatusFileSize
new16.08 KB

> Site doesn't have a default language set.

Can this be - how do you not set a language?

Sorry, a prefix for the default language, I mis-typed.

Status:Needs review» Fixed

Committed, thanks.

Status:Fixed» Closed (fixed)

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

Status:Closed (fixed)» Needs work

This actually caused tests not to pass -- we should probably fix the tests.

Please note that this patch could be causing a infinite loop in Spaces OG
See: #457846: Problems with pre created organic groups

Status:Needs work» Fixed

Language tests separately fixed. Of course, now #1419530: OG6 Language Tests Failing

Status:Fixed» Closed (fixed)

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

Status:Closed (fixed)» Needs review
StatusFileSize
new890 bytes
PASSED: [[SimpleTest]]: [MySQL] 269 pass(es).
[ View ]

(Sorry to re-open)

When testing this upgrade with Spaces (specifically spaces_og) the $current_node = menu_get_object(); seemed to break the access callback in node/%node/features. I believe this could be a race condition of sorts to how early a spaces is assigned and then statically cached; my guess is that at the point og_set_group_context is called there is not a space and the menu access checks are triggered and statically cached (in the %node/features case prior to having a space to check access against).

I will try to dive a little more into the spaces_og side to see if this is unavoidable, but I have another option here to look at the node id path itself, rather than the path assumed on the page (please see attached)...

Tested the patch in #10. It is necessary for sites running Open Atrium on Drupal 6. While spaces_access_features will seem to work correctly due to the fallback for non-spaces features which uses variable_get(), without this patch all calls to spaces_get_space() in a menu access function will return false.

The patch in #10 works for me an also addresses:

Open atrium issues as mentioned in #11

https://community.openatrium.com/node/4063
https://community.openatrium.com/node/4038#comment-9322

Both of these issues (very odd) go away with the patch in #10

Version:6.x-2.x-dev» 6.x-2.3

This bug also applies to version = "6.x-2.3"

The patch in #10 succeeds and works as mentioned in #11 and #12

Version:6.x-2.3» 6.x-2.4
Status:Needs review» Needs work

If the problem is a bug with node/%/features, we should limit the overhead to just that page. If it is just that one path, we should consider whether Spaces OG should correct this...

Has anyone tested to see if the language test passes? It must be run locally because of a problem with the testbot & Locale module on D6.

For me, this problem appeared using the OG Views argument og_views_handler_argument_og_uid_nid. Patch #10 solved it.

StatusFileSize
new943 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch og_set_language-spaces-conflict-998642-16.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Confirming this breaks spaces_og

Here's a patch that just removes it for now while a better solution can be created.

IMO Do NOT call menu_get_item at all; can't clear that cache and it can be called quite early during init. Just a mess.

Status:Needs work» Needs review
StatusFileSize
new708 bytes
PASSED: [[SimpleTest]]: [MySQL] 269 pass(es).
[ View ]

Quick untested patch that just uses arg(

Priority:Normal» Major

Marking #2011742: Access to "Import / Export" tab denied as dependent issue and updating priority

Status:Needs review» Reviewed & tested by the community

Applied #17 in production on https://localize.drupal.org, works flawlessly