Perhaps this has already been reported; I did not find a match.

Main settings permits the province display to be set to "Display full province name." When this is done, parts of Drupal's administrative UI do not work.

Specifically, on my Acquia-hosted site a "500 Internal Server Error" is returned when one attempts to browse these URLs:

- http://[site-url]/admin/user/settings
- http://[site-url]/admin/content/taxonomy/edit/vocabulary/[vid]
- http://[site-url]/admin/content/taxonomy/add/vocabulary

The Acquia technical support team tracked the first of these down to a piece of PHP code. Here is their technician's comment:

"Okay, so I did some heavy code diving and found the root of the issue, it is in location module. Specifically around line # 1630 in location.module: $form['form']['fields'] = array( '#type' => 'location_settings', '#default_value' => isset($old['form']['fields']) ? $old['form']['fields'] : array(), ); The '#type' is referring to a location_settings field type. This is a custom form element and in the process function for this element loops through all the fields that could be used by user profiles and builds a sorting table. The Province field is causing issues when it is being built. From location_locationapi(): case 'province': drupal_add_js(drupal_get_path('module', 'location') .'/location_autocomplete.js'); $country = $a5['country'] ? $a5['country'] : variable_get('location_default_country', 'us'); return array( '#type' => 'textfield', '#title' => t('State/Province'), '#autocomplete_path' => 'location/autocomplete/'. $country, '#default_value' => variable_get('location_use_province_abbreviation', 1) ? $obj : location_province_name($country, $obj), '#size' => 64, '#maxlength' => 64, '#description' => NULL, // Used by province autocompletion js. '#attributes' => array('class' => 'location_auto_province'), '#required' => ($a4 == 2), ); The particular line is $country = $a5['country'] ? $a5['country'] : variable_get('location_default_country', 'us'); The $a5 param in this case is empty for some reason. I don't know the module well enough to tell you why or if it should be, but that is causing the segfault. The $country value ends up being the array: [10-Oct-2010 17:56:42] Array ( [default] => [collect] => 2 [weight] => -99 ) instead of a string which is expected. It's unclear why this should cause a segfault. My guess is that some code in the form API for building the autocomplete urls doesn't like it. At any rate, there's the issue. I've got to head out right now, I guess the best thing to do is to file an issue in the location module's queue which I can do tomorrow. In the meantime, one of my colleagues may be able to modify the code to not show this field, or perhaps there is a configuration setting to not use it?"

Indeed, when the above option is selected, the referenced parts of my administrative UI are unavailable. As soon as the option is reverted to "Display province/state code.", the administrative UI behaves normally.

IMO this is a serious flaw in the Location module, because it means that one cannot have content displaying the full province/state names. Thus Solr search, in particular, becomes less useful. Etc.

Please advise.

Best regards,

Bob

Comments

hutch’s picture

The line

$country = $a5['country'] ? $a5['country'] : variable_get('location_default_country', 'us');

is different in dev,

$country = $a5['country']['default'] ? $a5['country']['default'] : variable_get('location_default_country', 'us');

Looks like it's fixed in dev as I am not getting admin lockups using dev

Bob Newby’s picture

That's good. Is there a time frame in mind for the next stable release?

hutch’s picture

I am not the maintainer, not my decision.
This morning I had a bit of a dig around and found that in fact $a5['country']['default'] was not delivering the configured country but the old $a5['country'] does. (circa line 647 location.module) I checked this on 3 sites, two using cck location and one using location_node. Using the devel utility dd() revealed that $a5['country']['default'] does not exist at all but strangely delivers only one letter, 'u'. It also revealed that each time I went in to change the settings of the location widget those settings were added recursively, making $a5 larger and larger. This can also be seen in an export of the node-type. All very odd.
The best way to get a location widget to work is to create it, move it into position and configure it and leave it alone thereafter.

Bob Newby’s picture

A note of possible importance to the maintainer...

My site is an international site, and there is no notion of a default country. Therefore, on the location settings page, the default for country is left unspecified.

Might this be one reason that every time I want to access the aforementioned parts of the admin UI, I have to switch the province display from full name to abbreviation? (When I am done with that part of admin usage, I switch it back to full name.)

In any case, this is a real nuisance.

Bob Newby’s picture

When is this going to be addressed?

rooby’s picture

Hutch's post caught my eye here.

The change hutch mentioned came from #846604: warning: trim() expects parameter 1 to be string, array given in sites/all/modules/location/location.inc on line 498., where the use of $a5['country'] was causing other problems (although the problem there are definitely less serious than the ones here).

I'll get to this one soon and find a solution that fixed both issues.

hutch’s picture

What I'm seeing is
$a5['location_settings']['form']['fields']['location_settings']['form']['fields']['location_settings']
So the ['location_settings'] array is being appended to 'fields' rather than overwriting the original set on resave.

As for the country issue as I said earlier $a5['country']['default'] does not exist but
$a5['location_settings']['form']['fields']['country']['default'] does.
I presume that $a5['country'] is the global default but I might be wrong.

I hope you can find the bug ;-)

rooby’s picture

Status:Active» Fixed

Status:Fixed» Closed (fixed)

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

Summit’s picture

Hi, the commit links lead to commitlog and not the specific commits. How do I get to these specific commits?
edit: I found the link myself through looking thriogh the location commits: http://drupalcode.org/project/location.git/commitdiff/82e5c6c

greetings, Martijn

rooby’s picture

@Summit:
This is a widespread problem on drupal.org relating to the move from cvs to git.

There is an issue regarding this at #780342: Handle linkrot from CVS commit browser