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.
Comment | File | Size | Author |
---|---|---|---|
#17 | og_set_language-spaces-conflict-998642-17.patch | 708 bytes | hefox |
#16 | og_set_language-spaces-conflict-998642-16.patch | 943 bytes | hefox |
#10 | og-set_language-998642-10-D6.patch | 890 bytes | christianchristensen |
#2 | locale.png | 16.08 KB | amitaibu |
#1 | og_language.patch | 1.09 KB | catch |
Comments
Comment #1
catchComment #2
amitaibu> Site doesn't have a default language set.
Can this be - how do you not set a language?
Comment #3
catchSorry, a prefix for the default language, I mis-typed.
Comment #4
amitaibuCommitted, thanks.
Comment #6
amitaibuThis actually caused tests not to pass -- we should probably fix the tests.
Comment #7
NaX CreditAttribution: NaX commentedPlease note that this patch could be causing a infinite loop in Spaces OG
See: #457846: Problems with pre created organic groups
Comment #8
Grayside CreditAttribution: Grayside commentedLanguage tests separately fixed. Of course, now #1419530: OG6 Language Tests Failing
Comment #10
christianchristensen CreditAttribution: christianchristensen commented(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 innode/%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 pointog_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)...
Comment #11
praestigiare CreditAttribution: praestigiare commentedTested 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.
Comment #12
blueprint CreditAttribution: blueprint commentedThe 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
Comment #13
blueprint CreditAttribution: blueprint commentedThis bug also applies to version = "6.x-2.3"
The patch in #10 succeeds and works as mentioned in #11 and #12
Comment #14
Grayside CreditAttribution: Grayside commentedIf 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.
Comment #15
infojunkieFor me, this problem appeared using the OG Views argument og_views_handler_argument_og_uid_nid. Patch #10 solved it.
Comment #16
hefox CreditAttribution: hefox commentedConfirming 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.
Comment #17
hefox CreditAttribution: hefox commentedQuick untested patch that just uses arg(
Comment #18
SebCorbin CreditAttribution: SebCorbin commentedMarking #2011742: Access to "Import / Export" tab denied as dependent issue and updating priority
Comment #19
SebCorbin CreditAttribution: SebCorbin commentedApplied #17 in production on https://localize.drupal.org, works flawlessly
Comment #20
joelpittetTriaging 6.x issues