Support

Account

Forum Replies Created

  • This is a little elaborate, but I’ve setup my own WP website as a composer repository using SatisPress:

    https://github.com/cedaro/satispress

    All my premium plugins – and I use a few – are installed and maintained there. Then I pull them down from there as standard composer packages to my own/client sites.

    I don’t have any security on that repository, but it’s an obscure URL and that’s good enough for me.

    It has proven an effective and easy way to do it.

    Who knew a WordPress site could double as a composer repo!?

    In the default SatisPress approach, a plugin that would normally be referenced in composer as:

    composer install wpackagist-plugin/advanced-custom-fields

    …is instead referenced as:

    composer install satispress/advanced-custom-fields-pro

    The SatisPress plugin lets you change that repo name if you so desire.

    All in all, reliable and great, because it’s one approach for all my premium plugins.

    FINALLY… one other benefit. I can create my own custom plugins for this and that, and also have them automatically available as composer packages, just by installing them on that WP site. Nothing more to do. No need to put them on a public composer repo.

    So I like it 🙂

  • I think this needs some more thought, John. Honestly.

    A basic ACF text field DOES get the $field[‘class’] attribute applied to its class.

    But the input of a datepicker field is ignored (as I show above).

    Can we not, at least, aim for simple consistency?

    $field[‘class’] should always be available, and should always be applied to the visible element, so that things like Bootstrap classes can be applied easily.

    To my mind this is sensible, and a fairly trivial update to the code. It’s very little work to do it, and a big win for consistency and usefulness.

    A

  • Ok so I got a reply from Elliott on this.

    Basically, he sees no possible way to add InnerBlock capability to a dynamically-generated block.

    As you would know, all ACF blocks have to be degnerated dynamically, and as such there are limitations on what can be done, and to his mind, InnerBlocks can’t be done.

    He’s open to what others may know beyond that, but frankly, that’s a little scary! I can’t see a rock solid solution if we can’t do this. There are so many applications that really need it, to my mind.

    So I guess, thinking caps on, people!!

    A

  • I’m looking at ACF Pro > includes > fields > class-acf-field-date_picker.php:

    
    // elements
    		$div = array(
    			'class'					=> 'acf-date-picker acf-input-wrap',
    			'data-date_format'		=> acf_convert_date_to_js($field['display_format']),
    			'data-first_day'		=> $field['first_day'],
    		);
    		$hidden_input = array(
    			'id'					=> $field['id'],
    			'name'					=> $field['name'],
    			'value'					=> $hidden_value,
    		);
    		$text_input = array(
    			'class' 				=> 'input',
    			'value'					=> $display_value,
    		);
    

    Why can we not change the 3rd last line there to:

    
    			'class' 				=> $field['class'] . ' input',
    

    ?

    And do this consistently for all other field types?

    For me, this is about applying Bootstrap 4 styles to the correct field elements for front-end forms. I can’t, because I can’t get to the input element to add a class, unless I make ACF (Pro) consistent in this way…

    Is this a missing bit of code, or deliberate??

    A

  • @ryan62 I have been thinking about the same thing! It’s a critical need right now. I can’t believe it’s so hard!!

    Please, Elliott and team, THIS IS A REALLY URGENT NEED!

  • Are you able to share that plugin? I’d love to see it. I’m looking for a lightweight plugin with JUST a row/section/container/wrapper block, as you describe it, and I can’t find one!

    Thanks!

  • I feel like I’m having a lovely little conversation with myself, here!

    I’ve extended the CSS above and it’s seems enough for what I need now.

    Leaving it here in case it’s useful to someone else:

    
    add_action('admin_head', 'hb_acf_custom_fonts');
    function hb_acf_custom_fonts() {
      echo '  <style>
        .acf-block-body.is-edit {
          font-family: -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",sans-serif !important;
          font-size: initial !important;
        }
        .acf-block-body.is-edit .acf-field, .acf-block-body.is-edit p {
          font-size: 13px !important;
          color: #555d66 !important;
        }
        .acf-block-body.is-edit label {
          font-size: 12px !important;
          color: #191e23 !important;
        }
        .acf-block-body .acf-fc-layout-handle {
          background: #f3f4f5 !important;
        }
        .acf-fc-layout-order {
          background-color: #11a0d2 !important;
          color: #fff !important;
        }
        a.acf-icon.-collapse {
          background-color: transparent !important;
        }
      </style>';
    }
    
  • If there is nothing better, I propose something like this, for a start:

    
    add_action('admin_head', 'hb_acf_custom_fonts');
    function hb_acf_custom_fonts() {
      echo '  <style>
        .acf-block-body.is-edit {
          font-family: -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",sans-serif !important;
        }
      </style>';
    }
    
  • Click-and-drag of the inner/nested flex content fields also doesn’t work.

    Same issue, no doubt.

  • I note that this is also the case for the main editing area – no collapsing of the internal flex content fields either.

  • Thanks Pedro. That expresses the need very well.

    I have not progressed anywhere on this issue since my post.

    I’ve no doubt this is a “like to have” kind of thing, and there are likely always more urgent things for the ACF team to look at 🙂

    A

  • Since 5.4.0, /core/cache.php explicitly adds “acf” to a non-persistent-cache group via calling wp_cache_add_non_persistent_groups().

    So for some reason it has been determined that ACF should not use the persistent cache.

    Why? What’s the logic there and why can’t it be overruled without hacking this file?

    HOWEVER, if you look at wp_cache_add_non_persistent_groups(), it does nothing! It’s an empty function in WP core. So I dunno what to think.

    A

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