The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.On my localhost on the settings page admin/structure/openlayers I keep getting the Javascript error "Error making request to server."
This wasn't happening before. I used variations of the following in the OpenLayers Source:
- http://openlayers.org/api/2.11/OpenLayers.js
- http://openlayers.org/api/OpenLayers.js
- http://localhost/sites/all/libraries/openlayers/OpenLayers.js
- sites/all/libraries/openlayers/OpenLayers.js
- sites/all/libraries/openlayers/lib/OpenLayers.js
Nothing seems to get rid of the error. All of these are 2.11 versions, though I wonder if there's been some change since a 2.12RC is now out.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | openlayers-non_clean_url_version_check-1533546-5.patch | 680 bytes | friedjoff |
Comments
Comment #1
zzolo commentedHi @mgifford. Just a formality, please default to "support request" unless a bug has been identified already.
More information is needed here. In Chrome or Firefox, there are network tools which should help you locate what file is giving that error.
Comment #2
mgiffordMaybe on the support request. Certainly since it hasn't been verified as a bug with the coding.
This was with Firefox. Don't think it was a network thing either as the maps were working fine, just the Javascript on the config page was reporting an error.
You can actually see it here - http://drupal.org/node/1481374 - as I was running into it when editing the D7 docs.
I was able to replicate the error (which is only visible after saving it) with the dev version specified on the Mac with FF, Chrome, Opera & Safari.
Again, it's the Javascript tool which is aiming to verify that it's 2.11
Comment #3
ranelpadon commentedMost likely it is a "Clean URL" issue.
I've experienced the same problem, but found the solution here:
http://drupal.org/node/1375156
and a related problem and solution also:
http://drupal.org/node/1333134
Comment #4
ranelpadon commentedComment #5
friedjoff commentedThis is indeed a "Clean URL" issue. I think it's save to always include the "?q=" url part (see attached patch).
Comment #6
mgiffordSeems like a simple enough patch. Applies nicely.
Comment #7
polCommitted, thanks.