Fixed taxonomy field load/save function to get right post id if field… by highbelt · Pull Request #401 · AdvancedCustomFields/acf

highbelt · 2020-10-22T08:42:35Z

… is located in a block

If Taxonomy field is added to a block, the method acf_get_post_id_info() tries to get the right post id but fails because of the unrecognized syntax „block_38u4ndfd8“ of $post_id. Means taxonomy terms are not loaded from/saved to the post/page.

Tried to implement it in a way that all cases are covered: save, update, auto-save, load, ...

If there is a better/more robust way to get the (parent) Post ID in this part of code i'm happy to hear about.

… is located in a block

elliotcondon · 2020-10-22T08:45:42Z

Hi @highbelt - Thanks so much for this PR. You wouldn't believe it, but I'm actually working on this exact issue right now, ha!

highbelt · 2020-10-22T09:34:35Z

Hi @elliotcondon - just figured out, this solution seems to be not working for taxonomy fields placed inside a repeater field. It only saves the last entry to the post.

highbelt · 2020-10-30T12:20:02Z

fyi: the current WIP state of 5.9.2 breaks this workaround (i downgraded to 9.2.1 again)

elliotcondon · 2020-11-01T04:41:32Z

Hi @highbelt 👋. Thanks for the update.

You'll notice in our latest release (5.9.2) an initial attempt to add support for this enhancement. Unfortunately, we were not able to find an elegant enough solution to determine the current $post being edited during the block saving process, so we decided to abandon the code for that release.

It is definitely possible for us to determine the current "Object" being edited, and we will continue to investigate this into the future. We also need to consider - and perhaps consult with the community - whether or not a Taxonomy field within a Block may save data outside of the block scope. This may set a precedence which causes us issues in the future, so we will want ot be double sure that everyone is "for" and not "against".

Will keep you updated on the progress.

highbelt · 2020-12-08T13:38:15Z

After the update of 5.9.2 and 5.9.3 broke the workaround, here is a (more) update proof solution until this topic gets „fixed“.

function decode_post_id( $data ) {
$type = '';
$id = 0;
extract($data);
if($type === 'block') {
$realPostID = $id;
// try to get post id in all possible ways you can think of
if(isset($GLOBALS['post']) && isset($GLOBALS['post']->ID)) {
$type = 'post';
$realPostID = $GLOBALS['post']->ID;
} elseif(isset($_REQUEST['post_id']) && is_numeric($_REQUEST['post_id'])) {
$type = 'post';
$realPostID = $_REQUEST['post_id'];
} elseif(isset($GLOBALS['HTTP_RAW_POST_DATA'])) {
$rawPostData = $GLOBALS['HTTP_RAW_POST_DATA'];
$postData = json_decode($rawPostData, true);
if(isset($postData['id'])) {
$type = 'post';
$realPostID = $postData['id'];
}
}
$id = (int) $realPostID;
}
return array("type" => $type, "id" => $id);
}
add_filter( 'acf/decode_post_id' , decode_post_id );

@elliotcondon regarding your thoughts and concerns on implementing this behavior in general:
As you currently have the option to configure the taxonomy fields to save and/or load the parent post taxonomies, it is just consequent to implement like this, i think.

elliotcondon · 2020-12-09T22:26:50Z

Hi @highbelt. Thanks for the update.

Does your above code cause any issues when loading field values within the field's render function/callback?

highbelt · 2020-10-22T08:42:35Z

… is located in a block

If Taxonomy field is added to a block, the method acf_get_post_id_info() tries to get the right post id but fails because of the unrecognized syntax „block_38u4ndfd8“ of $post_id. Means taxonomy terms are not loaded from/saved to the post/page.

Tried to implement it in a way that all cases are covered: save, update, auto-save, load, ...

If there is a better/more robust way to get the (parent) Post ID in this part of code i'm happy to hear about.

… is located in a block

elliotcondon · 2020-10-22T08:45:42Z

Hi @highbelt - Thanks so much for this PR. You wouldn't believe it, but I'm actually working on this exact issue right now, ha!

highbelt · 2020-10-22T09:34:35Z

Hi @elliotcondon - just figured out, this solution seems to be not working for taxonomy fields placed inside a repeater field. It only saves the last entry to the post.

highbelt · 2020-10-30T12:20:02Z

fyi: the current WIP state of 5.9.2 breaks this workaround (i downgraded to 9.2.1 again)

elliotcondon · 2020-11-01T04:41:32Z

Hi @highbelt 👋. Thanks for the update.

You'll notice in our latest release (5.9.2) an initial attempt to add support for this enhancement. Unfortunately, we were not able to find an elegant enough solution to determine the current $post being edited during the block saving process, so we decided to abandon the code for that release.

It is definitely possible for us to determine the current "Object" being edited, and we will continue to investigate this into the future. We also need to consider - and perhaps consult with the community - whether or not a Taxonomy field within a Block may save data outside of the block scope. This may set a precedence which causes us issues in the future, so we will want ot be double sure that everyone is "for" and not "against".

Will keep you updated on the progress.

highbelt · 2020-12-08T13:38:15Z

After the update of 5.9.2 and 5.9.3 broke the workaround, here is a (more) update proof solution until this topic gets „fixed“.

function decode_post_id( $data ) {
$type = '';
$id = 0;
extract($data);
if($type === 'block') {
$realPostID = $id;
// try to get post id in all possible ways you can think of
if(isset($GLOBALS['post']) && isset($GLOBALS['post']->ID)) {
$type = 'post';
$realPostID = $GLOBALS['post']->ID;
} elseif(isset($_REQUEST['post_id']) && is_numeric($_REQUEST['post_id'])) {
$type = 'post';
$realPostID = $_REQUEST['post_id'];
} elseif(isset($GLOBALS['HTTP_RAW_POST_DATA'])) {
$rawPostData = $GLOBALS['HTTP_RAW_POST_DATA'];
$postData = json_decode($rawPostData, true);
if(isset($postData['id'])) {
$type = 'post';
$realPostID = $postData['id'];
}
}
$id = (int) $realPostID;
}
return array("type" => $type, "id" => $id);
}
add_filter( 'acf/decode_post_id' , decode_post_id );

@elliotcondon regarding your thoughts and concerns on implementing this behavior in general:
As you currently have the option to configure the taxonomy fields to save and/or load the parent post taxonomies, it is just consequent to implement like this, i think.

elliotcondon · 2020-12-09T22:26:50Z

Hi @highbelt. Thanks for the update.

Does your above code cause any issues when loading field values within the field's render function/callback?

highbelt · 2020-10-22T08:42:35Z

… is located in a block

If Taxonomy field is added to a block, the method acf_get_post_id_info() tries to get the right post id but fails because of the unrecognized syntax „block_38u4ndfd8“ of $post_id. Means taxonomy terms are not loaded from/saved to the post/page.

Tried to implement it in a way that all cases are covered: save, update, auto-save, load, ...

If there is a better/more robust way to get the (parent) Post ID in this part of code i'm happy to hear about.

… is located in a block

elliotcondon · 2020-10-22T08:45:42Z

Hi @highbelt - Thanks so much for this PR. You wouldn't believe it, but I'm actually working on this exact issue right now, ha!

highbelt · 2020-10-22T09:34:35Z

Hi @elliotcondon - just figured out, this solution seems to be not working for taxonomy fields placed inside a repeater field. It only saves the last entry to the post.

highbelt · 2020-10-30T12:20:02Z

fyi: the current WIP state of 5.9.2 breaks this workaround (i downgraded to 9.2.1 again)

elliotcondon · 2020-11-01T04:41:32Z

Hi @highbelt 👋. Thanks for the update.

You'll notice in our latest release (5.9.2) an initial attempt to add support for this enhancement. Unfortunately, we were not able to find an elegant enough solution to determine the current $post being edited during the block saving process, so we decided to abandon the code for that release.

It is definitely possible for us to determine the current "Object" being edited, and we will continue to investigate this into the future. We also need to consider - and perhaps consult with the community - whether or not a Taxonomy field within a Block may save data outside of the block scope. This may set a precedence which causes us issues in the future, so we will want ot be double sure that everyone is "for" and not "against".

Will keep you updated on the progress.

highbelt · 2020-12-08T13:38:15Z

After the update of 5.9.2 and 5.9.3 broke the workaround, here is a (more) update proof solution until this topic gets „fixed“.

function decode_post_id( $data ) {
$type = '';
$id = 0;
extract($data);
if($type === 'block') {
$realPostID = $id;
// try to get post id in all possible ways you can think of
if(isset($GLOBALS['post']) && isset($GLOBALS['post']->ID)) {
$type = 'post';
$realPostID = $GLOBALS['post']->ID;
} elseif(isset($_REQUEST['post_id']) && is_numeric($_REQUEST['post_id'])) {
$type = 'post';
$realPostID = $_REQUEST['post_id'];
} elseif(isset($GLOBALS['HTTP_RAW_POST_DATA'])) {
$rawPostData = $GLOBALS['HTTP_RAW_POST_DATA'];
$postData = json_decode($rawPostData, true);
if(isset($postData['id'])) {
$type = 'post';
$realPostID = $postData['id'];
}
}
$id = (int) $realPostID;
}
return array("type" => $type, "id" => $id);
}
add_filter( 'acf/decode_post_id' , decode_post_id );

@elliotcondon regarding your thoughts and concerns on implementing this behavior in general:
As you currently have the option to configure the taxonomy fields to save and/or load the parent post taxonomies, it is just consequent to implement like this, i think.

elliotcondon · 2020-12-09T22:26:50Z

Hi @highbelt. Thanks for the update.

Does your above code cause any issues when loading field values within the field's render function/callback?

highbelt · 2020-10-22T08:42:35Z

… is located in a block

If Taxonomy field is added to a block, the method acf_get_post_id_info() tries to get the right post id but fails because of the unrecognized syntax „block_38u4ndfd8“ of $post_id. Means taxonomy terms are not loaded from/saved to the post/page.

Tried to implement it in a way that all cases are covered: save, update, auto-save, load, ...

If there is a better/more robust way to get the (parent) Post ID in this part of code i'm happy to hear about.

… is located in a block

elliotcondon · 2020-10-22T08:45:42Z

Hi @highbelt - Thanks so much for this PR. You wouldn't believe it, but I'm actually working on this exact issue right now, ha!

highbelt · 2020-10-22T09:34:35Z

Hi @elliotcondon - just figured out, this solution seems to be not working for taxonomy fields placed inside a repeater field. It only saves the last entry to the post.

highbelt · 2020-10-30T12:20:02Z

fyi: the current WIP state of 5.9.2 breaks this workaround (i downgraded to 9.2.1 again)

elliotcondon · 2020-11-01T04:41:32Z

Hi @highbelt 👋. Thanks for the update.

You'll notice in our latest release (5.9.2) an initial attempt to add support for this enhancement. Unfortunately, we were not able to find an elegant enough solution to determine the current $post being edited during the block saving process, so we decided to abandon the code for that release.

It is definitely possible for us to determine the current "Object" being edited, and we will continue to investigate this into the future. We also need to consider - and perhaps consult with the community - whether or not a Taxonomy field within a Block may save data outside of the block scope. This may set a precedence which causes us issues in the future, so we will want ot be double sure that everyone is "for" and not "against".

Will keep you updated on the progress.

highbelt · 2020-12-08T13:38:15Z

After the update of 5.9.2 and 5.9.3 broke the workaround, here is a (more) update proof solution until this topic gets „fixed“.

function decode_post_id( $data ) {
$type = '';
$id = 0;
extract($data);
if($type === 'block') {
$realPostID = $id;
// try to get post id in all possible ways you can think of
if(isset($GLOBALS['post']) && isset($GLOBALS['post']->ID)) {
$type = 'post';
$realPostID = $GLOBALS['post']->ID;
} elseif(isset($_REQUEST['post_id']) && is_numeric($_REQUEST['post_id'])) {
$type = 'post';
$realPostID = $_REQUEST['post_id'];
} elseif(isset($GLOBALS['HTTP_RAW_POST_DATA'])) {
$rawPostData = $GLOBALS['HTTP_RAW_POST_DATA'];
$postData = json_decode($rawPostData, true);
if(isset($postData['id'])) {
$type = 'post';
$realPostID = $postData['id'];
}
}
$id = (int) $realPostID;
}
return array("type" => $type, "id" => $id);
}
add_filter( 'acf/decode_post_id' , decode_post_id );

@elliotcondon regarding your thoughts and concerns on implementing this behavior in general:
As you currently have the option to configure the taxonomy fields to save and/or load the parent post taxonomies, it is just consequent to implement like this, i think.

elliotcondon · 2020-12-09T22:26:50Z

Hi @highbelt. Thanks for the update.

Does your above code cause any issues when loading field values within the field's render function/callback?

highbelt · 2020-10-22T08:42:35Z

… is located in a block

If Taxonomy field is added to a block, the method acf_get_post_id_info() tries to get the right post id but fails because of the unrecognized syntax „block_38u4ndfd8“ of $post_id. Means taxonomy terms are not loaded from/saved to the post/page.

Tried to implement it in a way that all cases are covered: save, update, auto-save, load, ...

If there is a better/more robust way to get the (parent) Post ID in this part of code i'm happy to hear about.

… is located in a block

elliotcondon · 2020-10-22T08:45:42Z

Hi @highbelt - Thanks so much for this PR. You wouldn't believe it, but I'm actually working on this exact issue right now, ha!

highbelt · 2020-10-22T09:34:35Z

Hi @elliotcondon - just figured out, this solution seems to be not working for taxonomy fields placed inside a repeater field. It only saves the last entry to the post.

highbelt · 2020-10-30T12:20:02Z

fyi: the current WIP state of 5.9.2 breaks this workaround (i downgraded to 9.2.1 again)

elliotcondon · 2020-11-01T04:41:32Z

Hi @highbelt 👋. Thanks for the update.

You'll notice in our latest release (5.9.2) an initial attempt to add support for this enhancement. Unfortunately, we were not able to find an elegant enough solution to determine the current $post being edited during the block saving process, so we decided to abandon the code for that release.

It is definitely possible for us to determine the current "Object" being edited, and we will continue to investigate this into the future. We also need to consider - and perhaps consult with the community - whether or not a Taxonomy field within a Block may save data outside of the block scope. This may set a precedence which causes us issues in the future, so we will want ot be double sure that everyone is "for" and not "against".

Will keep you updated on the progress.

highbelt · 2020-12-08T13:38:15Z

After the update of 5.9.2 and 5.9.3 broke the workaround, here is a (more) update proof solution until this topic gets „fixed“.

function decode_post_id( $data ) {
$type = '';
$id = 0;
extract($data);
if($type === 'block') {
$realPostID = $id;
// try to get post id in all possible ways you can think of
if(isset($GLOBALS['post']) && isset($GLOBALS['post']->ID)) {
$type = 'post';
$realPostID = $GLOBALS['post']->ID;
} elseif(isset($_REQUEST['post_id']) && is_numeric($_REQUEST['post_id'])) {
$type = 'post';
$realPostID = $_REQUEST['post_id'];
} elseif(isset($GLOBALS['HTTP_RAW_POST_DATA'])) {
$rawPostData = $GLOBALS['HTTP_RAW_POST_DATA'];
$postData = json_decode($rawPostData, true);
if(isset($postData['id'])) {
$type = 'post';
$realPostID = $postData['id'];
}
}
$id = (int) $realPostID;
}
return array("type" => $type, "id" => $id);
}
add_filter( 'acf/decode_post_id' , decode_post_id );

@elliotcondon regarding your thoughts and concerns on implementing this behavior in general:
As you currently have the option to configure the taxonomy fields to save and/or load the parent post taxonomies, it is just consequent to implement like this, i think.

elliotcondon · 2020-12-09T22:26:50Z

Hi @highbelt. Thanks for the update.

Does your above code cause any issues when loading field values within the field's render function/callback?

highbelt · 2020-10-22T08:42:35Z

… is located in a block

If Taxonomy field is added to a block, the method acf_get_post_id_info() tries to get the right post id but fails because of the unrecognized syntax „block_38u4ndfd8“ of $post_id. Means taxonomy terms are not loaded from/saved to the post/page.

Tried to implement it in a way that all cases are covered: save, update, auto-save, load, ...

If there is a better/more robust way to get the (parent) Post ID in this part of code i'm happy to hear about.

… is located in a block

elliotcondon · 2020-10-22T08:45:42Z

Hi @highbelt - Thanks so much for this PR. You wouldn't believe it, but I'm actually working on this exact issue right now, ha!

highbelt · 2020-10-22T09:34:35Z

Hi @elliotcondon - just figured out, this solution seems to be not working for taxonomy fields placed inside a repeater field. It only saves the last entry to the post.

highbelt · 2020-10-30T12:20:02Z

fyi: the current WIP state of 5.9.2 breaks this workaround (i downgraded to 9.2.1 again)

elliotcondon · 2020-11-01T04:41:32Z

Hi @highbelt 👋. Thanks for the update.

You'll notice in our latest release (5.9.2) an initial attempt to add support for this enhancement. Unfortunately, we were not able to find an elegant enough solution to determine the current $post being edited during the block saving process, so we decided to abandon the code for that release.

It is definitely possible for us to determine the current "Object" being edited, and we will continue to investigate this into the future. We also need to consider - and perhaps consult with the community - whether or not a Taxonomy field within a Block may save data outside of the block scope. This may set a precedence which causes us issues in the future, so we will want ot be double sure that everyone is "for" and not "against".

Will keep you updated on the progress.

highbelt · 2020-12-08T13:38:15Z

After the update of 5.9.2 and 5.9.3 broke the workaround, here is a (more) update proof solution until this topic gets „fixed“.

function decode_post_id( $data ) {
$type = '';
$id = 0;
extract($data);
if($type === 'block') {
$realPostID = $id;
// try to get post id in all possible ways you can think of
if(isset($GLOBALS['post']) && isset($GLOBALS['post']->ID)) {
$type = 'post';
$realPostID = $GLOBALS['post']->ID;
} elseif(isset($_REQUEST['post_id']) && is_numeric($_REQUEST['post_id'])) {
$type = 'post';
$realPostID = $_REQUEST['post_id'];
} elseif(isset($GLOBALS['HTTP_RAW_POST_DATA'])) {
$rawPostData = $GLOBALS['HTTP_RAW_POST_DATA'];
$postData = json_decode($rawPostData, true);
if(isset($postData['id'])) {
$type = 'post';
$realPostID = $postData['id'];
}
}
$id = (int) $realPostID;
}
return array("type" => $type, "id" => $id);
}
add_filter( 'acf/decode_post_id' , decode_post_id );

@elliotcondon regarding your thoughts and concerns on implementing this behavior in general:
As you currently have the option to configure the taxonomy fields to save and/or load the parent post taxonomies, it is just consequent to implement like this, i think.

elliotcondon · 2020-12-09T22:26:50Z

Hi @highbelt. Thanks for the update.

Does your above code cause any issues when loading field values within the field's render function/callback?

highbelt · 2020-10-22T08:42:35Z

… is located in a block

If Taxonomy field is added to a block, the method acf_get_post_id_info() tries to get the right post id but fails because of the unrecognized syntax „block_38u4ndfd8“ of $post_id. Means taxonomy terms are not loaded from/saved to the post/page.

Tried to implement it in a way that all cases are covered: save, update, auto-save, load, ...

If there is a better/more robust way to get the (parent) Post ID in this part of code i'm happy to hear about.

… is located in a block

elliotcondon · 2020-10-22T08:45:42Z

Hi @highbelt - Thanks so much for this PR. You wouldn't believe it, but I'm actually working on this exact issue right now, ha!

highbelt · 2020-10-22T09:34:35Z

Hi @elliotcondon - just figured out, this solution seems to be not working for taxonomy fields placed inside a repeater field. It only saves the last entry to the post.

highbelt · 2020-10-30T12:20:02Z

fyi: the current WIP state of 5.9.2 breaks this workaround (i downgraded to 9.2.1 again)

elliotcondon · 2020-11-01T04:41:32Z

Hi @highbelt 👋. Thanks for the update.

You'll notice in our latest release (5.9.2) an initial attempt to add support for this enhancement. Unfortunately, we were not able to find an elegant enough solution to determine the current $post being edited during the block saving process, so we decided to abandon the code for that release.

It is definitely possible for us to determine the current "Object" being edited, and we will continue to investigate this into the future. We also need to consider - and perhaps consult with the community - whether or not a Taxonomy field within a Block may save data outside of the block scope. This may set a precedence which causes us issues in the future, so we will want ot be double sure that everyone is "for" and not "against".

Will keep you updated on the progress.

highbelt · 2020-12-08T13:38:15Z

After the update of 5.9.2 and 5.9.3 broke the workaround, here is a (more) update proof solution until this topic gets „fixed“.

function decode_post_id( $data ) {
$type = '';
$id = 0;
extract($data);
if($type === 'block') {
$realPostID = $id;
// try to get post id in all possible ways you can think of
if(isset($GLOBALS['post']) && isset($GLOBALS['post']->ID)) {
$type = 'post';
$realPostID = $GLOBALS['post']->ID;
} elseif(isset($_REQUEST['post_id']) && is_numeric($_REQUEST['post_id'])) {
$type = 'post';
$realPostID = $_REQUEST['post_id'];
} elseif(isset($GLOBALS['HTTP_RAW_POST_DATA'])) {
$rawPostData = $GLOBALS['HTTP_RAW_POST_DATA'];
$postData = json_decode($rawPostData, true);
if(isset($postData['id'])) {
$type = 'post';
$realPostID = $postData['id'];
}
}
$id = (int) $realPostID;
}
return array("type" => $type, "id" => $id);
}
add_filter( 'acf/decode_post_id' , decode_post_id );

@elliotcondon regarding your thoughts and concerns on implementing this behavior in general:
As you currently have the option to configure the taxonomy fields to save and/or load the parent post taxonomies, it is just consequent to implement like this, i think.

elliotcondon · 2020-12-09T22:26:50Z

Hi @highbelt. Thanks for the update.

Does your above code cause any issues when loading field values within the field's render function/callback?

highbelt · 2020-10-22T08:42:35Z

… is located in a block

If Taxonomy field is added to a block, the method acf_get_post_id_info() tries to get the right post id but fails because of the unrecognized syntax „block_38u4ndfd8“ of $post_id. Means taxonomy terms are not loaded from/saved to the post/page.

Tried to implement it in a way that all cases are covered: save, update, auto-save, load, ...

If there is a better/more robust way to get the (parent) Post ID in this part of code i'm happy to hear about.

… is located in a block

elliotcondon · 2020-10-22T08:45:42Z

Hi @highbelt - Thanks so much for this PR. You wouldn't believe it, but I'm actually working on this exact issue right now, ha!

highbelt · 2020-10-22T09:34:35Z

Hi @elliotcondon - just figured out, this solution seems to be not working for taxonomy fields placed inside a repeater field. It only saves the last entry to the post.

highbelt · 2020-10-30T12:20:02Z

fyi: the current WIP state of 5.9.2 breaks this workaround (i downgraded to 9.2.1 again)

elliotcondon · 2020-11-01T04:41:32Z

Hi @highbelt 👋. Thanks for the update.

You'll notice in our latest release (5.9.2) an initial attempt to add support for this enhancement. Unfortunately, we were not able to find an elegant enough solution to determine the current $post being edited during the block saving process, so we decided to abandon the code for that release.

It is definitely possible for us to determine the current "Object" being edited, and we will continue to investigate this into the future. We also need to consider - and perhaps consult with the community - whether or not a Taxonomy field within a Block may save data outside of the block scope. This may set a precedence which causes us issues in the future, so we will want ot be double sure that everyone is "for" and not "against".

Will keep you updated on the progress.

highbelt · 2020-12-08T13:38:15Z

After the update of 5.9.2 and 5.9.3 broke the workaround, here is a (more) update proof solution until this topic gets „fixed“.

function decode_post_id( $data ) {
$type = '';
$id = 0;
extract($data);
if($type === 'block') {
$realPostID = $id;
// try to get post id in all possible ways you can think of
if(isset($GLOBALS['post']) && isset($GLOBALS['post']->ID)) {
$type = 'post';
$realPostID = $GLOBALS['post']->ID;
} elseif(isset($_REQUEST['post_id']) && is_numeric($_REQUEST['post_id'])) {
$type = 'post';
$realPostID = $_REQUEST['post_id'];
} elseif(isset($GLOBALS['HTTP_RAW_POST_DATA'])) {
$rawPostData = $GLOBALS['HTTP_RAW_POST_DATA'];
$postData = json_decode($rawPostData, true);
if(isset($postData['id'])) {
$type = 'post';
$realPostID = $postData['id'];
}
}
$id = (int) $realPostID;
}
return array("type" => $type, "id" => $id);
}
add_filter( 'acf/decode_post_id' , decode_post_id );

@elliotcondon regarding your thoughts and concerns on implementing this behavior in general:
As you currently have the option to configure the taxonomy fields to save and/or load the parent post taxonomies, it is just consequent to implement like this, i think.

elliotcondon · 2020-12-09T22:26:50Z

Hi @highbelt. Thanks for the update.

Does your above code cause any issues when loading field values within the field's render function/callback?

Fixed taxonomy field load/save function to get right post id if field…
91195c5
… is located in a block

Uh oh!

Conversation

highbelt commented Oct 22, 2020

Uh oh!

elliotcondon commented Oct 22, 2020

Uh oh!

highbelt commented Oct 22, 2020

Uh oh!

highbelt commented Oct 30, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

elliotcondon commented Nov 1, 2020

Uh oh!

highbelt commented Dec 8, 2020

Uh oh!

elliotcondon commented Dec 9, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

highbelt commented Oct 22, 2020

Uh oh!

elliotcondon commented Oct 22, 2020

Uh oh!

highbelt commented Oct 22, 2020

Uh oh!

highbelt commented Oct 30, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

elliotcondon commented Nov 1, 2020

Uh oh!

highbelt commented Dec 8, 2020

Uh oh!

elliotcondon commented Dec 9, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

highbelt commented Oct 22, 2020

Uh oh!

elliotcondon commented Oct 22, 2020

Uh oh!

highbelt commented Oct 22, 2020

Uh oh!

highbelt commented Oct 30, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

elliotcondon commented Nov 1, 2020

Uh oh!

highbelt commented Dec 8, 2020

Uh oh!

elliotcondon commented Dec 9, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

highbelt commented Oct 22, 2020

Uh oh!

elliotcondon commented Oct 22, 2020

highbelt commented Oct 30, 2020•
edited
Loading

highbelt commented Oct 30, 2020•
edited
Loading

highbelt commented Oct 30, 2020•
edited
Loading

highbelt commented Oct 30, 2020•
edited
Loading

highbelt commented Oct 30, 2020•
edited
Loading