Thanks for keeping this @mauteri.

I wanted to give some more information on my initial attempt and why the WordPress Geodata Standard could be from interest for GatherPress' gp_venue post type and maybe even for the gp_event post type as well.

The codex says:

WordPress does not include any geographic functionality or functions to deal with Geodata itself [...].
But there is a standard for how to store geodata, so that plugins can interoperate.

The W3C Geolocation API([1]), introduced in 2014, offers the additional geolocation properties of altitude, accuracy, altitudeAccuracy, speed, and heading, which if adopted by any plugin to ensure compatibility with this, should be stored with the geo_ prefix.

If GatherPress wanted to follow this standard, it must make sure to save geo-related data within specially named custom-fields aka post_meta following this given format:

geo_latitude REQUIRED
(float) decimal degrees -90 to 90 (negative values are in the southern hemisphere).
geo_longitude REQUIRED
(float) decimal degrees -180 to 180 (negative values are in the western hemisphere).
geo_public OPTIONAL
(int) is the geodata public (1) or private (0)? If value is missing or not set to 0, assume public.
geo_address OPTIONAL
(string) freeform textual description of coordinates.

Because of the required fields for latitude and longitude, it's not possible to provide the needed data with the current version of GatherPress, the required data is missing.

So we would at least need to:

Request and save latitude and longitude data from the geo-data API (whichever we use)
Bind geo_publicdirectly to post_status
and geo_address is already available

While working on #638 I found out and tested for the first time, if and that it's possible to work with non-existent post_meta. This allows GatherPress to keep its current data structure, while still aligning with the WordPress Geodata Standard.

Example pseudo-post_meta for `geo_address`

'geo_address' => array(
	'auth_callback'     => function () {
		return current_user_can( 'edit_posts' );
	},
	'sanitize_callback' => 'sanitize_text_field',
	'show_in_rest'      => true,
	'single'            => true,
	'type'              => 'string',
),

Load a filter to hook into the post_meta retrival

\add_filter(
	'get_post_metadata',
	array( $this, 'get_pseudo_post_meta' ),
	10,
	3
);

Make sure data is delivered

function get_pseudo_post_meta( $metadata, $object_id, $meta_key ): mixed {
	if ( ! in_array( $meta_key, ['geo_latitude','geo_longitude','geo_address'] ) ) {
		return $metadata;
	}
	$venue_information = (array) json_decode( get_post_meta( $object_id, 'venue_information', true ) );
	$output = [];

	switch ($meta_key) {
		case 'geo_latitude':
			$output[] = '48.856613'; // Paris
			break;
		
		case 'geo_longitude':
			$output[] = '2.352222'; // Paris
			break;
		
		case 'geo_address':
			$output[] = ( isset( $venue_information['fullAddress'] ) ) ? $venue_information['fullAddress'] : '';
			break;
		
		default:
			break;
	}

	return $output;
}

This worked very well and I was able to see my pseudo-post_meta in action, using the Simple Location – WordPress plugin, which is following the WordPress Geodata Standard.

So, why not start saving latitude and longitude and aligning with the WordPress Geodata Standard?!!

Example pseudo-post_meta for geo_address

Example pseudo-post_meta for `geo_address`

Venue post_type does not take care about the WordPress Geodata Standard. #560

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions