ACF Blocks Todo list

[elliotcondon]

Hi all 👋,

Welcome to the ACF Blocks todo list. Here you will find all the items we are working on for the upcoming ACF Blocks feature.

Bugs

• [x] Unload prompt always shows even after post is published
• [x] Field value is lost when deleting / recreating a field with the same name
• [x] Default values are not loaded in render_callback
• [x] Prevent "edit html" option
• [x] Duplicate Block is not working
• [x] Reusable Block is not working
• [x] Conflicting input names cause issues with duplicate fields (radio)
• [x] Field widths in sidebar should be ignored (100% width CSS override)
• [x] Fix "reordering" rows not affecting preview (rep/flex row index number => string)

Features

• [x] Allow "alignment toolbar' to be disabled / customized
• [x] Support the "anchor" setting for table of contents
• [x] Use icon in alignment toolbar to switch between edit/preview
• [x] Add setting for default mode (edit/preview)
• [x] Add setting for default align (full, wide, left, right)
• [x] Add setting to restrict mode
• [x] Allow render_callback to provide different front/back markup
• [x] Add render_template setting to avoid callback function
• [x] Add setting to restrict post types

Ideas

• [x] Save values using field name instead of field key
• [x] WP renders all dynamic blocks on "edit page load" (see wp.apiFetch.createPreloadingMiddleware() inline script). Take advantage of this to avoid AJAX preview requests on initial load.
• [x] Use "acf/prepare_field" to change input key to name. Add hidden inputs for "_acf_reference"
• [x] Add post_id value to $block parameter in callback
• [x] Add JS actions during "switch" and "render" events.

Tasks

• [x] Write documentation for acf_register_block() function.
• [x] Write documentation for ACF Blocks feature.

Please leave any comments below, but try not to bloat this ticket into a chatroom.

Thanks Elliot

[jjarolim]

Hi Eliot -

Bugs: Edit Mode: Multiple Instances of the same block on the same page: Radio Select Javascript interferences. Maybe testing required with all types of input components.

[elliotcondon]

Thanks @jjarolim - I've just added this to the to-do and already know the fix :)

[nick6352683]

It's amazing how quickly you fixed the bugs in just a few days. That said, on your web site, I opened 2 new support tickets for a whole new set of bugs regarding WP 5.0 beta1.

Thanks for all the hard work, Nick.

[elliotcondon]

@nick6352683 Thanks! I'll reply to your tickets shortly

[jjarolim]

Hi Eliot -

Cool thanks for fixing "Conflicting input names cause issues with duplicate fields (radio)". Is there any chance to test the current build with your fixes? Or do you have any release date for beta2?

Or am I blind for not finding the current download?

Thanks ;-)

• Johannes

[NewJenk]

Great progress @elliotcondon, when can we expect Beta 2?

Keep up the good work!

[elliotcondon]

@jjarolim @NewJenk Aiming to release ACF 5.8.0-beta2 today!

[nick6352683]

This is great Elliot. One of the ideas that needs to be added is a new field type "block", where we can embed "insert another block, like the native columns block for example, with the + sign. With it, we can create our own columns, sections, containers, etc... right now as it is, the compromise that I'm using is using the WYSIWYG field, and rely on shortcodes (not blocks) to insert (embed) the content.

The plugin that I mentioned to you last week in a support ticket implemented this exact feature yesterday, and it opens many other possibilities. Let me know, if you want more specifics and demos...

Thanks.

[elliotcondon]

Hi @nick6352683 Thanks for the reply. This sounds pretty interesting, but is not something I would be able to add in before November 19. Let's get the basic ACF_Blocks functionality working and then look towards new ideas afterwards.

[nick6352683]

Totally understandable...

[jjarolim]

5.8 Beta 2: w00t !!

I can see ALOT of improvements - not only the one bugfix.

THANKS Eliot - That thing is becoming better and better! I'll currently developing a project with it and will report if i find something.

Thanks again and best regards from Salzburg, Austria!

• Johannes

[nick6352683]

I totally agree with Johannes above: That said, the new beta2 version is crashing my theme's customizer, I'm getting just a white screen, which is an indication for some sort of a JavaScript issue. Deactivating ACF brings back the customizer. This happens with both WP 4.9 / Gut. 4.1.1, and WP 5.0 beta1.

Disclosure: I am using the same code as I used n my functions to register the blocks from ACF 5.8 beta1, and not the new one for beta2, so that could be it (hopefully). I will try the new blog registration code on a fresh WP installation and hope that that was the cause and everyone can learn from it... I'll report back my findings here...

[elliotcondon]

Hi @nick6352683 Thanks. Will test out customizer today.

[MakiBM]

Hey @elliotcondon. I've been playing with that for a bit and there's one thing that concerns me. It seems to be using ServerSideRender which has to make a round per each update. It's meant as a fallback for a legacy code from what I learnt. Are there any plans to enhance that to "gutenberg-way|? Maybe with use of react html parser pkg or even dangerouslySetInnerHTML? Not sure on possibilities here and how far you could consider as scope of ACF interest. More of a question rather than any solid idea to drop in...

[elliotcondon]

Hi @MakiBM Thanks for the feedback.

Yes, we are currently using AJAX to integrate our PHP field framework into Gutenberg's JS UI. This transition stage is a tricky one for ACF, but if WordPress continues to move towards a full JS admin, we will have to adopt the same direction too.

[nick6352683]

Hi @elliotcondon,

Xampp on Windows 7 Pro WP 5.0 beta 2 - fresh installation ACF Pro beta2 - second release (today's release) - No other plugins. PHP v7.2, btw...

My customizer started working again. However, as long as ACF is activated, I cannot update an existing page/post, or publish new ones. Deactivating ACF, things work again.

Initially I thought this was a Theme issue, but I get the same issues exist with the Twenty Nineteen theme as well. Hopefully this is not an ACF issue, but WP, which will be fixed by beta3,4, RC1 or even with the final version.

Thanks, Nick.

[elliotcondon]

Hi @nick6352683 Thanks for the bug report. I'll do some testing today and report back.

[carfis]

Hi guys, @nick6352683 maybe what you described is part of this issue #11232 in WP 5.0 beta 2, I had the same problem then I reinstalled WP 4.9.8 und all works again.

@elliotcondon thank you for your amazing plugin 😉

[Jilson]

Hi Elliot, Really appreciate all the work you are doing with ACF and Gutenberg. It is looking amazing already! One bug I am running into consistently is related to duplicating posts. It seems that styles inside of Wysiwygs get stripped or serialized incorrectly, resulting in the below image. Would love to know if this is a bug or a problem with how I have programmed the render callback, or possibly just an incompatibility in the Post Duplicator plugin. Thank you!

[Jilson]

@elliotcondon Suggestion for a feature would be a way to register block editing inside of blocks. To make a completely seamless Gutenberg experience, it would be great to not have to use wysiwyg editors at all for content areas inside of blocks, but to rather use the common blocks (or even any block). A perfect example of what this type of functionality would be like the newer default "Media & Text" Block.

[elliotcondon]

Hi @Jilson This is the long term plan. Currently, we are bridging the gap between Gutenberg's JS React based design with ACF's PHP based architecture.

[elliotcondon]

@Jilson As for the Post Duplicator issue. Can you please notify the Post Duplicator devs? Can you also check the DB post_content of the 2 posts (original and duplicated)? Perhaps the issue is occurring in the DB before ACF is rendering anything.

[elliotcondon]

Hi All.

Just wanted to post here before anyone reports issues with WordPress 5.0-beta3. WordPress 5.0-beta3 contains major issues with metaboxes which I have reported here:

• WordPress 5.0-beta3 does not save ACF metabox data
• WordPress 5.0-beta3 redirects to “/wp-admin/edit.php” after hitting enter key

Let's wait for an official response and hopefully a fix in version 5.0-beta4

[jjarolim]

Hi Elliot - WP 4.9.8, Gutenberg 4.2.0, ACF 5.8.0-beta2: Custom Fieldgroup with 3 fields enabled for CPT including a "link" field: Nothing happens when clicking on the button. In the console i see the following javascript error:

TypeError: wp.blocks is undefined in acf-blocks.js:138:7

br from Salzburg, Austria

• Johannes

[jjarolim]

FYI: Small Hack solved the problem in acf-blocks.js in line 138 (btw. thanks for not minifying it yet):

-- var result = wp.blocks.registerBlockType( blockType.name, blockType ); ++ var result = wp && wp.blocks && wp.blocks.registerBlockType( blockType.name, blockType );

May not be the final fix but would work for now ;-)

br from Salzburg, Austria

• Johannes

[elliotcondon]

Hi @jjarolim

Thanks mate. I ran into this issue a few days ago too. I'll aim to release a beta3 soon to fix these minor bugs :)

[jjarolim]

Hi Eliot -

Any chance you insert the page id - where the currently rendered block is embeded into - to $block? Currently i don't see a way how i get that if i render the block in the backend.

In the frontend, i use get_the_ID() In the backend, i tried get_the_ID, global $wp_query, get_query_var('post'), $_GET['post'], etc. - nothing gives me the current page/post ID.

thanks!

• Johannes

[elliotcondon]

Hi @jjarolim Great idea, and one that I have recently added :)

I have added a $post_id parameter to the render_callback & render_template. This will be included in the next beta version!].

[nick6352683]

Hi Elliot,

This is not a bug, but a feature not fully implemented for the Blocks. The widths are correctly ignored in the Sidebar (inspector). However, when we have many fields (attributes) in a block, many of us (at least me) organize the fields in Accordions. In this case where the fields are within Accordions, the widths inside the Inspector are honored (not ignored). Any chance of ignoring the widths of fields in Accordions for the Inspector?

Thanks, Nick.

[elliotcondon]

@nick6352683 100%. I'll have this fixed shortly.

[jjarolim]

Hi Nick -

Any timeline for beta3?

Additionally, FYI, last week I noticed that it's not a good idea to start the main wp loop inside a acf gutenberg block template.

while (have_posts()): the_post(); global $post; echo $post->ID; endwhile;

used in a block template seems to cause an infinite loop.

Apart the question if using the loop inside a block template is something sane to do (I forgot a code snippet after copy-paste) - it's crashing wp. It seems you reset the main loop before rendering the block template somehow - maybe there is a possibility to reset it to a state where one can use it - gets nothing but breaks nothing either?

BR from Salzburg!

• Johannes

[nick6352683]

Hi Johannes,

I'm sure Elliot is waiting for the WP RC due out today. They had a one day delay, and it seems that they will be pushing the final version for the January date. I'll let Elliot respond to you though, as he is the right person to respond to you in this case...

[jjarolim]

Hi Nick - Thanks for the fast feedback: just sharing infos if I notice something - no pressure!

Best regards from Salzburg, Austria!

• Johannes

[elliotcondon]

Hi guys.

I'm currently testing 5.8.0-beta3 and hope to have it ready for you tonight/tomorrow.

[mario-neuhold]

Hi Elliot,

thanks for getting beta3 out so fast and your hard work on ACF Gutenberg in general.

Regarding the changelog:

• Added alias function acf_register_block_type() for better naming consistency.

Seems like other functions got renamed as well, but are missing an alias. When adding a new field group the Block list is empty. When selecting an existing field group for a block, I get this error in the Location tab:

I found a way to fix it by adding the alias in \advanced-custom-fields-pro\includes\blocks.php.

At the end of the file I added ...

function acf_get_blocks() {
    return acf_get_block_types();
}

Not sure if acf_get_block_type( $name ) and acf_remove_block_type( $name ) need alias as well?

[wpmark]

I can confirm I am also getting this error too with Beta 3.

[jjarolim]

I can confirm that Mario's addition to the end of the blocks.php is a working fix for that if you want to work with beta3.

[nick6352683]

@mario-neuhold: Your solution saved my thanksgiving !!! Last night I was so bummed (for about 5 minutes), then decided to develop with beta 2, and execute with beta 3, but your little code eliminated all that.

Thanks again, Nick.

[nick6352683]

Well, not exactly after all... It solves in editing the blocks and creating new ones, and on the front end all is well as well, but when you edit a page that contains previously created blocks you get a message "Your site does not include support for the acf/qtsection block. You can leave this block intact or remove it entirely".

What am I missing here?

[nick6352683]

Clearing the cache when editing the page, forces for Gutenberg to recognize the blocks again, in case others encounter what I experienced. All is well again...

[elliotcondon]

@mario-neuhold @wpmark @jjarolim @nick6352683

Thanks guys. Sorry for the noob mistake. I've fixed the issue and re-uploaded the beta version files online. Please either create an "alias function", or search/replace acf_get_blocks() to acf_get_block_types().

[nick6352683]

One quick suggestion to make things even better...

In a block I have a Color field, and this field has a default value set during the fieldset creation process. Now, while using this field in Gutenberg, there is a text field to manually type in and replace the default color, and a "clear" button. Once I use either one of these methods, and change my mind, there is no way to get back the default color (in case I forgot what the default value was). My only recourse at this point, is to delete the block, and start all over again, or temporarily start a new block and get the default value from it...

My suggestion would be, to still have the ability to replace or clear the default color with the text field, but instead of having the clear button have a "default" button, to load the default color set by the developer as intended. With this, we can have all available options available... and this is how the Customizer works as well.

[elliotcondon]

Hi @nick6352683 Great idea. I think this is a good improvement for the color picker field. I've just taken a quick look at the customizer but can't find a default value for color pickers. Can you point me in the right direction to check that out?

[nick6352683]

I think I was wrong about deleting the color from the text field, the default value gets set, but instead of the clear button we get a default button.

https://www.youtube.com/watch?v=gBF9-HmLcso&feature=youtu.be

[elliotcondon]

@nick6352683 I believe this "default" color button may be a custom one in your theme. I've just tested the "Twenty Seventeen" theme and can confirm the the button is named "clear" and does not change the value to a pre-determined default. If you would like to continue this conversation about the color picker, can you please submit a support ticket here: https://www.advancedcustomfields.com/contact/

[nick6352683]

We can leave for later on Elliot, as I was at the core meeting today and felt your anxiety, Dealing with these arrogant people should be more than enough for you now...

Thanks.

[ghost]

@elliotcondon Can you please add an JS event that fires (every time) after the preview loads so we can do things like initialise a slider?

Perhaps another that is called when switching away to the editor view (/just before the ajax call).

i.e. on preview load and unload

[elliotcondon]

@f4w-pwharton Great idea. I'll add this to the list.

[mario-neuhold]

@elliotcondon Facing an issue that sounds related to "[x] Default values are not loaded in render_callback".

It seems like default values in the render_callback are only working in the backend preview, not in the actual rendered frontend.

If we create a block that has only one field and that field has a default value set and insert it into a post, it looks good in the block editor, but bad in the frontend where get_field() just returns NULL instead of the expected default_value. That's because there is no information about the field in the database yet, only the block ID. Hence ACF can't look up the defined default_value of the field - because there is no field at all.

So despite the positive preview in the backend, the save hook actually calls the render_callback again where the output is still NULL. You have to pro-actively change the value of the radio button to successfully save anything to the db.

Here is an example gist for a block field definition and a simple template: https://gist.github.com/mario-neuhold/313ba94a4cf48b835c043d0b1b7ee4fa

We chased the difference between editor + frontend down and found the class ACF_Local_Meta()->pre_load_reference() in \advanced-custom-fields-pro\includes\local-meta.php filtering acf/pre_load_reference which gets applied in acf_get_reference() of \advanced-custom-fields-pro\includes\api\api-value.php.

Unfortunately, no idea for a solution whatsoever. For now we have to put the desired default_value in the render_callback template as well.

[nick6352683]

Hi Mario, Elliot,

I had reported this annoyance to Elliot since beta 1, and I think this is more of a Gutenberg issue more than an ACF one. Nevertheless, I read this yesterday at the #core-editor channel and I'm not sure, but I think this is similar what they are discussing here. I wish they had better documentation to make Elliot's life easier...

https://wordpress.slack.com/messages/C02QB2JS7/convo/C02QB2JS7-1547086365.456000/