Thanks Anh, of course I can tell 🙂
So we have these custom post-types and they all share common data; we then decided to store this shared data in a common custom table and some specific data in their respective post-type-specific custom tables.
We're hooking into the get_post_metadata
and the add_post_metadata
so that we can generalize the usage of the custom table plugin and render it "transparent" to other plugins such as Polylang.
To do so we need to programmatically get the source/destination table, given a meta-key, where we need to retrieve/store its value.
Let's focus on writing data (because we just join the shared/common meta-data table upon reading so it's simpler).
Our meta writing function, in pseudo-code, looks more or less like this
add_filter('add_post_metadata', function ( $check, $object_id, $meta_key, $meta_value, $unique ){
if this_is_not_a_custom_post_type || the_meta_key_is_not_a_metabox_field
return null;
// This is where we select the table, based on the field_id/meta_key
$table = com_get_obj_property( rwmb_get_field_settings( $meta_key, '', $object_id )['storage'], 'table' );
// This is so we update an existing ID in the custom table afterwards
maybe_insert_id_in_custom_meta_table( $object_id, $table );
// Maybe we need to serialize the value
if ( !empty($meta_value) )
$meta_value = maybe_serialize( $meta_value );
// Finally write the correct meta value in the correct table updating the correct ID
$wpdb->update( $table, [$meta_key => $meta_value], ['ID' => $object_id] );
});
As you can see, we dynamically need to grab the correct table based on the meta_key. That's why we'd need to have access to it (and we have, via the array casting trick).
A simple getter, would be enough. No need to have a setter or make it public.