Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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
Comment | File | Size | Author |
---|---|---|---|
getlocation.jpg | 52.76 KB | L.Bouider |
Comments
Comment #2
hutch CreditAttribution: hutch commentedI 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.
Comment #3
Krilo_89 CreditAttribution: Krilo_89 commentedHi 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.
Comment #4
hutch CreditAttribution: hutch commentedI 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.
Comment #5
hutch CreditAttribution: hutch commentedI 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.
Comment #6
L.Bouider CreditAttribution: L.Bouider commentedHi 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.
Comment #7
hutch CreditAttribution: hutch commentedThe 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.
Comment #10
hutch CreditAttribution: hutch commentedFix 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.
Comment #11
onemorepixel CreditAttribution: onemorepixel commentedHi,
I confirm, getlocations-7.x-2-dev have fixed the issue on Drupal 7.39
No side effect so far.
Thanks
Comment #14
hutch CreditAttribution: hutch commentedMore bugs found, commited.
Comment #15
L.Bouider CreditAttribution: L.Bouider commented2.x-dev , it works for me.
Thank you
Comment #16
L.Bouider CreditAttribution: L.Bouider commentedI'm not sure, but I think that 2.x-dev cause a bug in Views.
All Getlocation fields are disabled in my view.
Comment #17
hutch CreditAttribution: hutch commentedThe 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.
Comment #18
Getekid CreditAttribution: Getekid commented7.x-1.16+37-dev fixed the issue for me as well !!
Thanks a lot!
Comment #19
webservant316 CreditAttribution: webservant316 commentedyep, getlocations-1.x.dev solved the problem for me also.
Comment #20
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedI 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).
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.
Comment #21
hutch CreditAttribution: hutch commentedThe 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.
Comment #22
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedOK, 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