Jo Sprague

Here’s some more info about the issue in case other people experience something similar;

Our host has a process that runs as a part of their built in security hardening that removes any .php files in the uploads directory since that’s a common attack vector. To resolve the issue, I just had to store the Sucuri settings somewhere other than the uploads directory, so I created the directory /absolute/path/to/wp/install/wp-content/plugins/sucuri-settings and added define('SUCURI_DATA_STORAGE','/absolute/path/to/wp/install/wp-content/plugins/sucuri-settings'); in my wp-config.php.

Daniel, maybe in future versions of the plugin you could consider changing the default storage location for the settings php files to be in the plugins directory instead of uploads. The uploads directory may not be the most secure location even with the exit() lines for several reasons. For example; sometimes people copy and paste their upload directories via FTP expecting it to just be uploaded media and not to contain sensitive data.

I wonder if you’d also be able to offer an option to store the settings in either the database or the filesystem, as I could imagine a use case where people prefer to continue storing their settings in the database.

It looks like our host has a service running that may be renaming files in the uploads directory with that postfix. I’ll see if they can add an exception for the uploads directory. Closing this for now. I’ll reopen it again later if that turns out to not be the issue.

@yorman I figured out that the answer I was looking for was to make sure that Reverse Proxy Support is Enabled and IP Address Discoverer is Disabled. Once I set those settings, my performance is back up to normal speeds. Thanks!

Alright, I tracked down what the problem is. It’s related to mu-plugins. When the $full_url passed in was an mu plugin url, for example; “https://mysubdomain.com/wp-content/mu-plugins/force-strong-passwords/force-zxcvbn.min.js” the domain_mapping_plugins_uri() function was just taking the last character of the string (results of stripos -1) to be the plugin path since PLUGINDIR wasn’t found in the string. Rather than relying on a plugin directory constant, if I just parse the URL with PHP to replace the domain, it seems to work more reliably. I did this;

// Replaces the domain in the plugins URL with the mapped domain for the site
function domain_mapping_plugins_uri( $full_url, $path=NULL, $plugin=NULL ) {
	$url_path = parse_url($full_url, PHP_URL_PATH);
	$url_query = parse_url($full_url, PHP_URL_QUERY);
	return get_option( 'siteurl' ) . $url_path . $url_query;
}

Of course, that will be overwritten next time I update. Ron, if you’d like I can try to make a PR, but I’m not sure where that’s done. Is there a Subversion repo somewhere?

Thanks @mardala, the issue I’m having is definitely related to that line. I just tried your fixes, and it ends up breaking more asset URIs than it fixes (instead of just one having an extra s appended, a bunch are missing the / before the query string. I’ll look into it a little more to see if I can figure out what’s going on here.

Ron, I’m not sure what you mean about editing the domain and path of the sites in network admin -> sites -> edit site. The sites that I’m working on have been migrated several times, so I’m sure that field has been changed in the past, but I’ve checked and the current values look correct.

Hi, you might have to edit the WordPress profile for the author of the post and add the Twitter handle in there. Does that work?

You can add it to any file, as long as that file is being executed. I’d recommend adding the following to an activated plugin’s functions.php (maybe to the JSON REST API plugin, but be careful that it doesn’t get overwritten with updates);

add_action( 'init', 'allow_origin' );
function allow_origin() {
    header("Access-Control-Allow-Origin: *");
}

It’s almost certainly a conflict with the theme you’re using, but I need more information to know what the issue is. Do you have a link to the live website so I can see how the page is built? Otherwise, do you have a before/after screenshot that you can send? I don’t have any context for the one you linked to, so I don’t know what’s going on.

Turns out the issue was with bad theme code that set is_front_page() to false. Doing wp_reset_query() at the bottom of the homepage template solved the issue. No idea why it didn’t show up on the old host. Probably different caching rules or something.

Hi brandecho, it should work in either place. They key is the add_filter line. That makes it run whenever the json_prepare_post hook runs. That being said, it’s generally a bad idea to modify another person’s plugin directly, since your changes would be overwritten in the next update. I’d recommend adding this either to your theme’s functions.php file (easiest) or to a custom plugin’s functions.php. Good luck!

Thanks for the kind words Dan! ??

Hi Dan,

You’ll find there is a global setting under Dashboard > Settings > Discussion > Quotable

Hopefully that helps.

Unfortunately, this plugin is only designed to take advantage of the standard WordPress page editor. I don’t have the time or resources to support third party page building tools like Make. But if there are any conflicts or bugs, I’ll be happy to take a look if you can provide details.

Here is the function I wrote to use types_get_fields_by_group() instead;

// Add custom fields created by Types plugin to public types_custom_meta key
function add_types_custom_meta($data, $post, $context) {
    if (function_exists(types_get_fields_by_group)) {
        $post_custom_data = get_post_custom( $post['ID'] );

        // Get a list of Types custom fields in the "public" group
        $public_types_fields = types_get_fields_by_group('public');

        foreach ( $post_custom_data as $key => $value ) {
            if ( in_array($key, array_keys($public_types_fields)) ) {
                $types_custom_meta[$key] = $value;
            }
        }

        if ( !empty($types_custom_meta) ) {
            $data['types_custom_meta'] = $types_custom_meta;
        }
    }

    return $data;
}
add_filter( 'json_prepare_post', 'add_types_custom_meta', 10, 3 );

I tried using types_get_fields_by_group('public') to only get fields within a group named public, but so far I haven’t been able to get that to work.

I was able to apply the following function with the json_prepare_post filter to get all custom fields created by the Types plugin into the WP-API post response under the types_custom_meta key. The Types function I needed was types_get_fields().

// Add custom fields created by Types plugin to public types_custom_meta key
function add_types_custom_meta($data, $post, $context) {

    $post_custom_data = get_post_custom( $post['ID'] );

    // Get a list of custom fields added by Types plugin
    $all_types_fields = types_get_fields();

    $post_custom_types_fields = array();
    foreach ( $all_types_fields as $key => $value ) {
       $post_custom_types_fields[] = $value['meta_key'];
    }

    foreach ( $post_custom_data as $key => $value ) {
        if ( in_array($key, $post_custom_types_fields) ) {
            $types_custom_meta[$key] = $value;
        }
    }

    if ( !empty($types_custom_meta) ) {
        $data['types_custom_meta'] = $types_custom_meta;
    }

    return $data;
}
add_filter( 'json_prepare_post', 'add_types_custom_meta', 10, 3 );