Antony Booker
Forum Replies Created
-
Thanks for the update. Great support!
Yes, the admin notification removal snippet will save 1.15s here on every admin page view as it will stop the external CURL requests to Google’s API (this could be longer on some servers depending on the latency to Google).
I have also shared the slow log backtrace on the Github thread.
Yes I saw that post afterwards. This is very likely related removing the admin notifications from this plugin using that filter will stop the code continuing from this line:
apply_filters() google-listings-and-ads/src/Menu/NotificationManager.php:155Forum: Themes and Templates
In reply to: [OceanWP] Request: Add rel=”nofollow” to products per page linksThanks for the quick response. If possible please implement this into the core theme file so others can benefit from this enhancement.
As it isn’t a link that should be scanned by search engines it should have rel=”nofollow”. This will help to reduce server load and prevent unnecessary scanning by search engines.
Just confirming updating to the latest release 2.6.1 has fixed the issue.
Just checking if this was address in the latest releases? I’m still getting the issue on Version 7.2.13. Please let me know if there is anything I can do on the website side to fix the mismatch.
That was quick! Thanks for the quick investigation and turn around.
Forum: Plugins
In reply to: [Duplicate Post] Lots of ajax requestsYou may need to create another ticket as @mixha has marked this as resolved. Hopefully they will be able to resolve it in the future. I’ve had to replace the plugin with an alternative on multiple sites.
Forum: Plugins
In reply to: [Duplicate Post] Lots of ajax requestsJust following up if this will be looked into? 15,000 ajax requests is a lot.
Forum: Plugins
In reply to: [Duplicate Post] Lots of ajax requestsThe issue isn’t so much to do with the low resource issue of the ajax action itself but how ajax requests to WordPress are resource extensive by nature since they require the full WordPress stack to load (all plugins, theme, database connections and so on) on each ajax request.
For example I have a site that makes 15,000 requests to this ajax request daily. If we estimate it takes .5s for WordPress to load (it’s a large site on a fast dedicated server), then that’s 7,5000 seconds or 2 hours daily of 1 core spending time on these requests. If multiple editors or tabs are open this further takes away resource usage for front end traffic. On slower unoptimized servers these requests could take 1s+.
This occurs even when the admin toolbar menu for this item is set to be hidden in the plugin’s settings. Surely it won’t be necessary to make that many requests?
Hopefully that explains the issue further and the potential resource issue when many ajax requests are queried.Thanks for the reply. Yes I can confirm removing the @font-face lines will fix the issue as the Lato font is already called successfully in nextgen_admin_page.css.
Thanks for the clarification and explanation. Doesn’t appear this will be an issue anymore. Appreciate the response.
Actually it looks to be an issue with WP Bakery and the Uncode theme installed. Sorry for the confusion. I’ll do some more debugging and submit a support ticket within the week if needed.
Edit: I was able replicate on a blank install with only WP Bakery and the Cloudinary plugin and have reached out to the support email.- This reply was modified 1 year, 2 months ago by Antony Booker.
Hi Loic,
I was able to replicate the issue on a blank WordPress install with only the Cloudinary plugin and WP Bakery installed. Would you still like a system report sent to that address?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 INTOwp_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 );
}