Support

Account

Register Login

Forum Replies Created

  • That’s a nifty little recursive function you made. Would that be called like this?

    add_filter( 'acf/update_value', 'acf_wp_kses_post', 10, 1 );

    I haven’t tried that yet, but I do want to clarify that my code in the initial post works on repeater fields. If someone knows they will not use a certain field on their site, they can delete that line. The main goal is just to ensure that the function doesn’t get run on a repeater itself.

  • Although a one-line solution would be nice, I think the most imperative thing is simply updating the documentation. I feel like I need to be clear that the current recommendation on there is DANGEROUS to anyone using repeater and FC fields.

    In my case, I came across the suggestion, thought “more security and XSS removal is good”, installed it and tested it without testing the more complex fields. That was sitting on my website for about a week, until a user finally contacted me telling me that their fields were “weird” and they couldn’t figure it out. That means that any user who updated their listing on my site that week would have destroyed any data they had previously entered into a repeater field, even if they were just changing one simple field.

    Not only is the current documentation potentially harmful, but at the very least it’s confusing to determine what the problem is. Is there somewhere else I should be recommending documentation changes?

  • It’s also worth noting that if the user has any access to the backend, those filters should be placed in functions.php, and then they would no longer need to be added above acf_form_head.

  • I’ve added some more guidance on this thread.

  • I was also having trouble with this. All of the fields in repeaters were converting to “A”, and it was hard to tell why. I think there should be a note of this made on the documentation for acf_form.

  • Although the hack by @joelgoodman works, it would be nice to see ACF compatible with add_editor_style

  • Just to follow up, this appears to be working in ACF 5 without any custom code needed.

  • You’re totally right… I should have checked my code. In thinking about it, it makes perfect sense: you are checking that the user is not an admin and that AJAX is not being run (which would be in the backend). I went back to my implementation of it, which is quite a bit more complex due to the nature of my site, but I am effectively doing the same thing. I guess I just got confused when I applied the logic to your instance on here. Sorry about that! Glad it’s working for you.

  • I think it’s because you have && ! (defined( 'DOING_AJAX' ) instead of && (defined( 'DOING_AJAX' )

    Also, I think that checking for is_admin() is redundant, since you’re using the admin_init action, which only runs on an admin screen.

  • Here’s what I’m doing, and I can confirm that it works in Safari with ACF 5. DOING_AJAX is a global constant… is there a reason why the value needs to be confirmed? I’m just making sure that it’s set to something other than FALSE.

    add_action( 'admin_init', 'redirect_admin' );
function redirect_admin() {
	if ( ! current_user_can( 'manage_options' ) && defined( 'DOING_AJAX' ) && DOING_AJAX ) {
		wp_redirect( site_url() );
		exit;
	}
}

  • That’s a creative solution, albeit somewhat hacky. Unfortunately, my community site uses only ACF frontend forms to manage user-created posts, and edit_form_after_editor doesn’t get called on the frontend.

    I’m also not sure I’m in love with the idea of adding an extra input field to every editor page across WP, including media, forums, and even ACF field groups, regardless of whether ACF fields are on that post or not. It would be nice to see some functionality built into the core of the plugin.

    But since I am calling a frontend form, maybe there’s a way to add an extra input to the template itself, or possibly a parameter on the acf_form function. I haven’t played around with it yet but it’s worth a shot.

    P.S. @jsilver I couldn’t submit a comment to your site because of a recaptcha error.

  • I’ve also noticed that ACF support has been less reliable in the last few months. It’s possible that Elliot has received a sudden influx of users since the launch of ACF 5 and figuring out how to adapt. Fortunately, he’s still pushing out new features.

    I’m not sure if this will completely answer your questions, but here’s a start. Here’s how I think you need to setup your function call:

    acf_form( array(
	'post_id' => 'new_post',
	'new_post' => array(
		'post_type' => 'company',
		'post_status' => 'publish',
	),
	'field_groups' => array(24),
	'post_title' => true,
	'post_content' => true,
) );

    You’d call that in your template file with acf_form_head called at the top (above get_header). No need to mess with actions or filters in your functions.php file unless you want to do further customization.

  • Ha! Wow, I feel dumb now. It must have still been using the beta dev license. Don’t know why I didn’t think of that, but thanks a bunch!

  • It sounds like your trying to do too much hacking with the core functionality here. Uploading to a custom folder would actually be messing with WP’s system, not really ACF’s.

    I’d recommend you leave the system as-is and just grab the gallery images in your template file, creating the CSS on the fly right there. You wouldn’t be able to place this CSS in style.css but you’d have the ability to adjust the images from the gallery field and maintain the flexibility you want.

  • To answer my own question, I stumbled on the validate_value filter, which allows me to do this. In my case, I simply wanted the input from the location field to include a city and state in the “San Francisco, CA” format, so I accomplished it like this:

    function google_map_acf_validate_value( $valid, $value, $field, $input ) {
	if ( ! $valid ) { // bail early if it's already invalid
		return $valid;
	}
	
	preg_match( '/([^,]+), ([A-Z]{2})\b/', $value['address'], $matches );
	if ( ! $matches ) { // City was not found
		$valid = 'Address must include city and state';
	}
	
	return $valid;
}
add_filter( 'acf/validate_value/type=google_map', 'google_map_acf_validate_value', 10, 4 );

  • When you set the page as a posts page, you’re creating an archive page that is likely using a different template than a single post or page would. It’s possible to show the page’s fields on the posts page, but you would need to manipulate the code in the template that’s getting used.

    The problem is that when you run the loop on the posts page, you’ll get data for the first post, not the page itself. You could get the info about the page with this:
    $query_object = get_queried_object();
    And then you can use the page’s ID to grab the fields from it.

  • First of all, you should stick your function at the top in functions.php

    But to answer your question, the post_title and post_content settings are only available in ACF 5. When you look at that tutorial, make sure you’ve selected “Version 4” at the top. But more importantly, I’d suggest you upgrade to ACF 5 to do more advanced front-end forms.

  • This is fixed as of 5.0.7

  • I look forward to when Elliot gets the “previous versions” section on the account page, because it’s really not yet time to upgrade for some of us.

    Here’s the 5.0.4 archive: https://docs.google.com/file/d/0B3eCykPC9JSec0U0cVlRV0FDV2M/edit
    I’ll take it down later today.

  • I just downloaded the latest, and I am confirming that while the tabs now work, the single select taxonomy field fails to load.

  • This is possible in ACF 5 using the new “post_title” parameter in the acf_form function.

  • Good catch @John Wilson. We’re definitely running bbPress too.

  • Thanks for responding. It’s not a caching issue… it occurred in all browsers, in incognito, and on the live server and localhost.

    I have temporarily bypassed the issue by getting post IDs and then calling get_post on those IDs… I thought that would indicate that there is not a conflict on my site. However, I should have checked this with a fresh WP install, and now I have and I can see that it works there. So it’s something site-specific… sorry about that, please disregard.

  • @thx1138, I’m not sure if this is the best way, but here’s how I do it. Instead of setting post_id to “new”, I set it to “new_post-type”, then I use that to specify the post type in my_pre_save_post:

    function my_pre_save_post( $post_id ) {
    $type = explode( '_', $post_id, 2 );
    if ( $type[0] != 'new' ) // Check if this is a new post
        return $post_id;

    // Create a new post
    $post = array(
        'post_status' => 'publish',
        'post_title' => 'Untitled',
        'post_type' => $type[1]
    );
    $post_id = wp_insert_post( $post ); // Insert the post
    do_action( 'acf/save_post' , $post_id ); // Save the fields to the post
    wp_redirect( add_query_arg( 'updated', 'true', get_permalink( $post_id ) ) ); exit; // Redirect to the new post
    return $post_id;
}
add_filter( 'acf/pre_save_post' , 'my_pre_save_post' );

  • @elliot, I figured as much. I tried a number of things before coming here, so I supposed that the feature hadn’t been included yet. Maybe with some guidance I can help get this into a future version.

    I’m just using the standard add_editor_style() to add custom styles to the backend wysiwyg boxes. This custom style works on both the_content and on acf wysiwyg fields.

    The custom style doesn’t work on the wysiwyg fields on the frontend. Looking at the source, there is a JS object called “tinyMCEPreInit” in the footer, which contains an element called “content_css”, which holds the url of the custom stylesheet. “tinyMCEPreInit” on the frontend looks similar to what’s on the backend, except that it doesn’t have the “content_css” element.

    I looked in the plugin and it looks like ACF might have a homegrown version of the wysiwyg field? I couldn’t tell if you’ve switched to using wp_editor() yet.

    wp_editor() has an argument called “editor_css”, presumably for that “content_css” element. If acf’s system is homegrown, maybe it would be possible to add an “editor_css” argument to the $options array for acf_form(), which could hold the url of the editor stylesheet. Or better yet, it would be nice if it just used the same logic to know when I’m calling add_editor_style(), which gets called through the ‘init’ action, so it should be available on the frontend.

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