Support

Account

Forum Replies Created

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

Viewing 7 posts - 1 through 7 (of 7 total)