Skip Navigation

[Escalated to 2nd Tier] Safari issues with repeatable field groups

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Our next available supporter will start replying to tickets in about 8.48 hours from now. Thank you for your understanding.

This topic contains 18 replies, has 3 voices.

Last updated by catherineR-2 1 month, 1 week ago.

Assigned support staff: Christian Cox.

Author
Posts
#2123619

Similar to this issue: https://toolset.com/forums/topic/performance-of-repeatable-field-groups-with-conditional-fields-on-safari-browser/

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?

#2123629

Shane
Supporter

Languages: English (English )

Timezone: America/Jamaica (GMT-05:00)

Hi Catherine,

Thank you for getting in touch.

Would you mind allowing me to have admin access to the website as well as a link to the backend page where you are having issues with the load time?

I've enabled the private fields for your next response.

Thanks,
Shane

#2125433

Shane
Supporter

Languages: English (English )

Timezone: America/Jamaica (GMT-05:00)

Hi Zubin,

Would it be ok to grab a copy of this site with the Duplicator plugin to provide to our 2nd tier support team for further debugging ?

I was able to experience the issue on safari here as well.

Thanks,
Shane

#2125553

Hi Shane,

Sure, you can install Duplicator. It's a large database though, over 2GB, so as long as Duplicator can handle that.

thanks,
Zubin

#2125693

Shane
Supporter

Languages: English (English )

Timezone: America/Jamaica (GMT-05:00)

Hi Zubin,

Thank you but i'm not seeing where the Duplicator plugin has been installed.

My account isn't able to do it as I tried to install it from the Super User dashboard for your Multi Site but the Add New option wasn't available.

Can you install it and let me know .

Thanks,
Shane

#2125695

Oops, sorry about that. I installed and activated it. It's on the second page of the blue menu.

thanks,
Zubin

#2125735

Shane
Supporter

Languages: English (English )

Timezone: America/Jamaica (GMT-05:00)

Hi Zubin,

Thank you i've started doing the build package for the duplicator but it is taking some time.

#2128245

Shane
Supporter

Languages: English (English )

Timezone: America/Jamaica (GMT-05:00)

Hi Zubin,

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.

Thanks,
Shane

#2128405

Hi Shane,

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.

thanks,
Zubin

#2131871

Hi,

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.

Thanks!
Zubin

#2132051

Christian Cox
Supporter

Languages: English (English )

Timezone: America/New_York (GMT-04:00)

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.

Please let me know.

#2132695

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.

#2132713
Screen Shot 2021-08-03 at 9.31.37 AM.png

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.

#2133005

Christian Cox
Supporter

Languages: English (English )

Timezone: America/New_York (GMT-04:00)

fire.png

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.

#2133075

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