In Chrome and Firefox, when editing a post that has custom field group with a repeatable group inside, the page loads normally in 1-2 seconds.
However, in Safari, the page takes over a minute to load. This is a relatively new issue, since we've had this sane field group unchanged for about 2 years. We've always been able to edit our custom posts in Safari with this field group and it's always opened within 1-2 seconds.
We have two people on staff who use Safari and they both report the issue. I tested it also on iOS/iPad OS Safari and the issue is there too (but not on mobile Chrome).
This issue is on both our main site (gangaji.org) and the staging copy (gangaji.cc).
Had you found any new info after that similar thread was closed? Is there any way to fix this?
I must apologize for the delay on this one as i've been waiting on the package to complete, however it would appear that it has failed to create the backup.
Failing this I would like for you to go through some of the basic debugging steps to see if we can identify the root cause of this.
If you're able to, can you temporarily disable all the non-toolset plugins and then check the page again. It could be a case where the browser isn't able to handle the requests efficiently given that this is only affecting Safari.
No worries, and thanks for the update. We're doing some other work on this staging server, so I'll only be able to disable all the plugins early next week. When they're disabled, I'll you know.
We disabled all the plugins on the server except toolset.
The issue still remains, though one thing I noticed which will hopefully help you diagnose the issue: In Toolset, when I switch the GF Events custom post type to use the Block editor the page loads fast. Only when I switch it back to use the Classic editor does the page have that delay in Safari.
Please let me know when you're finished testing, so I can re-enable all the plugins on the server for our other work on it.
Hi, Shane is on vacation this week so I'm taking a look at his open tickets. I hope that's okay.
The issue still remains, though one thing I noticed which will hopefully help you diagnose the issue: In Toolset, when I switch the GF Events custom post type to use the Block editor the page loads fast. Only when I switch it back to use the Classic editor does the page have that delay in Safari.
Okay interesting...can you confirm your Safari Users are experiencing the same long delays when they test now on the staging site, with only a limited set of plugins active?
I am currently seeing less than 5 seconds of delay with Safari active, but earlier I was seeing the longer delays you described. I can see that at least Oxygen is disabled now, because I remember seeing an Oxygen panel in the editor page that is no longer visible. So I'm curious to know if your Safari Users are still having extreme load times now that other plugins are deactivated.
Hi, yes, the delays of 40-70 seconds for the page to finish loading are still there. The delay is always on the part of the page with the repeatable group, about 3/4 down the page. I'm seeing it in my Safari (M1 native) and another staff member (Intel Safari) is seeing it.
We started trialing Oxygen about a month ago, but this Toolset delaying the edit post screen was there before then. I got complaints about it about 3 months ago, but didn't have time to look into it back then. I'm not sure if it started earlier. Apart from Oxygen, we hadn't added new plugins to the site in over a year, and we know this Toolset delay wasn't there last year, so something in an update of Toolset or Safari introduced it.
Hi Christian, I've narrowed down where the problem is. I ran a Timeline recording in Safari while the page was loading.
The load-scripts.php from WordPress took over 90 seconds to complete. When I drill down into that section of the timeline, there is a Toolset-related javascript function (a loop inside addConditionals from conditional.js in the Types plugin) that takes about 98 seconds to complete.
That addConditionals function works fine in Chrome/Firefox, and works ok in Safari when there is no repeatable group, but when there is such a group (possibly with conditional display rules), it takes abnormally long to complete. See the attached image. Hopefully this is enough for your developers to go on.
That addConditionals function works fine in Chrome/Firefox, and works ok in Safari when there is no repeatable group, but when there is such a group (possibly with conditional display rules), it takes abnormally long to complete. See the attached image. Hopefully this is enough for your developers to go on.
Okay thank you for the extra analysis - I crashed Safari several times yesterday trying to run the same timeline measurements and was never successful at producing a useful timeline. I see wptCallback.conditionalCheck.fire is responsible for most of the slowness there, but that line is toggled closed so I can't see any details about the stack within that row. Did you happen to export this timeline (link in the top right corner of the developer tools panel)? If so, can you post a link so I can download that and dive in a bit further? If not, an export would be helpful, or at least more screenshots showing activity currently hidden inside the collapsed .fire row. There will be numerous callbacks triggered by the .fire call, and more detail will be helpful for narrowing down the source of the bottleneck here.
Hi, I tried drilling down into it since I still had it open, but the slow calls went down pretty far so I ran it again and exported it. You can download it from our domain at /wp-content/safari-timeline-recording.json.zip
