LANGUAGE_NEGOTIATION_NONE error notice

I commented out the following line and the error message disappeared. Not sure if that is the proper fix, but thought I'd share.

// $mode = variable_get('language_negotiation', LANGUAGE_NEGOTIATION_NONE);

subscribe

That will remove the notice but is by no mean a solution.

I suppose that author just made a typo wanting to put there LANGUAGE_NEGOTIATION_DEFAULT as that would serve if we had some problems with getting variable language_negotiation, so I suggest changing NONE to DEFAULT or make line 152 of /sites/all/modules/fb/fb_url_rewrite.inc look like this:

  $mode = variable_get('language_negotiation', LANGUAGE_NEGOTIATION_DEFAULT);

Sure, this also removes Notice:... but is it what author wanted?

Maintainters, please respond ASAP to issues like this as this radically breaks a site.

This line of code comes from a fix in the 6.x branch that was recently merged into 7.x, and I guess LANGUAGE_NEGOTIATION_NONE disappeared between 6.x and 7.x.

I find it hard to imagine a notice radically breaking a site. Your live website should probably not display php notices. They are usually harmless. And I think modules/fb for 7.x has a handful of php notices that need fixing.

What would be helpful is if someone could find some issue or documentation on d.o that mentions LANGUAGE_NEGOTIATION_NONE, why it was removed in D7 and how to upgrade modules that use it.

Following suggested change in line 152 (#4) only changed the error notice. It did not remove it.

The language_negotiation_get function wasn't removed in D7.

http://api.drupal.org/api/drupal/includes--language.inc/function/languag...

sub'n

@jns

Following suggested change in line 152 (#4) only changed the error notice. It did not remove it

I can't reproduce your quote. Changing

$mode = variable_get('language_negotiation', LANGUAGE_NEGOTIATION_NONE);

to

$mode = variable_get('language_negotiation', LANGUAGE_NEGOTIATION_DEFAULT);

is def the right step, follows the api correctly and makes the error notice dissapear. (here under d7.4 with latest fb dev shot)

All it needs is a (co-)maintainter putting this little change in the next dev for now. That's it.

is def the right step

How do you know for def?

In D6 both constants LANGUAGE_NEGOTIATION_NONE and LANGUAGE_NEGOTIATION_DEFAULT exist. In D7, the latter goes away. Has anyone found any documentation or reason why it was removed?

subscribe

see also http://drupal.org/node/1060908

I don't know enough about it but it has to do with URL rewriting and those two constants are no longer in D7

#9:

LANGUAGE_NEGOTIATION_DEFAULT exists in D7. LANGUAGE_NEGOTIATION_NONE is gone.

http://api.drupal.org/api/drupal/includes--language.inc/constant/LANGUAG...

I made it correct by just replacing LANGUAGE_NEGOTIATION_NONE with 'LANGUAGE_NEGOTIATION_DEFAULT'.
Two changes
1. DEFAULT instead of NONE
2. write in single quotes i.e., ' '

I'm not convinced any of this is needed in D7. Does anyone out there have a site that actually uses language prefixes?

Subscribing. Still present in latest dev (2011-Jul-18).

Patch #13 totally hoses url_aliases.

I don't have time to look into it in depth yet, but I am sure the last snippet of code that was removed should stay in, with $path_language = NULL;

 $alias = drupal_lookup_path('source', $path, $path_language);
    if ($alias)
      $path = $alias;

@Dave Cohen, you really like this C-style control structure without curly braces, any reason for not hewing to Drupal coding standards?

totally hoses

That helps.

I don't pretend to understand the language stuff in Drupal. At the moment I'm fortunate enough to not be supporting any multi-language facebook apps. In both D6 and D7 big changes were made to core and its hard to keep up. I'm counting on patches tested by the community to make it work.

My understanding in D7 is that url alters are a hook, so the language modules can do their own thing and modules/fb should not have to do it for them. Thats why I tried to take out all the language code.

@Dave Cohen, you really like this C-style control structure without curly braces, any reason for not hewing to Drupal coding standards?

You're welcome to submit a new issue, with a patch.

Sorry, didn't mean to sound snarky, and you are probably right that "totally hoses" is not the best idiom. At any rate, I am no expert on i18n either, but it seems that the url rewriting schemes are the same while the underlying API has changed. Until someone with a need for this on D7 comes forward, with some example scenario, then I think the majority of the patch from #13 is appropriate, ie, just remove the bulk of the code related to i18n. Attached a revised patch that leaves the last bit of the conditional, so that url_aliases are fetched and processed.

+1

Here is an updated version for the 7/31/2011 dev release of the FB module.

Hi all
i ve got the same notice but changing NONE to DEFAULT
has produced the error twice:
**** Notice: Use of undefined constant LANGUAGE_NEGOTIATION_DEFAULT - assumed 'LANGUAGE_NEGOTIATION_DEFAULT' in fb_url_inbound_alter() (line 152 of /..../sites/all/modules/fb/fb_url_rewrite.inc).
****Notice: Use of undefined constant LANGUAGE_NEGOTIATION_DEFAULT - assumed 'LANGUAGE_NEGOTIATION_DEFAULT' in fb_url_inbound_alter() (line 152 of /..../sites/all/modules/fb/fb_url_rewrite.inc).
Commented the line:
// $mode = variable_get('language_negotiation', LANGUAGE_NEGOTIATION_DEFAULT);

but here is the persistent message that can not stop emerging everywhere even in the client interface:

****fbconnect module is already enabled, choose the fbconnect module in the facebook stream settings page

This patch is against the master (as of 8/30/2011) and fixes #20 as well.

Joe

So what is the final decision? Just comment it out?

It would be nice to hear whether patch #21 works. I'm testing with it, but don't have multiple languages set up.

Works for me - but I'm not using multiple languages either.

Hmm..that patch doesn't seem to play nice with path aliases, as it specifically undoes any path un-aliasing done further up the stack.

This hook is supposed to be the 'opposite' of what happens in hook_url_outbound_alter, which it currently isn't, as it has all the language stuff in it. In theory you can ignore all that and just focus on your little bit of the path.

I've attached a patch that does just that, and works for me. I've not got it set up with language stuff, but that won't actually play nice with anyone's path re-writing at the moment anyway, so you can't fully test it out. In theory, you shouldn't have to care about what other modules (including language) are doing, so we shouldn't need to have any language code in our function.

patch #25 tested and appears good, with path aliases enabled and used.

sub

sub

+1

Checked it in. Glad to be rid of the language code. Thanks guys!

I do wonder, with the new facebook oauth implementation... maybe the url rewriting can be removed entirely. In the past it was needed because sometimes canvas pages gave no indication that they were a canvas page request. If there is now always a signed request, and if that signed request always identifies which app, this url rewriting hack can be avoided. I just haven't had time to look into that (and unclear whether I ever will).

Hmmm... url rewrite is broken. I'm not sure if the patch above was bad, or I applied it badly (I may have had other changes already there). Anyway I'm trying to repair url altering again.

Hey Dave, now that canvas pages are deprecated in favor of iframe apps, do we need rewriting at all?

Language detection can be handled by i18n.

Marking this as fixed because I've just pushed my latest fb_url_rewrite.inc live. The previous patch had bugs, don't bother applying it. Instead, test the latest .dev release. If you find it is broken, please submit another issue. The LANGUAGE_NEGOTIATION_NONE is fixed. (the question is whether anything else is broken in the process.)

In the current release, canvas pages and page tabs need the url rewriting (just facebook connect, you don't need it). It is possible with the latest oauth changes from facebook that maybe we could do without rewriting. That would be nice, but I'm not certain everything will work. I think that's something for a 4.0 release...