Support

Account

Register Login

Forum Replies Created

  • Jumping on the vagon too. Some sort of refresh would be realy nice.
    Blocks displaying completely irrelevant content after post save is rather jarring 😀

  • I strongly support this feature request 😀 It will complete the currently limited Gutenberg editor experience.

  • I tried. It doesn’t.
    Elementor’s integration with ACF is in beta right now and works only with simple fields (those which output text, numbers etc.). So, no repeater, no post object, no relationship, no arrays etc.).

  • @juliusbangert – there should be no data loss if you revert to version 4.3.4. as the new versions so far didn’t introduce any major changes to the way data is stored. However, to be safe you A L W A Y S should backup your site’s files and database before doing any updates.


    @usuar10     – no that I’m aware. New versions so far didn’t address the JS performance issues.

  • There is no official fix for it yet. Unofficial solution is to install ACF 4.3.4 and follow instructions from this thread for patching particular files.
    This is not a 100% fix but most of the performance issues are addressed. Read the whole thread before you change any file.
    Absolutely do not apply these workarounds on version other than 4.3.4.

  • Patched files attached raven-design. Be careful with this. It was tested in certain cases only and it might break things i.e. as pointed by o1y.
    This is based on version 4.3.4.
    Elliot released new version 4.3.5 which possibly addresses some of the issues. Don’t apply those if you’ve already updated ACF to 4.3.5.
    If I have time I’ll see if those fixes are still relevant in 4.3.5.

    EDIT:
    4.3.5 release didn’t address all issues listed here. I’m sticking with 4.3.4 for now plus fixes which we collectively introduced here.

    acf-patched-....zip

  • Hi Elliot,
    This will be long one. I took on the performance issues related to page load once you manage to add several repeater field rows.
    In my test case (9 rows with nested repeater fields) it was taking over a minute for a page to unfreeze from JS routines.
    According to the JS profile I did in Chrome, majority of the JS time has been absorbed by acf.conditional_logic.refresh which is responsible for calling refresh_field for every conditional logic field. This is where the CPU time was eaten. In my case each refresh_field call took 0.2 to 0.5 seconds. Now multiply it by 255 items in CL array and you have your bottleneck. With every added repeater row this number was increasing.
    The culprit is here:
    var $targets = $('.field_key-' + item.field);
    This cycles through all fields of given key and does the rule checking for each of them. But you do it for every item in the CL array so almost all fields are processed several time redundantly.
    So the fix is to target only the particular field rather than all of the fields of given type. But it wasn’t as easy and straightforward as I initially expected. Due to the way you organised things in the first place I had to rewrite the logic in several places.

    Here is a walk-through of what I did (based on 4.3.4 code and including the fixes from my previous posts in this thread).

    First I changed the above mentioned line in refresh_field function to:
    var $targets = $('#'+item.field_id);
    but at this stage the item does not have the field_id element. So, I had find a way to include it.
    In acf-repeater/views/field.php after line 218 I’ve added the following lines:

    $sub_field['field_id'] = 'id_'.str_replace(array('[',']'), array('_', ''), $field['name'] . '_' . $i . '_' . $sub_field['key']);
$attributes['id'] = $sub_field['field_id'];

    This resulted in id attribute being added to the TR element of the field. Also I have now field_id available in the $sub_field array which I can use later.
    I’ve commented out the check for for the index clone because with the new logic now I need the reference id being added to every field (otherwise new nested rows will not have the required info in them):

    //				if( $i !== 'acfcloneindex' )
//				{
//					$sub_field['conditional_logic']['status'] = 0;
//					$sub_field['conditional_logic']['rules'] = array();
//				}

    In acf/core/fields/_functions.php I’ve changed the last lines of create_field function to:

    // conditional logic
if( $field['conditional_logic']['status'] )
{
	$field['conditional_logic']['field'] = $field['key'];
	
	?>
    <div class="condition" data-condition='<?php echo json_encode($field['conditional_logic']); ?>' data-field_id="<?=$field['field_id']?>"></div>
	<?php
}

    I couldn’t leave the inline JS there because jQuery append function will strip it out and nested row-clones will no longer have it. Now, field_id is saved in data attribute and I moved rules object to another data attribute.
    Because of the above changes I needed to create extra function which will fetch that data once the DOM is created. So, I’ve added acf.conditional_logic.get_items function in acf/js/input.min.js:

    get_items : function(context) {
    var _this = this;
    if (typeof(context) != "undefined") {
        conditions = $('.condition', context)
    } else {
        conditions = $('.condition')
    }
    conditions.each(function(){
        $condition = $(this).data('condition');
        $condition['field_id'] = $(this).data('field_id');

        if ($condition) {
            _this.items.push($condition);
        }
    })
},

    This is rough and can be improved to not include data from row-clones. But performance impact is not that big anyway. This functions fetches all information from the data attributes which are added due to previously mentioned change.
    Now we need to call this function when needed. I do it
    once document is ready before the init function call:

    acf.conditional_logic.get_items();

// conditional logic
acf.conditional_logic.init();

    and when new repeater rows are being setup in ‘acf/setup_fields’ event handler:

    $element = $(el);
$element.find('.repeater').each(function(){			
    acf.fields.repeater.set({ $el : $(this) }).init();			
});
acf.conditional_logic.get_items($element);

    In my case the edit page load time has been improved from 68 sec to 3.5 sec. The changes above also affected the response of the acf.conditional_login.change function. I hope you find this useful. Please review the suggested changes whether these break anything else and implement the fixes in next available release.
    If you have any questions as to why I did something one way and not the other then please let me know.
    Cheers.

  • Hi,
    Me again. I’ve been digging into the actions called after clicking Add new repeater field. It calls acf.fields.repeater.add which at the end triggers setup_fields event:
    $(document).trigger('acf/setup_fields', new_field);
    The event itself runs fast but then it gets propagated into gazillion of other elements. Not sure why. Maybe because you use $(document)?
    Regardless of the above I’ve changed the event handler to stop the propagation:

    $(document).on('acf/setup_fields', function(e, el){
	e.stopImmediatePropagation();
	$(el).find('.repeater').each(function(){
			
		acf.fields.repeater.set({ $el : $(this) }).init();
			
	});
		
});

    And now adding new repeater fields happens in an almost instant, regardless of how many are already there. Not sure if this will affect other functionality but I didn’t notice anything unusual so far. Please consider whether this can be a permanent fix.
    Possibly the same is happening in Flexible Content field. Sorry folks I don’t have this plugin so I can’t test it.

  • Hi Elliot,
    I hope you don’t mind double posting but I don’t want mix questions with my findings
    The acf.conditional_logic.change function has a line:
    $.each(this.items, function( k, item ){
    which loops through all items with conditional logic. In my case with 9 rows this.items has 255 elements and loop takes 10 seconds to complete.
    Each extra row add another 10-40 items depending on the complexity of the nested repeater fields.
    In the embedded code for each field you put them all in one bag:
    acf.conditional_logic.items.push({
    This ultimately kills the performance of conditional logic fields. I suggest you rewrite the code so the repeater field holds separate conditional_logic object with its own children only rather than refer to the global object with all items.
    I’ll keep digging what is causing other slowdowns.

  • Yeah, it didn’t work for me straight away. In my installation js was cached on WP level and on browser level.
    So clean all you caches and ensure the new version of input.min.js is loaded on post edit page.
    And yes I’m using Repeater field but not Flexible Content so I guess Flexible Content has its own set of problems which might have an impact.
    The issue with JS performance is not completely fixed though anyway.
    After adding like 10 repeater fields with 1-3 nested repeater sub-fields each the edit page loads terribly slow (on JS level). It can take 20 sec or more for JS to stop calculating whatever it is calculating before I can interact with the page.
    Also time to add new Repeater increases with every added field. Increase is not exponential but it gets longer and longer to add each new field.
    The same with conditional logic. They are fast when you start adding fields but after you have a few fields the lag is noticeable and is increasing with every added field.

  • Hi Elliot,
    The suggested fix from raldenhoven didn’t work for me. Sorry, but I’ve noticed no difference whatsoever.
    I can confirm the issue as mentioned above. Conditional logic in repeater field slows down the editing significantly.
    If additionally you have nested repeater field with its own conditional logic then it can simply kill the editing experience.

    EDIT:
    Hi,
    I’ve installed latest version from the github. I can confirm that editing experience is now greatly improved!
    There is still a lag when adding new repeater field or changing select field with conditional logic but this lag does not grow exponentially like before. It seems constant.
    Also before it was nearly impossible to add more than few images but now it works quite fast.
    I’ll keep adding content and let you know if it goes downhill.

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