dionsis

Figured this one out

It was my nginx configuration ,apparently WP Super Cache doesn’t work well with $args at the end of the index.php. So I removed that and it’s now creating static files. FINALLY!

try_files $cachefile $uri $uri/ /index.php?q=$uri&$args ;
became
try_files $cachefile $uri $uri/ /index.php ;

Now to track the results in New Relic and see how much load it takes off the server.

Yeah it’s getting to the point now where I might have to just take the active decision to remove this plugin. It’s useful in what it does but it’s causing too many issues.

I had done that before posting, but I tried it again for the sake of it.

It looks to be working now. What I did was change a load of the setting in there to the opposite of what they were. Changed them back and saved and then it started working. Just incase that helps anyone else if they experienced the same thing.

It’s a custom theme built be an agency, so swapping that out isn’t an option.

The plugin worked just fine on this theme and plugin set before, and nothing in the theme has changed. So I wouldn’t imagine the theme is at fault if it worked fine before.

Latest version. Both Plugin and WordPress

Tried disabling all my plugins, no joy there either.

No duplicating for me either

I’m trying to duplicate something from one post type. It’s creating a new post, but it’s creating it in the default post type and not the post type I’m creating.

It then also has no content, the title of the post created is just “Copy” and nothing else. The post is empty.

I notice the plugin updated recently, it worked perfectly before this. What has changed in the latest update?

Welcome dude!

Cloudflare caching was the problem. Old version of the JS was being stored.

Sorted now.

A year on and it’s still doing this any idea’s?

PHP-FPM user is set as nginx
Nginx user is set as nginx
1st of every month it creates a new directory with user:group root:root and I have to manually intervene.

What kind of extra statistics are you getting?

newrelic_set_appname($app_name .’ ajax;Site Rollup’ );
newrelic_set_appname($app_name .’ admin;Site Rollup’ );
newrelic_set_appname($app_name .’ cron;Site Rollup’ );
newrelic_set_appname($app_name .’;Site Rollup’);

This is how I’ve got it set. Looks similar to yours. This rolls all those for the same site up into the one rollup.

Nothing solid but removing Varnish cache from my setup has created all kinds of speed increases across the board.

OK I might have a potential reason for the length of time of WP-CRON.PHP

It seems that priming the cache was one of the longest running items on my site.

I’ve also managed to see that a function called google_analytics_async request was slowing down my admin-ajax.php so I’m looking into that now.

I wouldn’t disable heartbeat, it is quite functional and allows you stuff like quick edit and tag related stuff.

I don’t understand what in it takes so long to run. It’s fine running it every 15 seconds if it takes 1 second to run. How it’s taking thousands of seconds. I don’t know.

It most definitely is related to an update.

recently WordPress Heartbeat API was introduced. This is what (on the admin side at least) is calling the admin-ajax.js which in turn I believe called heartbeat.js in the /wp-includes/js/heartbeat.js file.

If any plugin uses heartbeat for AJAX functions, that’s another call.

So I have multiple writers, they use the backend through the day and may each have multiple tabs open. Each tab starts a new heartbeat that tries to load the file every 15-60 seconds.

For some reason the admin-ajax.php file is taking a very long time to run. It might be down to the reason I have 10,000 posts in my wordpress install. I’d like to think scale wasn’t part of the issue but it probably is.

So in the heartbeat.js I saw that numbers defined the frequency of the heartbeat, so I’ve tried by changing 60 to 180 so that it runs every 4 minutes instead of 15 seconds. I don’t know if this has had any effect but I’m trying to track it.