NEW Venue Map block

[carstingaxion]

Is your enhancement related to a problem? Please describe.

Several aspects, to keep in mind or be aware of while working on GatherPress' new Venue Map block:

SOC by reducing to the “map” component

Following on within the greater block-refactoring the current Venue block will probably be 80% of a new, stand-alone Venue Map block. As I already separated the venue-selection-logic into a single block, the new Venue Map block, doesn’t need to handle this, but instead can rely on the existence of context, see #629 for more details.

Use slotFills

All UI components should -in my opinion- be additionally rendered into a new slot registered by the new Venue block, named VenuePluginDocumentSettings . Which should not replace the normal block controls, but should help bringing controls together in one place, where it is needed, like when editing an explicit venue- or event-post.

Have a look at slotfill.js which has the relevant snippets. Even we haven't discussed this yet, I outlined the general approach in 2.2 using slotFills

• The new Venue Map blocks editing interface should be registered for the VenuePluginDocumentSettings slot.

Use Block Hooks API

GatherPress can and should make use of the new, available block hooks to further improve the editing experience like I described in 2.1 The new Block Hooks API.

My exploration of a new Venue Website block already uses the hooks API to add itself into the relevant pattern. Unfortunately, I haven't found time, yet, to describe what I did in #638 and I absolutely know, that my code is heavy WIP and not production ready, mainly because I'm unsure about Naming Things, but ...

• a new Venue Map block should be hooked-in as well.

Privacy

As first mentioned in my long collection of questions, I wanted to add some more info to the privacy-aspect of third-parties within EU regulations and would like to finally provide answers to @pbrocks questions from 5 weeks ago, sorry for that delay!

@pbrocks: Back in 2018, I contributed to the Privacy team as GDPR was becoming relevant and from my understanding, the issue is about potentially revealing individuals identity. Although we are using Google Maps to draw the map, it's only an iFrame, not an API connection that is doing so. That is, there isn't any registration/consent involved, and as such, it seems that this should circumvent the issue you reference.

No, I don't think so. Within the GDPR or the german privacy law called DSGVO, personal data includes the IP address of the user requesting a website. That being said, as website-owner I'm not allowed to sent any data to third-parties, before the user hasn't given consent, mostly in form of horrible cookie banners. To circumvent the need for such a banner, websites hosted in the EU can use Embed Privacy which prevents loading of such iframes to protect the users rights. This plugin is indeed helpful in my daily work and well-made, I think.

This will be the same for every map-provider, be it Google Maps or OSM, unfortunately.

@pbrocks: However, I understand I am dealing with speculation here, hence couching claims with modals like should and could, so I wonder if you have a suggestion about where to look for a more definitive answer to the question.

• The plugin developer handbook has its own privacy-section, which says:

  Does the plugin enqueue Javascript, tracking pixels or embed iframes from a third party (third party JS, tracking pixels and iframes can collect visitor’s data/actions, leave cookies, etc.)?

• Sarah Gooding wrote for the Tavern: German Court Fines Website Owner for Violating the GDPR by Using Google-Hosted Fonts – WP Tavern

• Suggest text to the websites privacy-page, about OSM & Google #875

Static Map images used like featured images

One idea to prevent this privacy-issue - at least for the visitor, not for the editor - is to save & update a static map image every time the map block is changed. This image can be served to the user, who has not given any consent yet. This can be done within GatherPress or hooked into plugins like Embed Privacy.

This could also open a bunch of nice curation possibilities, when integrated nicely into the editor, like so:

Extensibility

GatherPress should take note of the great work @dshanske did with simple-location. Instead of relying on one or the other Mapping service, simple-location works with standardised providers. This would give GatherPress most flexibility and would be a way that can be scaled on a per-site basis, rather than on a 'per all users of the plugin'-basis.

While simple-location goes even further, GatherPress should include at least two types of providers:

• 1. Mapping providers to render a map and
• 2. geo-location providers to validate and save a given Address into a proper scheme, the WordPress Geodata Standard for example.

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[carstingaxion]

Side note: While writing this issue, I was reminded on my first map plugin. I requested the removing from wp.org 4 weeks ago, because it was totally outdated, but 13 years ago, I was very proud about this.

[carstingaxion]

If written a php-based geo-location helper in the past, using the Nominatim API. This piece of 💩 code is on my refactoring-todo-list for a while and I could take this opportunity to getting things done, for GatherPress and me as well.

https://github.com/figuren-theater/deprecated__Figuren_Theater__v2/blob/master/mu-plugins/Figuren_Theater/src/inc/Geo/ft_geo_options_bridge.php#L201-L274

[dshanske]

Thanks for the compliment, by the way.

[carstingaxion]

Asked in #core-editor slack for help, where to start with static maps as featured images.

https://wordpress.slack.com/archives/C02QB2JS7/p1718484829132509