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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

catch’s picture

FileSize
1.09 KB
amitaibu’s picture

FileSize
16.08 KB

> Site doesn't have a default language set.

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

catch’s picture

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

amitaibu’s picture

Status: Needs review » Fixed

Committed, thanks.

Status: Fixed » Closed (fixed)

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

amitaibu’s picture

Status: Closed (fixed) » Needs work

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

NaX’s picture

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

Grayside’s picture

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.

christianchristensen’s picture

Status: Closed (fixed) » Needs review
FileSize
890 bytes

(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)...

praestigiare’s picture

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.

blueprint’s picture

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

blueprint’s picture

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

Grayside’s picture

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.

infojunkie’s picture

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

hefox’s picture

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.

hefox’s picture

Status: Needs work » Needs review
FileSize
708 bytes

Quick untested patch that just uses arg(

SebCorbin’s picture

Priority: Normal » Major

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

SebCorbin’s picture

Status: Needs review » Reviewed & tested by the community

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

joelpittet’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Closed (outdated)

Triaging 6.x issues