Support

Account

Register Login

Forum Replies Created

  • @loic_syclo OVH also gaslit me lately telling me repetitively “You can see curl is activated, so the problem is obviously in your code” and ended up closing the ticket on my nose. You were much luckier than me into getting some kind of insight as to why outgoing curl requests don’t work.

    I was working with a specific API made by a custom vendor and couldn’t get it working and they were not of any help and ended up asking for a refund. Sadly, many of my clients are on OVH’s server and my deployment process is hindered by this problem with ACF’s composer installation too.

  • Actually nevermind. I made further tests and there’s another issue laying around and it still triggers validation for the other forms… basically can’t have multiple forms with required values anyway (which makes sense in the admin, but not on the frontend). I’ll have to resolve the issue differently 🤔

  • I see I see. It’s a simple newsletter subscription form which is displayed in the header / overlay navigation of the website as well as in the footer.

    No worries, I’ll resolve the issue by duplicating the form and fields, it’s not a big deal for now and could even actually give us an insight on which of those two gets used the most.

    Thanks for replying so quickly! 👍

  • Hi @hube2 ! I know it’s an old one, but still giving me problems when I use Advanced Forms to display ACF forms in the frontend.

    When you say two identical field groups, do you mean that If I was to wrap my fields in a group in both output of my form, they would be perceived by ACF as separate and remove the issue?

  • Aaaand I figured it out. Warning: this is very much hacked around. We should never access React instances from the outside and call their methods without having been passed the instance from an event or something. But until we get the proper hooks and APIs from ACF and WP core, this is pretty much as close as it gets. https://github.com/davidwebca/acf-block-style-location

  • Just for reference, I found this post in the forum from John about extending acf.ajax to be able to trigger the re-rendering of the form. I’ll look into that, even though his example is a broken link, I’m pretty sure I know what to do. https://support.advancedcustomfields.com/forums/topic/custom-location-rule-js-refresh/

  • Alright, I got an OCD moment because I come back to this post every 6 months checking in if it’s been done so I wanted to give it a go.

    I’m 99% there with only filters: https://gist.github.com/davidwebca/efe3bb9f69df0a0f007179c59872054a

    With that, it works on full reload of the page in the admin, but not with changes, style changes or AJAX re-rendering… And you have to visit a Gutenberg page to activate the block styles cache, otherwise there’s no way WordPress knows about the block styles registered (🙄).

    Other than that small limitation, only thing that I miss is the ability to force the re-rendering of the ACF form components. As far as I know, my AJAX works and the filtering out of the field group works, but the forms don’t re-render or reload according to changes in the form. Might have to add filters in acf-pro-blocks.js? Maybe we can already do that with JS filters / force JavaScript events?


    @hube2     Thoughts?

  • Inspired by Rahul’s answer and the newest Gutenberg / React practices, I’ve created a small sidebar plugin that allows a user to set the desired width for themselves. I needed this for myself so I pulled a (╯°□°）╯︵ ┻━┻ and coded it.

    Feedback welcome. https://github.com/davidwebca/custom-editor-sidebar-width

  • Just adding this here in case someone else needs this. This piece of code will add the first taxonomy term as default for all taxonomy fields *on the frontend*. I needed this for frontend forms, but feel free to remove the “is_admin” check if that’s what you need.

    Beware of potential overhead if you have many terms or fields that would be triggered by this.

    function set_tax_default($field) {
	if(!is_admin()){
		$terms = get_terms($field['taxonomy'], ['number' => 1]);
		if($terms) {
			$single_term = reset($terms);
			$field['default_value'] = $single_term->term_id;
		}
	}
	return $field;
}
add_filter('acf/load_field/type=taxonomy', 'set_tax_default');

  • Hi! Sorry to revive this old thread, but I found this searching for an option to deactivate certain fields on the frontend. Right now, I’m able to dequeue the CSS and JS manually and that’s okay for most of my fields, but I also have some fields that echo some content (namely SVG icons that are hidden with display:none) to facilitate rendering them on the backend when they’re needed.

    That also comes from the fact that I have a few custom fields plugins enabled on the website I’m working on and I’d like to selectively stop them to be “activated” at all on the frontend. All of the fields are always enqueueing their settings and assets regardless if they’re used or not in the form I’m actively displaying on the frontend. In that example, my SVG Icon selector enqueues it’s CSS, JS and echoes its icons even if there’s no SVG Icon selector field added in the form itself.

    Seems like there should be a filter to shortcircuit a field altogether in that case but I can’t find it right now, but that brings me to the other question: aren’t fields lazily initialized? Should they not or is it too complicated since it doesn’t really matter for the backend of things?

  • (apologies if this is posted twice, got a bug and not sure if it went through)

    Just a quick update, I’ll link to a comment I found by Eliot on github. https://github.com/AdvancedCustomFields/acf/issues/264#issuecomment-629558291

    Basically says that if you use “get_fields” instead of single “get_field” functions, it won’t pass the data because the name of the fields aren’t declared at that moment in the code execution. You can still pass examples without refactoring your code to use “get_field”, but you have to use the field IDs like so and it will work with “get_fields” : 

    
'example'  => [
    'attributes' => [
        'mode' => 'preview',
        'data' => [
            "field_5efb9b4a86e4d" => "Titre gauche",
            "field_5f29ba5f8e2f1" => "h2",
            "field_5efb9b4a86e4f" => "Sous-titre gauche",
            "field_5efb9b4a86e51" => "<p>Mauris turpis risus scelerisque mollis interdum tincidunt lectus parturient nibh</p>",
            "field_5f08b1ab13927" => ["url" => "http://google.com", "target" => "_blank", "title" => "Lien gauche"],
            "field_5f0c252bdce4e" => 0,
            "field_5f29c57dad9dc" => "text-white",
            "field_5f29c59dad9dd" => "opacity-15",
            "field_5f3a04b753a8d" => "Titre droite",
            "field_5f3a04a953a8c" => "h2",
            "field_5f3a04bd53a8e" => "Sous-titre droite",
            "field_5efb9b4a86e52" => "<p>Mauris turpis risus scelerisque mollis interdum tincidunt lectus parturient nibh</p>",
            "field_5f08b24c905b3" => ["url" => "http://google.com", "target" => "_blank", "title" => "Lien gauche"],
            "field_5f0c2543dce4f" => 0,
            "field_5f29c5dbad9de" => "text-white",
            "field_5f29c5ebad9df" => "opacity-15",
            "is_preview" => 1
        ]
    ]
]

  • Just a quick update, I’ll link to a comment I found by Eliot on github. https://github.com/AdvancedCustomFields/acf/issues/264#issuecomment-629558291

    Basically says that if you use “get_fields” instead of single “get_field” functions, it won’t pass the data because the name of the fields aren’t declared at that moment in the code execution. You can still pass examples without refactoring your code to use “get_field”, but you have to use the field IDs like so and it will work with “get_fields” : 

    
'example'  => [
    'attributes' => [
        'mode' => 'preview',
        'data' => [
            "field_5efb9b4a86e4d" => "Titre gauche",
            "field_5f29ba5f8e2f1" => "h2",
            "field_5efb9b4a86e4f" => "Sous-titre gauche",
            "field_5efb9b4a86e51" => "<p>Mauris turpis risus scelerisque mollis interdum tincidunt lectus parturient nibh</p>",
            "field_5f08b1ab13927" => ["url" => "http://google.com", "target" => "_blank", "title" => "Lien gauche"],
            "field_5f0c252bdce4e" => 0,
            "field_5f29c57dad9dc" => "text-white",
            "field_5f29c59dad9dd" => "opacity-15",
            "field_5f3a04b753a8d" => "Titre droite",
            "field_5f3a04a953a8c" => "h2",
            "field_5f3a04bd53a8e" => "Sous-titre droite",
            "field_5efb9b4a86e52" => "<p>Mauris turpis risus scelerisque mollis interdum tincidunt lectus parturient nibh</p>",
            "field_5f08b24c905b3" => ["url" => "http://google.com", "target" => "_blank", "title" => "Lien gauche"],
            "field_5f0c2543dce4f" => 0,
            "field_5f29c5dbad9de" => "text-white",
            "field_5f29c5ebad9df" => "opacity-15",
            "is_preview" => 1
        ]
    ]
]

  • Just like @phip said, I don’t see any data from the example array passed to my block rendering. Are we missing something?

  • I just found my question by searching again for this as I need it again for another project and I didn’t remember I had already asked. 💀

    I really would like this. I’ve noticed there’s talk about an ACF_Location overhaul in 5.9, but we have yet to learn what it entails.

  • @jvarn Hi! Since answering here, I’ve gotten the pro github access to be a French tranlsator. Maybe I can fix this issue (but only this once, since answering requests here is not my job). Since I don’t speak arabic and don’t know the syntax, I just want to make sure with you before making the change (and fixing the % d error mentioned along the way) :

    %d fields require attention
    is now
    % d مجالات تحتاج إلى اهتمام
    and would be more logical as
    %d حقول تحتاج إلى اهتمام

    Is this right?

  • Hi ahmader,

    I currently have the same problem in French. Can you be more specific onto what you’ve changed / fixed?

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