Hi John,
firstly thanks so much for your detailed reply!
I was looking into it a bit more and thought the problem might have stemmed from a separate function redirecting non-admins out of wp-admin if they tried to access it. e.g.
https://support.advancedcustomfields.com/forums/topic/front-end-form-image-upload-issues/#post-14656
Which didn’t fix it.
But did point me in (hopefully 😬) the right direction comparing it to your function.
The primary issue with my ‘user_has_cap’ function was it caused capabilities creep, giving participants the ability to edit others’ topics.
Prefacing my function with your ‘DOING_AJAX’ block seems to fix it: participants can upload and don’t have edit or mod rights for others’ topics.
Thanks again!
Francesca
For anyone who might be stuck on a similar problem, after a lot of searching, and trial-erroring, I came up with a bodged solution that deals with this, which uses $wpdb, so there’s no hardcoding a specific meta_key. Originally I bound this to ACF being active, but realised it can work for any post meta.
global $post;
// using $wpdb, grab all post_meta for the current post_id
// then ignore all meta_keys beginning with an underscore
// then search the all remaining ones for the shortcode
// if the post's meta_values has the shortcode anywhere, do stuff
global $wpdb;
$post_id = $post->ID;
$post_meta_sql = "select * from $wpdb->postmeta where post_id = {$post_id} and meta_key not like '\_%' and meta_value like '%[shortcode]%'";
$post_meta_results = $wpdb->get_results( $post_meta_sql );
// run the has_shortcode() as usual, works for all the_content() cases
if ( is_a( $post, 'WP_Post' ) && has_shortcode( $post->post_content, 'shortcode' ) ) {
// do stuff
return required_shortcode_js();
}
// for shortcodes in post_meta
else if ( is_a( $post, 'WP_Post' ) && ! empty( $post_meta_results ) ) {
// do stuff
return required_shortcode_js();
}
No idea what sort of performance hit doing this might cause, and can think of a number of cases where it could fail. There is a Core ticket open for this issue here: https://core.trac.wordpress.org/ticket/36958, which might be another way of doing it.
Hi John,
thanks for your quick and comprehensive reply.
I did search but didn’t find anything.
For me, I’ll stick with unintuitive, verging on a bug in the case where I actually deleted the contents of a field on a page and then hid that field by unchecking a conditional checkbox. I would expect that physical act of deleting to be carried over. (As distinct from if I just checked/unchecked a conditional field, I would expect the fields & data it shows would not be affected.)
Good to know about save_post_action also, thanks.
Turns out Simple Facebook Plugin is the cause. Disable it and things work as expected.
Hi @scheurta
ah, yeah! ok, that’s exactly it. Somehow I thought because the custom post types are ‘capability_type’ => ‘page’, ‘hierarchical’ => true I’d find them under pages. I would have never looked under ‘Post is equal to’, thanks!
Also having this problem on strato.de. Definitely something new as some of the sites have been using ACF5 for a long time with no problems.
Another one here. I have two identical sites (local and remote dev) the former updated to ACF 5.2 and fields using Page Templates vanished.
I could bring them back by changing the template under Page Attributes when editing a page, but this doesn’t hold when either reloading the page or opening it again.
Downgraded to 5.1.8 (same as on remote) and problem went away.
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 Cookie Policy. If you continue to use this site, you consent to our use of cookies.