hummelmose

What I have done now, is to download 1.6.2, and write 1.6.3 in the code, so it dont get updated by mistake, and then I hope 1.6.4 will solve the issue, but I think the developer is very quiet.

this message just to be notified on follow-up answers – sorry

I can verify that I have the same issue with the latest version. I also use Custom Fields Pro, so something is broken.

Sadly it sends notifications also on scheduled posts so NDA articles are sadly spread. We have shut down this plugin until the issue has been resolved.

I still have the problem with 3.1.1.

Adminbar is gone, and now there’s nowhere to fix it in code.

Same here – Crashed both test and prod. site.

Restored to old version, and were back up right away.

No. But I can attach my VCL file.

But just for info, I do have the same issues when bypassing the varnish all.

I will check my nginx config.

Thanks a mill.

What did you change in varnish. I also uses varnish ?

I can confirm the same behaviour as Array064.

If we post two artickes right after each other we experience that the second overwrites the first.

Thanks – I expected that.

But great you make a version that easily can clean up the “mess” ??

@compute – But with the fix in Taxonomy.php and the cleanup in my DB I don’t need it right ?

I made a hotfix plugin that stops WordPress from spamming the cron option:

https://github.com/phh/wp43-stahp-spamming-my-cron

Hi Patrick.

1. Where would you put it. In mu-plugin or in an ordinary plugin.

2. Since I’ve allready fixed the taxonomy.php and cleaned up my DB, do I need it?

@vangelis183 I thought about that , but there are just too much unknown stuff that can happen.

That’s why you should use a backup.

I use backup-buddy, and there it’s in cleartext per row.

It took me 10 seconds to write the sql and get back to normal.

You need to clean up all the cron jobs that “the fix” created.

The best way is to get the value from the cron field in wp_options from prior the upgrade.

It had inserted more than 5000 rows in my cron field, and that cost a lot of performance

I restored the cron field from prior wp 4.3 update with a

UPDATE wp_options SET option_value = ‘<insert old values here’ WHERE option_id = <insert option_id that holds the cron values>

My site is back to normal performance now