Hi,

To add a map to a node, I'm using Getlocation fields with Geocoder widget. however , since the last update of Drupal, I don't know why The map is not displaying on the edit form of the node. also , the search box does'nt work
How can I fix this ?

Ps: Screenshot is attached

CommentFileSizeAuthor
getlocation.jpg52.76 KBL.Bouider
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

L.Bouider created an issue.

hutch’s picture

I did see this on one site but not on any of the others that I was updating at the same time, quite why I don't know.
I suspect that the others were fixed by running cron or flushing cache, but the one site was fixed by going into the content type edit page (which also displayed a blank map, nothing in the logs and no js errors) and just saving it, that brought the map back, both on the content type edit page and the node edit page.
So try running cron and if that does not fix it try flushing the cache and if that fails to fix it edit the content type page.

Krilo_89’s picture

Hi L.Bouider,

Did you update Drupal to 7.39? On the releasenotes they have some known issues with the autocomplete:
https://www.drupal.org/drupal-7.39-release-notes

I think the geolocations module needs an update to work with the new autocomplete requirements. I disabled the autocomplete for City's and now I can edit any node like before.

hutch’s picture

I can confirm that city_autocomplete is not working so probably also provinces and country. Very annoying, yet again no consideration to backward compatibility. I am looking into it.
If anyone has any insights please let me know.

hutch’s picture

I have posted a request for help with this issue/bug on the drupal core issue queue, no responses yet.
Meanwhile I will explore using jquery.ui.autocomplete instead.

L.Bouider’s picture

Hi guys,

Thank you for replying so quickly.
I tried some tricks , like disabling the modules that can cause this bug, but I haven't had any results.
Finaly, I returned to Drupal 7.38, and the problem was solved. So, I can confirm that the bug is generated by the new version of Drupal Core.

hutch’s picture

The bug is generated as a result of a change in the way core handles forms, they will not change that I'm sure so I will have to change Getlocations, fortunately this has turned out to be doable so I will have a fix commited tomorrow.

  • hutch committed 37b273e on 7.x-2.x
    fixed drupal update bug #2556379
    

  • hutch committed 05b314d on 7.x-1.x
    fixed drupal update bug #2556379
    
hutch’s picture

Fix commited to Getlocations-1.x-dev and 2.x-dev
The fix works with old (< 7.39) and new (7.39) drupal core.
Anyone following this thread please test and confirm that the Getlocations_fields form is working as before.
The changes I have made affect the way jquery distributes geocoding results, instead of identifying each textfield with a "id" ("#") I had to make them into classes (".") as the new Drupal will only tolerate one id per element which although it is common practice is not AFAICT actual HTML5 spec.

onemorepixel’s picture

Hi,
I confirm, getlocations-7.x-2-dev have fixed the issue on Drupal 7.39
No side effect so far.

Thanks

  • hutch committed fbb2270 on 7.x-1.x
    more fixes for #2556379
    

  • hutch committed e5b54cc on 7.x-2.x
    more fixes for #2556379
    
hutch’s picture

More bugs found, commited.

L.Bouider’s picture

2.x-dev , it works for me.

Thank you

L.Bouider’s picture

I'm not sure, but I think that 2.x-dev cause a bug in Views.
All Getlocation fields are disabled in my view.

hutch’s picture

The only thing affected by this issue is the input form for getlocations_fields where an autocomplete has been set on city, province or country.
I have checked two test sites running 2.x and Views is working the same as before.

Getekid’s picture

7.x-1.16+37-dev fixed the issue for me as well !!

Thanks a lot!

webservant316’s picture

yep, getlocations-1.x.dev solved the problem for me also.

David_Rothstein’s picture

-      $form[$field]['#attributes'] = array('id' => 'getlocations_' . $field . '_' . $mapid);
+      $form[$field]['#attributes'] = array('class' => array('getlocations_' . $field . '_' . $mapid));

I am not positive, but I'm guessing that if you want to keep using IDs, you could fix the whole thing by changing the above to set $form[$field]['#id'] rather than $form[$field]['#attributes']['id'] (and then none of the other changes in the patch would have been needed). That's the official way to set IDs in the form API (see also my comment at #2581921-4: user/autocomplete not working).

Very annoying, yet again no consideration to backward compatibility.

This is a hurtful comment. We put a lot of effort into backwards compatibility, but security releases do need to happen and sometimes they break things. In this case, we did not think about the impact on people using ['#attributes']['id'] rather than '#id', but as mentioned above, it's not the correct/supported way to use the form API anyway.

I am going to update https://www.drupal.org/drupal-7.39-release-notes now to list this module as one of the modules affected by the update, and to mention the #id vs ['#attributes']['id'] issue in general.

hutch’s picture

The change in policy re form element ids introduced in Drupal-7.39 did cause me some ructions with customers breathing down my neck to fix something that was not of my making, however I do accept that this was an inadvertant side-effect of a change made to address other issues altogether and not a lack of consideration for backward compatibility within Drupal 7.

Perhaps a note on the "#attributes" entry on the Form API reference page making it clear that css ids should not be set there would help ensure that this does not happen again.

As far as my own modules go, using classes is fine, the Views module uses classes as unique identifiers so I'm not alone and the changes to jquery were easy enough to implement.

I would not want to mess with "#id" as many of my forms are reused in different contexts or appear more than once on the same page as in multiple maps so letting Drupal handle the ids is far better, it does it well although I cannot predict what they will be so cannot write code to address them, hence the need for my own unique identifiers.

@David_Rothstein, thank you for addressing this issue.

David_Rothstein’s picture

OK, thanks. I agree with your suggestion about improving the #attributes documentation on the Form API reference page, so I created an issue for that here: #2582869: #attributes example in the form API reference should give clearer examples, including examples of when not to use it