This is a simple example that shows how we can maintain backwards compatibility in a plugin for data that used to be stored in post meta but is now stored in a taxonomy term. When this change was made, a new `edd_get_commission_status()` function was introduced, but before this function existed, the status was retrieved by calling `get_post_meta…

gistfile1.php

<?php

/**
 * Filters get_post_meta() to ensure old commission status checks don't fail
 *
 * The status for commission records used to be stored in postmeta, now it's stored in a taxonomy
 *
 * @access      private
 * @since       2.8
 * @return      mixed
 */
function eddc_filter_post_meta_for_status( $check, $object_id, $meta_key, $single ) {

	if( defined( 'EDDC_DOING_UPGRADES' ) ) {
		return $check;
	}

	if( '_commission_status' !== $meta_key ) {

		return $check;

	}

	if( has_term( 'paid', 'edd_commission_status', $object_id ) ) {

		return 'paid';

	} else {

		return 'unpaid';

	}

}
add_filter( 'get_post_metadata', 'eddc_filter_post_meta_for_status', 10, 4 );

An unusual but nonetheless very interesting approach! Have you covered updating post meta as well (shouldn't be a big deal)? I do think this should be accompanied by some sort of error message being logged indicating that some updating needs to be done (and possibly display a message in the admin panel for that). I'm not sure what I think about the approach in general, this is quite an intrusive way to maintain backwards compatibility.

@engelen I haven't though you could definitely take a similar approach.

I wouldn't advise this method unless you know there will be plugins that break when changes are made.

This is a good example of why we should always consider writing an "API" for our plugins that offers the "official" way to retrieve and set data for the plugin. By doing that, we give ourselves the freedom to change how / where the data is stored without breaking the code that other developers have written on top of our platforms.