PR Summary

• Dependencies Updates
  Several dependencies in different block related files like add-to-calendar, event-date, events-list, online-event, rsvp-response have been added or updated. This means these blocks will now work more efficiently with the new or upgraded resources they depend on.

• CSS Styling Update
  The aesthetics and visual experience of the events-list block has been improved with some style changes.

• Addition of Leaflet CSS Dependency and Version Updates
  Addition of the Leaflet CSS signify an improvement in the appearance and functionality of the gatherpress-venue block. Alongside this, there have been version number updates for various scripts related to venue and rsvp blocks which will mostly bring bug fixes and potential enhancement in performance.

• Dependency Additions and Version Updates in Package Files
  There have been several additions and updates in the project package files, with the inclusion of react-leaflet and leaflet dependencies, signifying the addition of mapping functionalities. Version updates for react, react-dom and react-lifecycles-compat hint towards the improved performance and potential bug fixes of the relevant functionalities.

• Function Update in class-assets.php
  The enqueue_scripts function now checks for the presence of the gatherpress/venue block and queues the Leaflet CSS accordingly, ensuring the correct styles are applied when needed.

• Introduction of Map Components
  Two new map embedding components have been created - GoogleMap and LeafletMap. They allow for embedding Google and Leaflet maps with customizable options like location, zoom level, map type, and height. The MapEmbed.js file has been enhanced to use these new map components based on the mapType value.

These changes improve the product by enhancing its functionality, aesthetics, performance and including new features like map embedding.

We'll also need to add Leaflet to docs, see #610

I re-read this issue again today and stumbled upon:

This is a working draft for the OSM team to develop on.

Who should go on with the work to do?
Who is in the OSM Team?

I re-read this issue again today and stumbled upon:

This is a working draft for the OSM team to develop on.

Who should go on with the work to do? Who is in the OSM Team?

I think he means himself, @linusx, and @jmarx who wanted to work on this feature in one of our huddles.

Thanks.

@MervinHernandez all things you saw fail should be fixed now.

@stephenerdelyi @jmarx the data needs to be updated (latitude, longitude, address) need to meet the Geodata Format in ticket 561 https://codex.wordpress.org/Geodata#Geodata_Format

Details are in ticket #560 (cc @carstingaxion @MervinHernandez)

EDIT: This actually should be pretty easy. We can keep things as they are, but create a pseudo post meta function to retrieve the data from our serialized meta we use for gatherpress venue. I can probably take a look at this if you all wish.

Is testing in the playground using this PR loading the latest commit?

If yes, just done a test (20240721 06:15 UTC), happening in both Firefox and Chrome, and only with OSM, not with Google Maps.

When a map height is expanded, it gets a grey area (after about 370px), this solves as soon as we either resize the browser, or change the Zoom level in the block

@stephenerdelyi @jmarx the data needs to be updated (latitude, longitude, address) need to meet the Geodata Format in ticket 561 https://codex.wordpress.org/Geodata#Geodata_Format

Details are in ticket #560 (cc @carstingaxion @MervinHernandez)

EDIT: This actually should be pretty easy. We can keep things as they are, but create a pseudo post meta function to retrieve the data from our serialized meta we use for gatherpress venue. I can probably take a look at this if you all wish.

As an example, I created such a pseudo-post-meta-getter while working on the new Venue Website block AND over here (#560 (comment)), which worked, but have been criticised by @shawfactor for good reasons here.

\add_filter(
  'get_post_metadata',
  function ( $metadata, $object_id, $meta_key ): mixed {
	  if ( 'venue_information_website' !== $meta_key ) {
		  return $metadata;
	  }
  
	  $venue_information = (array) json_decode( get_post_meta( $object_id, 'gatherpress_venue_information', true ) );
	  return [
		  ( isset( $venue_information['website'] ) ) ? $venue_information['website'] : '',
	  ];
  },
  10,
  3
);

How to handle that post_meta and when to do it is more a strategic descision, I guess.

Currently I'm building the new blocks for Venue Website, Venue Address and ... as singular post_meta fields, because I understood this to be common sense.

How to handle that post_meta and when to do it is more a strategic descision, I guess.

Currently I'm building the new blocks for Venue Website, Venue Address and ... as singular post_meta fields, because I understood this to be common sense.

@carstingaxion this might be better. Using the filter has become challenging. I committed as far as I got with it, but maybe these should all just be singular post meta matching geodata format wordpress is looking for.

but maybe these should all just be singular post meta

Yes, please. Let's not reinvent the wheel, and use post_meta for what it is made for.

And because this would be a close-to-core route, GatherPress can make use of some more core APIs a little more easily. Like the core-data store in JS or native Editing for the Block Bindings API in php, which will be especially interesting for the venue address and venue phone data.

Is testing in the playground using this PR loading the latest commit?

If yes, just done a test (20240721 06:15 UTC), happening in both Firefox and Chrome, and only with OSM, not with Google Maps.

When a map height is expanded, it gets a grey area (after about 370px), this solves as soon as we either resize the browser, or change the Zoom level in the block

@patriciabt this should be fixed now. Good catch!!

but maybe these should all just be singular post meta

Yes, please. Let's not reinvent the wheel, and use post_meta for what it is made for.

And because this would be a close-to-core route, GatherPress can make use of some more core APIs a little more easily. Like the core-data store in JS or native Editing for the Block Bindings API in php, which will be especially interesting for the venue address and venue phone data.

So the post meta will be as follows for venue, correct?

• geo_latitude
• geo_longitude
• geo_public
• geo_address
• gatherpress_venue_phone_number
• gatherpress_venue_website

EDIT: Now that I'm thinking about it, do we just want to remove phone number and website from the block entirely? Those things can be added to the venue post as text if someone wants to add them. I'm just wondering if there's any real value at this point to storing that data as meta? Let me know what you think @carstingaxion.

I'm totally fine with your suggested post_meta @mauteri , like I described in #560.

Like also described over there, I would bind geo_public directly to a is-post_status-public boolean, to not have to introduce and maintain a UI for that, just only because GatherPress wants to align with the WP geo data standard.

And yes, I would also keep venue-website and venue-phone as separate post meta. I can imagine some use-cases where either one of them or both seem useful.

✅ TEST Latest open-street-maps Branch on GP

✅ Setup Test

✅ INSTALL Latest GP Branch on DEV

✅ TEST Open Street Maps

• CREATE Venue - with Address
  • Text - Full Address = renders on update
  • Text - Phone Number = renders on update
  • Text - Website = renders on update
  • Toggle - Show map = animates on-off
  • Slider - Zoom level = animates on update
  • Toggle - Satelite-Map = animates on update
  • Slider - Map Height = updates on update
  • VIEW Venue on front-end Desktop(https://develop.gatherpress.org/venue/panera-bread-downtown-nashville/))
  • VIEW Venue on front-end (mobile)
• CREATE Event
  • Start Date Selector = visible + date fly-out
  • Start Date Selector = observes WP Time Zone
  • Start Date Selector = calculates end date to be at least +2 hours, upon update
  • Time Zone Selector = displays WP time zone by default
  • VIEW Event on front-end Desktop(https://develop.gatherpress.org/event/sample-event-july-29/))
  • VIEW Event on front-end (mobile)

✅ TEST Open Street Maps - Settings

• TOGGLE to Google Maps (from OSM)
  • TEST Editor Screen - Venue map settings = ✅ All pass
  • TEST Front-end view of Venue Map = ✅ Pass
  • TEST Editor Screen - Event = ✅ Pass
  • TEST Front-end view of Event Map = ✅ Pass

✅ TEST BUGFIXES - July 27

✅ RESOLVED = 0727-01 Map Location Indicator = not visible in editor window
✅ RESOLVED = 0727-02 Map location indicator = not visible in the venue single

🐞 BUGFIXES That Remain

1. 0727-03 Front-end Map renders on top of “Add to Calendar” flyout menu (both desktop and mobile)
   • Note - This bug behavior is not present in Google Maps view
   • Screenshot - Desktop
   • 
   • Screenshot - Mobile
   • 
2. 0727-04 Export of events ** does not ** include event start-end date data