skirridsystems

How about a leading + in the layers list to indicate that it should remain open?

layers=”+Civil Parish|-Ecclesiastical Parish|-School Catchment”

or perversely

layers=”+-Civil Parish|Ecclesiastical Parish|-School Catchment”

The per-item – sign indicates that item is not initially checked, the overall leading + indicates that the list stays expanded.

hover=0 will turn off and hover=1 will turn on that option on a per-map basis.

I’ll update the documentation!

Brilliant, thanks.

One minor point, the label above the box still says ‘Username’. It would be better as ‘Username or Email Address’ like the WP login box.

Interesting. That’s the same reason that maps don’t work in popups – they get ‘drawn’ while the popup is invisible and then when the CSS is changed to ‘display’ it shows a map with only one tile drawn.

It’s on my todo list to find a solution, but it’s a pain as it involves detecting when the map has changed without forcing unnecessary invalidates.

Strange. I have tried in Chrome, Firefox and Edge and I can’t reproduce the problem. My monitor is 1920×1080. I’ve tried with the browser window maximised and also with smaller and greater (over 2 monitors) window widths and refreshed the view but I never see anything missing.

Sorry, didn’t manage to get this into 1.3. I’ve done a fairly major restructure of the JS generator and didn’t want to change too much in one go! But I haven’t forgotten.

The temporary fix is now included in the official 1.3 release.

Add in release 1.3.0

@andrewkazalia I may have a workaround for this. If you can contact me via the email on the plugin website then I can send you a test version to try.

@dougienisbet I’ve also seen that problem with the GPX maps plugin. The issue there is that the GPX maps plugin always loads its JS scripts regardless of whether it is displaying a map on the page, and it uses an earlier version of Leaflet maps which conflicts with the one used by my plugin. The OS maps plugin only loads the Leaflet script on pages where the shortcode is actually used, to avoid this sort of conflict. If you try to use both plugins on the same page then it will always be problematic.

I’m still seeing something which looks like a deferred load in the page source:
<script type=’text/javascript’ src=’https://burnhamjoggers.co.uk/wp-content/plugins/os-datahub-maps/js/leaflet.js&#8217; defer onload=” id=’osmap-leaflet-js’></script>

I think this may be a caching problem. Looks like the javascript files are not being loaded in time, so the JS on page is throwing up undefined reference errors. If you’re using a caching plugin can you try excluding the OS maps JS files from being delay-loaded?

Seems like a good idea. I’ll add that to the feature request list.

I did raise that concern with OS when the new APIs came out. They thought it was unlikely to be a problem in practice but that there is always OAuth.

In order to get the OAuth token, the mapping javascript would have to send a request to the WordPress server which would in turn use its stored credentials to request the token and return it to the client. Normally you would require the WordPress server to check who is making the request before going to the OS API to get the token, typically by checking that the user is logged in. But in most applications the website viewer is not logged in, so the server would have to accept anonymous requests. That puts you back to square one because anyone can use your endpoint to request an OAuth token and use it in their own map requests.

If you have any good ideas on how to make this work better then I may be able to look at implementing something.

I’ll add it to the to-do list to look at. No guarantees when, but in principle it seems doable.