FWIW, I’ve read: https:\/\/theeventscalendar.com\/support\/forums\/topic\/timeout-when-saving-recurring-events\/<\/p>\n
Most recurring events can be edited\/updated. Several however, particularly those that repeat a lot (ie. daily) fail when updated, timing out after 60-90s and redirecting to an nginx 502 page at \/wp-admin\/post.php.<\/p>\n
Like this one:
\ndomain.com\/wp-admin\/post.php?post=40811&action=edit
\nscreenshot of recurrence pattern: https:\/\/cloudup.com\/cmlzHahXTOB<\/p>\n
It doesn’t surprise me WPE kills long running PHP processes at 60 seconds, most hosts do. It does surprise me that TEC isn’t doing something to avoid this timeout though. I think there is something else that might be going on here.<\/p>\n
I’ve cloned the site to WPE staging for testing. It fails there the same. I deactivated all the plugins that weren’t a Tribe Events plugin and reverted to the 2014 theme. I thought it worked the first time I hit update on that one post, but then on many many repeat attempts it’s failed, so we’ll call that first one a false success. Maybe I was on the wrong post.<\/p>\n
FWIW, I did successfully update this post on my local install twice, each time it took 4 minutes (VVV, PHP5.5, 4 CPUs, 1024MB) with all plugins activated as normal the first time. Oddly after deactivating everything and trying again it ran 10 minutes before I killed it.<\/p>\n
Note: The DB for this site isn’t small, but it’s not really big either. 12,000 posts, 6000 comments, 200 categories, 11,000 tags.<\/p>\n
This is Jon Brown (developer) not the actual client\/licenses holder. Outside this forum I can give you a url and login to staging if you need.<\/p>\n","protected":false},"template":"","class_list":["post-826758","topic","type-topic","status-closed","hentry"],"yoast_head":"\n