Support

Account

Forum Replies Created

  • Wow. Thanks guys… I have the very same issue. I’ll try @jsilver’s solution. I don’t want to be pushy… but this should have been fixed by now 😱

  • I also make extensive use of flexible content in my themes. It would be lovely if it was implemented natively!

  • Hey people. I was reading through the latest changelogs and it seems a fix has been release to alleviate this issue. Not sure if it would fix it (I can’t validate right now on the website that was causing the issue for me). Maybe validate? https://www.advancedcustomfields.com/blog/acf-pro-5-5-0-update/ (WYSIWYG delay option)

  • I think that moving from repeaters to layouts can have a positive effect when using many editor fields, but @uptownbrent seems to have a great solution when you think about it.

    Each item that can be repeated, depending on your project, probably can be transformed in a custom post type in which ACF has some fields and then using a repeater or multiple select to link the posts to the original one.

    It’s not as convenient as having all the fields in the same page, but it allows ACF to breathe and to structure things more tightly to your concept.

  • Guess 1 :

    @elliot
    In my case, it seems it is the great number of TinyMCE WYSIWYG that slows things down. I’ve looked at the code in acf-input.js and there’s a different tinymce.init for every field (which is logical), but since mine were had all the same params, I’ve tried to “cache” all the ones with the same params to init them all at the same time in the same call, but the only effect that had was to prevent loading the CSS files again and again. Which didn’t correct the problem completely even though I saw a really small difference in loading time.

    Guess 2 :
    My other guess is the WOFF fonts. I don’t know why, but in my Chrome developer tools, I see those loading right after as if they were the one to block the loading. Couldn’t figure out why the server wouldn’t cache them, which should rule out that guess as well.

    Guess 3 :
    Before activating script debug mode, it seemed to block ad a load-scripts.php call with a lot of scripts in it. But after activating the debug mode, I’ve seen it didn’t seem to be this one that was causing the slowdown, but much more the 54 calls to tinymce.js… Why 54? I don’t know. I only had 25 tinymce fields in view at the time.

    Guess 4 :
    (╯°□°)╯︵ ┻━┻

  • I currently have the same issue. I am also using a lot more conditionals than it should be because tabs seem to have a problem with them. When there is, let’s say, a field to check (true/false) that makes a tab and its sub-fields appear, the tab appears but the sub-tabs aren’t checked on by the conditionals. In other words, if they are set to appear at another conditional inside the tab, they still are showing.

    Ex.:

    – Show content boxes (checkbox = checked)
    — Tab showing wysiwyg boxes (appears as per conditional)
    — Content box wysiwyg (showing as per conditional)
    — Show alternate content (checkbox = not checked)
    — Alternate content box wysiwyg (showing, conditional not respected)

    I had to add a conditional that applies to each sub field that checks both checkboxes (inside and outside the tab) which adds a lot more than necessary and slows down everything.

    Maybe using Zepto instead of jQuery would help out fiddling a little less with the dom? Is all the dom play necessary?

Viewing 6 posts - 1 through 6 (of 6 total)