Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed taxonomy field load/save function to get right post id if field… #401

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

highbelt
Copy link

… 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.

@elliotcondon
Copy link
Contributor

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
Copy link
Author

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
Copy link
Author

highbelt commented Oct 30, 2020

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

@elliotcondon
Copy link
Contributor

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
Copy link
Author

highbelt commented Dec 8, 2020

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.

image

@elliotcondon
Copy link
Contributor

Hi @highbelt. Thanks for the update.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants