Antony Booker

I looked into this further and was able to get the is_deliverable filter to work to ignore the embed mime types:

add_filter( 'cloudinary_is_deliverable', function( $is, $attachment_id ) {
    $mime_type = get_post_mime_type( $attachment_id );
    if ( strpos( $mime_type, 'oembed' ) !== false ) {
        return false;
    }
    return $is;
}, 10, 2 );

It turns out the theme (uncode) allows custom attachment types which can be added without a URL/guid perhaps by mistake by the client, and can be replicated with the below SQL insert of an attachment:

INSERT INTO wp_posts (ID, post_author, post_date, post_date_gmt, post_content, post_title, post_excerpt, post_status, comment_status, ping_status, post_password, post_name, to_ping, pinged, post_modified, post_modified_gmt, post_content_filtered, post_parent, guid, menu_order, post_type, post_mime_type, comment_count) VALUES
(7786, 24, '2025-03-24 00:47:50', '2025-03-24 00:47:50', 'Test', 'Test', '', 'inherit', 'closed', 'closed', '', 'test', '', '', '2025-03-24 00:47:50', '2025-03-24 00:47:50', '', 0, '', 0, 'attachment', 'oembed/youtube', 0);

With the missing URL the function to update the URL with the CDN version would return a fatal error:

// Previous v1 and Cloudinary only storage.
if ( false !== strpos( $url, 'https://', 5 ) ) {
	$dirs = wp_get_upload_dir();

	return str_replace( trailingslashit( $dirs['baseurl'] ), '', $url );
}

Thanks for the reply. That directory only has the font files for FontAwesome.

I searched through the plugin and found the Lato font file here:
nextgen-gallery\products\photocrati_nextgen\modules\nextgen_admin\static\Lato-Regular.ttf

Would you be able to update the link within the plugin’s stylesheet above to that location? or remove that font reference if it’s not required? as its currently returning a 404 error in the block editor.

Thanks for the quick reply. Having the disable option is great but would it be possible to remove the brands font family reference from the FA stylesheets in the plugin as font awesome is often used on the sites.

As the plugin doesn’t include the brand font files but declares the font family some browsers may try to download the brand fonts from this plugin but the files will be missing.

I wasn’t able to replicate the sitemap issue. However the function and that file is the same from what I can see? As it’s called within wp_enqueue_scripts it might have unexpected problems and conflicts.

The two issues are:
1. content echo’d in wp_enqueue_scripts
2. wp_print_inline_script_tag used incorrectly with an “echo” in front

Something like this would be more suitable if you are wanting to output javascript variables to the page when loading a javascript file:

public function load_inline_script() {
    $script_handle = 'your-main-script-handle'; // Replace with the handle of your enqueued script

    $js_inline = '
        var theplus_ajax_url = "' . admin_url("admin-ajax.php") . '";
        var theplus_ajax_post_url = "' . admin_url("admin-post.php") . '";
        var theplus_nonce = "' . wp_create_nonce("theplus-addons") . '";
    ';

    wp_add_inline_script($script_handle, $js_inline);
}

Or if only the inline script is needed the script could be loaded using the wp_head action:

public function load_inline_script() {
    add_action('wp_head', function() {
        ?>
        <script type="text/javascript">
            var theplus_ajax_url = "<?php echo esc_url(admin_url('admin-ajax.php')); ?>";
            var theplus_ajax_post_url = "<?php echo esc_url(admin_url('admin-post.php')); ?>";
            var theplus_nonce = "<?php echo esc_js(wp_create_nonce('theplus-addons')); ?>";
        </script>
        <?php
    });
}

Thanks for the quick patch. The rest api endpoints are responding again..

Thanks for the reply.

The bottleneck appears to be when “ORDER BY meta_id ASC;” is in the query with the high performance keys which results in a high creating sort time.

Here is a profile of the query with high performance indexes on the postmeta table taking .13s:

Duration: 0.13756471s

Starting: 0.000143s
checking permissions: 0.000006s
Opening tables: 0.000009s
After opening tables: 0.000007s
System lock: 0.000004s
table lock: 0.000005s
init: 0.000080s
Optimizing: 0.000033s
Statistics: 0.000248s
Preparing: 0.000017s
Sorting result: 0.000006s
Executing: 0.000004s
Sending data: 0.000006s
Creating sort index: 0.136885s
End of update loop: 0.000020s
Query end: 0.000004s
Commit: 0.000004s
Query end: 0.000004s
closing tables: 0.000004s
Unlocking tables: 0.000004s
closing tables: 0.000005s
Query end: 0.000005s
Starting cleanup: 0.000004s
Freeing items: 0.000016s
Updating status: 0.000013s
Logging slow query: 0.000024s
Reset for next command: 0.000006s

ALTER TABLE wp_postmeta
  ADD PRIMARY KEY (post_id,meta_key,meta_id),
  ADD UNIQUE KEY meta_id (meta_id),
  ADD KEY meta_key (meta_key,meta_value(32),post_id,meta_id),
  ADD KEY meta_value (meta_value(32),meta_id);

Postmeta rows: 2,019,801 461.4 MiB	

And a profile with the standard indexes taking .05s

Query ID: 1 Duration: 0.05160964s

Starting: 0.000139s
checking permissions: 0.000006s
Opening tables: 0.000009s
After opening tables: 0.000006s
System lock: 0.000005s
table lock: 0.000005s
init: 0.000084s
Optimizing: 0.000035s
Statistics: 0.000251s
Preparing: 0.000027s
Sorting result: 0.000006s
Executing: 0.000004s
Sending data: 0.000006s
Creating sort index: 0.050946s
End of update loop: 0.000019s
Query end: 0.000005s
Commit: 0.000004s
Query end: 0.000004s
closing tables: 0.000004s
Unlocking tables: 0.000004s
closing tables: 0.000004s
Query end: 0.000005s
Starting cleanup: 0.000004s
Freeing items: 0.000015s
Updating status: 0.000009s
Reset for next command: 0.000006s

ALTER TABLE wp_postmeta
  ADD PRIMARY KEY (meta_id),
  ADD KEY post_id (post_id),
  ADD KEY meta_key (meta_key(191));

Postmeta rows: 1,759,255 294.0 MiB

Could the longer times simply be from the larger database size with the extra indexes?

Thanks for the quick reply. I’d recommend reinstating the filter or if it’s no longer applicable adding a deprecated code message if the filter is added.

Looks like it adds the script to any file in the theme that has functions in the filename. I’d recommend restoring a backup of the themes folder or searching the folder for “my_admin_init_function_run” to remove that code.

You’ll need to manually check the functions.php file in the theme (usually under wp-content/themes/yourtheme/functions.php and remove the suspicious code, such as with a file manager in the hosting control panel or by using FTP.

The injected code will look like this at the top of the functions.php file:

if (!function_exists('add_footer_script')) {
function add_footer_script() {
	update_option('my_admin_init_function_run', 'yes');
	echo '<script>eval(......);</script>';
}
$has_run = get_option('my_admin_init_function_run');
if ($has_run !== 'yes') {
	add_action('wp_footer', 'add_footer_script');
}
}

@benzoid glad you were able to regain access quickly.

There seems to be some confusion, to confirm the issue is with the code added in the patched version 11.9.7 by the plugin review team that loops through and finds vulnerable administrator usernames, that had been added in previous versions.

Specifically the get_users?function which is looping through all users in the PowerPress_PRT_incidence_response function. This could be changed to loop through admin users only to prevent high cpu usage on sites with lots of users.

• This reply was modified 9 months ago by Antony Booker.

Yes this code is in the force updated version from, 11.9.7 that checks for vulnerable usernames.

Thanks for the response. Those snippets relate to changing cron jobs, however forminator uses the action scheduler instead:

/**
 * Set up the schedule
 *
 * @since 1.0
 * @since 1.27 Change from WP cron to Action Scheduler
 */
public function schedule_entries_exporter() {
    // Clear old cron schedule.
    if ( wp_next_scheduled( 'forminator_send_export' ) ) {
        wp_clear_scheduled_hook( 'forminator_send_export' );
    }

    // Create new schedule using AS.
    if ( false === as_has_scheduled_action( 'forminator_send_export' ) ) {
        as_schedule_recurring_action( time() + 10, MINUTE_IN_SECONDS, 'forminator_send_export', array(), 'forminator', true );
    }
}

This is triggering an action scheduler http request every minute.

I couldn’t find a similar filter for changing the action scheduler task frequency.

Do those tasks need to run every minute? especially for the forminator_process_report hook as only hourly can be selected in the backend for report notifications. I’ll keep investigating if there’s a way to remove the extra requests.

Thanks for the reply.

The external request to the sift URL is found within the admin_print_footer_scripts action in the woocommerce-services\woocommerce-services.php file on line #897:
add_action( ‘admin_print_footer_scripts’, array( $this, ‘add_sift_js_tracker’ ) );

This will load the “add_sift_js_tracker” function on every admin page which then requests https://api.woocommerce.com/payment/sift

This can be seen below in the add_sift_js_tracker function which calls “get_sift_configuration” that makes the HTTP request to the woocomerce.com/payment/sift URL

    public function add_sift_js_tracker() {
        $sift_configurations = $this->api_client->get_sift_configuration();

    public function get_sift_configuration() {
        return $this->request( 'GET', '/payment/sift' );
    }

Looking at the changelog for this plugin I can see that Sift was added for printing labels? I’m not sure where the print label function is used. Would this need to be loaded on every admin page?

2.3.7 – 2023-10-23 =
* Add – Load Sift when printing a label.

Here is a tool to see the response time of that request from around the world:
https://tools.keycdn.com/performance?url=https://api.woocommerce.com/payment/sift

From Sydney it’s taking .74s to respond . This adds .74s to the backend page generation whilst WordPress waits for the request to finish.

• This reply was modified 10 months, 1 week ago by Antony Booker.

Sorry for the confusion. I’m not requesting any custom code as I can code this per site. But hopefully it will be possible to get this plugin compatible with the relevanssi search plugin in general for other sites.

Currently when both plugins are installed draft statuses show in search results due to how the relevanssi plugin checks if a user can access a post in Simple Membership using the can_i_read_post function.

Other membership plugins have similar filters to check if a user should have access to a post that isn’t in a draft/private status, however using the can_i_read_post it doesn’t check if a post is published or not. Should the can_i_read_post function be set to check that?

I have reached out to Relevanssi regarding this but they couldn’t say why the SM plugin did this. If this isn’t a suitable filter to use in general for other plugins I can reach out to Relevanssi again to recommend they change their code to prevent draft posts showing in search results.

Thanks for the correction, it was running but yes you’re right it should be add_action and wouldn’t need the post returned. I have added it below in case other users may wish to use it:

add_action('the_post','filter_content_post', 999, 1);
function filter_content_post($post){
	if (!class_exists('SimpleWpMembership')) {
		return $post;
	}

    if (is_preview() || is_admin()) {
        //If the user is logged-in as an admin user then do not apply filtering for admin side viewing or preview page viewing.
        if ( current_user_can('administrator') ){
            //The user is logged in as admin in this browser.
            return $content;
        }
    }
    $acl = SwpmAccessControl::get_instance();
	$content = $post->post_content;
    $post->post_content = $acl->filter_post($post, $content);
}