Support

Account

Register Login

Forum Replies Created

  • Yes, this is just a feature request. I understand that JS is required to do this, but I am just asking that a dev can use PHP or JSON to build this functionality in just like we can do with ‘conditional_logic’. It would make my teams and I job much easier.

    I would still like this reviewed and considered.
    Thanks

  • The above is just an example.

    So lets say I have 2 fields:
    – format (radio buttons with two options [‘image’, ‘video’])
    – content (textarea)

    When the user (In the Admin) chooses format to be ‘image’ I would like the label for ‘content’ to be ‘Caption’.
    When the user chooses format to be ‘video’ I would like the label for ‘content’ to be ‘Description’.

    Sure, I could create two fields ‘caption’ and ‘description’ and set them conditionally based on ‘format’. The issue is then the user will have to copy their text and paste it in the next field. Which may not sound like a big deal, but when dealing with a repeater field where they have 20+ entries then it becomes one. Also I don’t want to have to add additional conditionals in my PHP code to retrieve the content.

    I can understand that this may be an issue when trying to figure out the best way to do this in the GUI, but my team and I don’t use the GUI. We build out all the fields using PHP. So for now I am just hoping that this can be done with PHP.

  • I am not able to download the attached file. I think the link might not be working properly or you might need to zip it first, but it’s fine as I got my own patch. Thanks for the update.

  • Jumping in here,
    Those 2 lines are also causing about 10% of additional load time for me as well. This is only the issue when using Persistent Cache.

    I understand why they are deleted, but I agree with Spacedmonkey that it should be a static class variable instead of using the wp_cache or more preferbly ACF checks to see if persistent cache is enabled and doesn’t run those 2 lines.

    So the reason for the deletes is if you change the fields then they need to be deleted. Many persistent caches will have some sort of clear all cache method which a developer would know to use when they update the code. Therefore, it is those 2 lines of code should not run when persistent cache is enabled.

    So I think the main thing here is ACF needs to determine first if persistent cache is enabled and if so to not run those 2 lines.

    There are many ways to check for this, but the easiest that comes to mind would be to check if the file exists (wp-content/object-cache.php)

    Spacedmonkey,
    For now you can get around this by editing wp-content/object-cache.php
    Just edit the “wp_cache_delete” function to only run if the $key and $group don’t match those of the ACF calls.
    Just make sure when you update your fields that you delete the object cache.

    John and Elliot,
    Since many persistent caches with create and delete the wp-content/object-cache.php file on the fly it would make more sense for ACF to run the check. I would recommend that you look into this.

    Thanks

  • Thanks Elliot,
    Well after a bunch of testing I finally found the main culprit.

    First off, it seems that JSON does not have a speed advantage over PHP.
    Not in my tests anyway. Which for me is good as I want stick with PHP.

    However, I did test upgrading to ACF5 and that increased the Speed drastically.
    Page load went from 15sec to 2sec.

    So I started looking as to why.
    it seems it mainly had to do with the “page-link” field.
    In ACF4 this field prints out the Select field and all the options. This is normal, but because the client has a few hundred posts, few hundred pages, products, casestudies, etc. The Select dropdowns were outputing about 1,000 option fields. On Top of that we are using Flexible Content and therefore there can be quite a few “page-links” on the page. This was causing the post.php file to be 4.4mb. This was making the page load extremely slow. In ACF5 you have switched this out for an Ajax Dropdown. So no more thousands of options in select fields. This took the page size down to 974kb.

    Even though this helped a lot I would suggest looking into ways to reduce the amount of markup. It seems something that my team can do is reduce the size of the key fields, but I would ask that you look into reducing the markup.

    This seems quite long for an id:
    id=”acf-field_52eda830feeb1-acfcloneindex-field_row_boxes_52f2da031b44e-acfcloneindex-field_row_boxes_10001″
    I know it needs to be unique, but maybe you can hash it or something to reduce the size as this is also used in the “for” attribute. Maybe also look into reducing the amount of tags, white-space, etc.

    To get around this issue in ACF4 you would need to change your “page-links” to “text” fields and have the client input the URL or have them input the Post ID. This is not ideal, but it would decrease the load on the page.

    Because of this our team will look at incorporating ACF5 much sooner.

    There are some minor issues with it like the new Dropdowns show the entire post title. My clients use really long titles. This makes the admin all wonky as items don’t line up. I am sure I can work around this with a CSS fix, but I will post this in another Thread.

    Thanks

    Also if anyone needs this info here is how I found converting PHP into JSON:

    
foreach (acf_get_local_field_groups() as $group)
{
	$group['fields'] = acf_get_local_fields($group['key']);
	echo json_encode($group, JSON_PRETTY_PRINT);
}

  • Ok, after a bit of time I see that when using PHP it doesn’t store any fields in the database. So we may have already been getting the benefits of not having to hit the database when using php. Which is good, but it doesn’t address the issue of the Admin still being slow when loading Fields, specifically Flexible Content.

    So now the main question is:
    If we have already only been using PHP to build our fields do we benefit from using JSON as well?

    My initial thought is No, but we would need Elliot to confirm.
    I may as well run some bench marks to determine that.

    Also I have been playing with exporting fields from PHP to JSON.
    I will have a follow up on that soon.

  • Thanks,

    I am playing with ACF5 right now.
    Looking at the JSON it looks almost identical to the PHP files.

    So Here is the Big Question:
    ** Can’t you just load the fields with the PHP data instead of JSON ***

    All that would be needed for us would be to specify a load type:
    define(‘ACF_LOAD_TYPE’, ‘php’);

    Default would be:
    define(‘ACF_LOAD_TYPE’, ‘json’);

    By setting it to ‘php’ we agree that ACF will not look at the database and instead only use what we have defined with php.

  • Thanks,

    We don’t have a need to move to ACF5 right now. I know there are a lot of nice features, but we don’t need them at the moment. However, our clients do mention often how slow the Admin Panel is. We have gotten around this a little by switching from Apache to Nginx only and using W3TC for DB and Object Caching, but it is still slow. So we are curious how much faster JSON would make it. Granted we understand that not everyone is using it like we are as we use Flexible Content to build most of the pages so some of our client have hundreds of fields on single page. It could take them up to 8-10 seconds to load before they can make any changes to the page.

  • Thanks, I will look into the Plugin if the client keeps having this issue. Personally I don’t like the idea of adding another plugin for something that I think should be handled by WP or ACF.

  • This is the only reason why my team has not moved to acf 5 yet.
    We are fine with running function or something else to get this to work. So any help would be appreciated.

    Thanks

  • Thanks
    So far I have been using this format:
    field_{field_group_name}_{field_name}

    Everything has been working fine as long as I use a unique group name and label name. Which you need to do anyways.

    I think there should be an option to leave it blank and it will use this format.

    I did have issues with older versions of ACF with the field id, but with 4.4.1 we don’t have any issues now.

  • Bump Again ?

  • Bump Again ?

  • Bump Again ?

  • Bump ?

  • Bump ?

  • Bump ?

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