Bug I verified in latest version of ACF, happened across two different fieldsets:
1. Create repeater field that applies to any kind of post type
2. Create new post of that type
3. “Publish” post as Private.
Using get_field on *either* the field slug OR the field key returns false.
Using get_post_meta() (or get_post_custom() or any other native WP function) returns the correct values.
Now, if you go into the post you created in (2) and publish it, you’ll see those values appear. ANd the kicker: edit post again, move it back to Private, then refresh frontend – now the fields DO appear.
Seems to me you might be attaching get_field to some kind of incorrect filter on the post_status?
Don’t know if this will help you.
If I create a new post and set it to private I get a 403 error if I try to view that post, even when I’m logged in, which I find odd. Then if I change it to public, for some reason I still get an error. Could be a caching issue because…
if I create a new private post and then change it to public before trying to view it I can see the page. If I make it private again, then I can’t see it.
This is with only WP and no plugins and a bare 2015 theme. WP should be allowing me to see these posts on the front end since I’m logged in as an admin. So now I’m suspecting some type of an error in WP.
At any rate, ACF calls a function to determine if the post id is a valid id. If WP is returning no value when ACF tries so get the post ID then you’ll get nothing from ACF.
So the question is; is this ACF or WP? I’m off to see if I can figure out why I can’t see private posts when logged in as an admin….
I see. So the issue is about whether the post “exists”. But if get_post_custom returns true, it seems to me that its an ACF issue – either its relying on a deprecated function to return if a post exists (and that function relays a private page as not existing) or not correctly searching to see if post exists… Maybe get_field does wpdb SELECT for post_status = publish?
I’m not sure what was causing my problem, but I can confirm that it is not ACF.
What I did was, I basically scrapped the site. It’s only a test site and I can do that. I deleted all the tables and reinstalled WP. So I have a fresh install, using 2016 and only ACF active. Everything is working the way that it should be, even with private posts.
It has been a long time since I’ve dumped this site and started clean. It’s where I build and work on plugins. I have 63 plugins on this site and they’ve all been active at one time or another, so I’m guessing when I say that I think something in one of these plugins cause the issue with private posts. So I’m also guessing that you may be seeing a similar situation.
For some reason, when ACF tries to get the current post ID something is causing WP to return no value.
It would probably be easier to tell me what plugins you’ve had installed than for me to list out all 63 of the ones I’ve used in the past. However, I did a search for various forms of not being about to see private posts and BBPress came up in quite a few of those searches and I have had BBPress installed on the test site.
Another thing you might to is, just before you try to get the acf value for the private post try adding the following. This is how ACF attempts to get the current post ID.
$object = get_queried_object();
echo '<pre>'; print_r($object); echo '</pre>';
See if you get anything on the private post where you’re not getting a value.
Good testing! To be honest this was a totally fresh site as well! No other plugins, just begininning to develop. The plot thickens…
The topic ‘Bug with repeater & private pages’ is closed to new replies.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Privacy Policy. If you continue to use this site, you consent to our use of cookies.