Support

Account

Register Login

Forum Replies Created

  • Hey – I arrived here from duckduckgo, and am looking for a way to deal with this issue.

    I hate that shortcodes always have <p> tags everywhere around them when using an ACF wysiwyg field.

    Any updates?

  • Does filtering acf/allow_unfiltered_html alone not work?

    Since you’re on a multisite, do superadmins have trouble as well?

  • I noticed this as well. Sorry if I’m just being dense, but I’m not sure how the priority could matter here, as the same variable is passed in both parameters.

        /**
	 * Filters the $value before it is updated.
	 *
	 * @date	28/09/13
	 * @since	5.0.0
	 *
	 * @param	mixed $value The value to update.
	 * @param	string $post_id The post ID for this value.
	 * @param	array $field The field array.
	 * @param	mixed $original The original value before modification.
	 */
	$value = apply_filters( "acf/update_value", $value, $post_id, $field, $value );

    I would also expect a call to grab the original value before line 188 if the original value was intended to be passed.

  • OK – I added if( !is_array($value) && !is_object($value) ) { before the wp_kses, and else writes to the error log so I’m aware that it is something that might need to get covered.

  • *remove

  • Are there any other field types that should be checked against that it would be bad to run wp_kses_post() on?

  • OK. I’m fine with normal content areas being filtered. Although, the nature of the filter seems kinda odd to me though, because if the super admin adds code to a post, then a non-super-admin comes along and updates the same post, the stuff the super-admin added will disappear.

    Anyway, this is the filter I made. It depends on the code field ending with ‘code’ in its name.

    // remove the html filter on all ACF fields
add_filter('acf/allow_unfiltered_html', 'wilirius_acf_allow_unfiltered_html_all_fields');
function wilirius_acf_allow_unfiltered_html_all_fields() {
    return true;
}
// re-apply filter to non-code fields
add_filter('acf/update_value', 'wilirius_acf_disallow_unfiltered_html_non_code_field', 1, 3);
function wilirius_acf_disallow_unfiltered_html_non_code_field($value, $post_id, $field){
    if(substr($field['name'], -4) !== 'code') {
        if(
            $field['type'] !== 'tab' &&
            $field['type'] !== 'group' &&
            $field['type'] !== 'repeater' &&
            $field['type'] !== 'flexible_content' &&
            $field['type'] !== 'clone'
        ){
            $value = wp_kses_post($value);
        }
    }

    return $value;
}

  • 1- Is there a security issue between acf_save_post(), and acf_update_value() if you let wp_kses go that far before running? I don’t see anything, personally, but all functions include acf_save_post, _acf_do_save_post, acf_update_values, acf_get_field, acf_update_value.
    2- Is this going to be a potentially very heavy hook to run?

  • How about true on ‘allow_unfiltered_html’ filter, and then run wp_kses() (or wp_kses_deep()?) on !code_field_id on the ‘acf/update_value’ filter?

  • Hmmm – maybe I’m thinking about this all wrong, but how would one filter acf/allow_unfiltered_html on only 1 field on a page? It seems like it’s either an all or none type situation.

    My use case is the same as others – I created a textarea field for code, but it gets filtered when a non-super-admin updates the page. I want admins to be able to edit that field, and all other users can edit other parts of the page (which will be kses’d), but the code field would not have it removed. I have the code field hidden from non-admins (good enough to prevent problems for now, although I might can improve on it with a validation hook that checks for updates by non-admins).

  • acf.validation.lockForm does not exist, but acf.lockForm does. Not sure if it changed to this, or just a typo, but it’s not working for me in any case for repeat submissions.

    I’m on 5.7.6, but reverting back to 5.6.10.

  • I kept the field as “library:all”, but filtered the media that could be seen like so (fill in your own USERTYPE):

    
/**
 * 	Limit media access to only their own media for certain users
 */
add_filter( 'ajax_query_attachments_args', 'mr_mp_filter_media' );
function mr_mp_filter_media( $query ) {
    if ( current_user_can( 'USERTYPE' ) || current_user_can( 'USERTYPE2' ) ) {
        $query['author'] = get_current_user_id();
    }
    return $query;
}

  • Definitely helps, good solutions & info, thanks a bunch.

  • Ahh yes that’s a great idea! I think I saw something like that before for saving the GPS lat/lng from the map field.

    Just to verify:

    • Hook in to the acf/save_post
    • Check for an update to the image selector field
    • Update a separate text field with the URL for the image from the image field

  • No luck with Rackspace Cloud Sites at 12:28pm GMT.

  • No.

  • Sounds good, let us know.

    When I discussed it with Rackspace they said that cURLing to the server resulted in 403 forbidden errors when attempting to connect to http://connect.advancedcustomfields.com/index.php?a=get-info&p=pro :

    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /index.php
on this server.</p>
<p>Additionally, a 403 Forbidden
error was encountered while trying to use an ErrorDocument to handle the request.</p>
<hr>
<address>Apache Server at connect.advancedcustomfields.com Port 80</address>
</body></html>

    and when trying to access http://assets.advancedcustomfields.com/add-ons/add-ons.json:

    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /add-ons/add-ons.json
on this server.</p>
<p>Additionally, a 404 Not Found
error was encountered while trying to use an ErrorDocument to handle the request.</p>
<hr>
<address>Apache Server at assets.advancedcustomfields.com Port 80</address>
</body></html>

  • The address:

    http://connect.advancedcustomfields.com/index.php

    After the index.php are usually arguments for what info is to be grabbed. For example, the get-info call (for checking the version):

    http://connect.advancedcustomfields.com/index.php?a=get-info&p=pro

    The function used to grab this data from a remote server is:

    wp_remote_post()

    (this function is called in ‘advanced-custom-fields-pro/pro/api/api-pro.php’, and is located in ‘wp-includes/http.php’)

    wp_remote_post() is a WordPress function. As Hube2 said, it creates a WP_Http object, going through a chain of functions, eventually resulting in either cURL or streams being used.

    The Wp_Http class is available to browse here:
    https://github.com/WordPress/WordPress/blob/master/wp-includes/class-http.php

    This file contains all the actual functions for handling any sort of remote connection.

    Inside the file, the 2 possible options (curl or streams) have classes associated with them.

    The class WP_Http_Curl handles the cURL session, setting up options and handling errors. This class contains all of the functions ran (stuff like curl_init, curl_setopt, curl_exec).

    If cURL isn’t used, then the class WP_Http_Streams handles the connection. This class contains all of the functions ran for the connection (stuff like stream_context_create, stream_socket_client ).

  • I believe it’s this:

    http://php.net/manual/en/function.stream-socket-client.php

  • @jsites Yea, trying it repeatedly did work on a stubborn site yesterday. Today though it doesn’t seem to be going through no matter what.

    @Loïc I think it just uses whatever WP usually uses to download updates, but with a custom server argument? I believe wp_remote_post/wp_remote_get are the functions used for getting other data from the server/

  • Well…it works for at least a couple sites. I have so far found one site so far that isn’t connecting. No idea what the difference is. I’ll be looking into it later though, while testing others.

  • I did the same thing Loïc.

    I’m not sure if something has changed on Rackspace’s end or ACF’s, but I am now getting updates to my Rackspace sites that are deployed to their own domain (that is, as opposed to sitting on an intermediate subdomain test link that rackspace provides while building a site…these sit on the websitetestlink.com domain).

    It works!1!!!!!!

    Has it resolved for anyone else?

  • Oh wow, I had no idea this had been marked solved, as it really isn’t.

    @Quantum, no, my key was purchased post 4->5, and the issue is a connection between 2 servers.

    I talked to my provider, they said they’re not sure what the issue is but they were seeing 403 Forbidden when trying to cURL to the addresses mentioned earlier in this thread. (ie http://connect.advancedcustomfields.com/index.php?a=get-info&p=pro)

    They originally thought that maybe the servers were blocking some IPs. Potential IPs that the ACF Host may be blocking/denying:

    Primary: 184.106.10.128
    Secondary: 184.106.10.129 – 184.106.10.135 | 184.106.55.253

    Or it could be that there needs to be some sort of verification/authentication that is not getting through on the POST.

  • Yea it’s definitely not a bug with the plugin’s code. It’s been apparent the problem is an incompatibility between many different hosts and the current ACF host. I’ll talk to my host and see if they have any ideas.

    The issue is how inefficient it is to manually update the plugin that is in fairly continuous development, and that many people seem to have this problem. I appreciate that you have stuck with it Hube2. Thank you.

    I’ll report back if I learn of/hear about/come up with any solutions.

  • Yea, it’s quite a big bug that I believe could be fixed maybe by having a secondary download site or investigating the issues with the current host environment.

    If you have only 1 site to worry about it isn’t that big of a deal, as you only have to go into your FTP, delete the old files, and then upload the new ones about once every two weeks. That’s maybe 10 minutes a month.

    But if you have 100+ sites, that’s at least 15 hours a month, just for updating one plugin on every website manually, twice a month.

    And the problem grows with every new site you create.

    Has anyone tried emailing support?

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