Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The Style options OpenLayers Data views allow to choose several Map Sources at once (like Lat/Lon point and WTK at the same time), but it then misses the fields specify where this data should come from.
As discussed during the Documentation sprint in Copenhagen: this should probably be radio buttons instead, with the description text referring not referring to sources in plural either.
Comment | File | Size | Author |
---|---|---|---|
#3 | data_source_value.patch | 853 bytes | strk |
Comments
Comment #1
zzolo CreditAttribution: zzolo commentedThanks for the notification on this. I think the original idea was to support multiple data sources in one data overlay, but interface-wise and code-wise, it does not seem like it would be worth the trouble, since it has not been a requested feature or even noticed until now.
Comment #2
tmcw CreditAttribution: tmcw commentedFixed: http://drupal.org/cvs?commit=416648
Comment #3
strk CreditAttribution: strk commentedIn commit 416648 you changed too much code, it seems. Even if non-multiple the checkbox values retain the structure they had before, that is "key" => "key" when selected. At least this is what happens here.
Did you try re-saving an old view recently ?
The attached patch fixes the problem for me (one line).
Comment #4
strk CreditAttribution: strk commentedAfter updating the "data" display style (engine icon) and "save" ing the view again, code in HEAD is fine to handle it, while my patch clearly isn't. So no problem with HEAD except some care is required for upgrade paths.
Comment #5
zzolo CreditAttribution: zzolo commentedIt sounds like this should be reviewed for upgrade path? I'll try to check out tonight.
Comment #7
zzolo CreditAttribution: zzolo commentedGood catch, @strk. Included groups as well and committed:
http://drupal.org/cvs?commit=420186
Comment #8
tmcw CreditAttribution: tmcw commentedWait, why is this being addressed with backwards compatibility rather than an update hook? Wouldn't the latter be a better long-term solution?
Comment #9
tmcw CreditAttribution: tmcw commentedIn fact, the approach taken here has broken openlayers data views for alpha 9. zzolo: revert, fix, re-release.
Comment #10
tmcw CreditAttribution: tmcw commentedReverted: http://drupal.org/cvs?commit=420440
Comment #11
zzolo CreditAttribution: zzolo commentedI totally agree that this was not the most ideal solution, and that an update would be more appropriate, but due to the the complexity of the update, I figured this would be a little more stable fix. An update function can be addressed for next release.
As for now, I have put in a fix that addresses new code and is backwards compatible. Just wanted to get a new release out before people started upgrading. I know it is not ideal.
My apologies for not testing as best as I could. @tmcw, your code did not address people upgrading, and I thought @strk's patch addressed the new code.
Keeping open for update functionality.
Comment #12
zzolo CreditAttribution: zzolo commentedSo, an update hook would not address any Views that are in code, which means we would still need to have the backwards compatible code. Also, this is kind of low priority. I am gonna close, but if anyone wants to work on the upgrade path, please go re-open as needed.