Last created block overwrites data in previous same type blocks #3
Comments
|
Hey @ATomilov You got the plugin to work? Would you mind taking a look at the issue I logged? I think I am missing something super basic. |
|
@ATomilov I managed to get it working but now I seem to be running into the same problem as you. Did you find a solution? |
|
A temporary solution would be to handle this as a repeater field |
|
Long term solution would be to store this data in block attributes and prefer to check there first |
|
Hmmm repeater field would be difficult for my usecase since I place my title block in a lot of different locations interspersed through out the blog post. In the thread on the ACF github page you mention the ability to post multiple testimonies. So it seems to be working correctly for you? How'd you do that then? Through the block attributes? Looking at your post though I can see on the TODO: you list storing field values as block attributes, so I'm assuming that you were saying that in the hypothetical but it doesn't work yet exactly? Just wanting to clarify. And thank you for your work again and communication. |
|
Closed my previous issue and migrating this new issue over to here as it seems to be the same and is more narrowly focused on here:
|
|
Also I don't know if this is what you meant but this was my result trying to use a repeater field:
And
|
|
@ATomilov Hey I actually found a separate plugin that fixed this problem for me. You might want to give it a shot. https://github.com/rheinardkorf/advanced-custom-blocks @rchipka You want want to check it out too as it has the same name as your project and seems to be further along in certain ways (though it doesn't hook into ACF specifically). If nothing else it might have some code you can or want to make use of. |
|
@thedonquixotic I don't know, maybe it's worst way to resolve this, but maybe we can use meta_key (block_id) and post_id to get meta_id and then get meta_value. I just try found some unique attribute :) |
|
@thedonquixotic hah, no way. I have more trouble with that new plugin. |
|
@thedonquixotic , @rchipka I do not know the galactic or intergalactic scale is bad my solution, but it seems to me that at least it will be useful (or not at all). Within the file /plugins/advanced-custom-blocks-master\advanced-custom-blocks.php I changed: <?php
if ($_GET['context'] === 'edit') {
ob_start();
$fields = acf_get_fields($field_group);
acf_render_fields($fields, $attributes['post_id']);
$output .= ob_get_contents();
ob_end_clean();
} else {
$custom_block_fields_group = acf_get_fields( $GLOBALS['ACF_FIELD_GROUP_ID'] );
foreach( $custom_block_fields_group as $field ) :
foreach( $field as $key => $value ) :
$current_group_fields_meta_keys[] = $field['key'] . '_' . $GLOBALS['ACF_BLOCK_ID'];
endforeach;
endforeach;
$_POST['custom_block_fields_meta_keys'] = array_unique( $current_group_fields_meta_keys );
$output = apply_filters('acf/render_block', $output, $attributes);
$output = apply_filters('acf/render_block/name=' . $attributes['block_name'], $output, $attributes);
} |
|
@thedonquixotic , @rchipka continue. This allowed me to get the following: |
|
@thedonquixotic the expected behavior was working for me when I tested it. Although it should work as-is now, storing the data in the block's attributes would be a much more reliable solution. |
|
@thedonquixotic I have taken a look at all of the other implementations I could find, and while some are better than others they all have limitations, like not being ACF fields or like not being repeatable, extensible, or location targetable. |
|
@ATomilov I'm glad you were able to create an implementation that works for you, but this solution is far from ideal. Luckily storing the ACF field data inside the block attributes should be pretty straightforward. |
|
@rchipka Yeah, your implementation seems to be more robust for sure. I'll do the ReadMe stuff and see if I can reproduce that other bug in the meantime. |
|
@rchipka Hi. I understand the reason of this bug, but I can't figure out how fix it) The reason - if we use same type blocks without put they in to repeater, each next same type block has fields with same keys. And when we edit, for example, second block in admin editor it take right data because to get it we use get_post_meta, but on front-end we have value of field which overwrites last same type block. Logic of it like a field = variable. |
|
@ATomilov Currently, we hack our way around this by using Ideally we only do this as a fallback and also store the field data inside the block's attributes (which are stored hidden in post_content). This would couple the fields with their corresponding values more tightly than the current solution. |
|
Technically, we don't have to store anything as post meta at all. We could achieve the same result by using block attribute data alone. The only reason to store the block data as post meta as well is so that we can still run WP_Query and mysql queries for the data. |
|
Try again with latest version |
|
This still only works within a repeater field. BTW, I like the new template system, my functions.php was getting crowded. |
|
@asadrahbar Which version did you try with? I recently made a change that might further help with this. Right now I've switched using |
|
Still has the bug in 2.1.3. Looks like it works in a repeater field but still can't have more than one of a repeater field block on the page. |
|
Can someone with this issue please post the raw I cannot debug this issue without that information. |
|
Still seeing this bug in 2.1.4 on a site with only ACF and ACB plugins installed. |
|
Please try again with the version 2.1.5. In this version I hook into get_post_meta instead of hooking into ACF's load_field hook. This should be much more reliable. |
|
Still not working in 2.1.5, actually it's worse. In 2.1.4, the field data was saved properly, just not displayed. Now I add 2 blocks with different content, publish, looks fine in editor. View the page and both blocks have same content (from 2nd block). Edit the page and now both blocks have same content in editor. post_content: ma-popover block had values of link1 and link2 when published, now both showing link2. ma-tabs block is testing this issue
Also sorry to note that popover blocks from the ma-tabs post are picking up data from the current page rather than the post called. page id 580 - page containing tabs block postmeta: |
|
same, gonna have to move off this plugin for an alternative. |
|
@asadrahbar You need to make sure to allow the separate Ajax save to happen on each field group. Thank you for providing helpful details and debugging information. @signaturesteve This open source software is offered free with absolutely no guarantees. Seems like it might be best to wait for the official ACF release instead, where you can get customer support without taking things into your own hands. I have no intentions on providing customer support for this plug-in. It works for me. It's open source so that we can all take a look at these issues and share an effort in figuring them out. I laid the foundation to make this happen, and I'll help fix bugs, but again, please do your due diligence by providing details and attempting to research it yourself first. |
|
Thank you for building this awesome plugin before ACF implements what they said they would! Can you tell me how to allow the separate Ajax save? I found this but not sure if it's what I need or how to adapt it for use. |
|
@asadrahbar @notasausage @signaturesteve Looks like I forgot to commit a change that should have been in 2.1.5. Sorry about that. I've published v2.1.6 that contains this change, which is essential for multi-block functionality. |
|
I have this exact code for v2.1.6 running on a test site (with latest Gutenberg and ACF) and everything is working well. There are some quirks with the AJAX save when adding new ACF blocks. If you run into this, my recommendation for right now is to save the post after adding another block and refresh the post edit page. I'll need to add even more aggressive AJAX saving for ACF block changes. The problem with that is the block temporarily changes to an uneditable "saving" view. |
|
got an alert for that message ^, just an example... if you create a custom block and have a post object field in it, then try and create 2 on a page - you are unable to set them to seperate items and have them both work individually on a page. they both use the same post object, |
|
@signaturesteve can you try with another field type? |
|
Still have the issue, but now it is saving the fields correctly on the edit screen. But both blocks pick up content from the second block when displayed on the page. Interestingly, it's not the second block added, but the second block on the page - changing the block order changes the output. I refreshed the edit screen after adding and updating each block. Also, after deleting the old blocks and adding a new one, it's pre-populated with old content. post_content: postmeta: |
|
@asadrahbar In order for it to work at all, there must be a post_meta key with It appears the post_content has block ids Since you have some post_meta in there from older versions, I recommend creating a new post and trying again from scratch. |
|
@asadrahbar The only reason that it appears to be working now is that it will be forced to fall back to the real field values for each field on the post, which will always be set to the last saved ACF Block's field values. Without a corresponding post_meta entry, the plugin has no way to efficiently override the field values for that specific block. The post meta entries for each block happen using the block attributes during the block's AJAX save call (instead of during rendering) in order to have better performance during block render. An AJAX save must occur on each block in order for things to work correctly. You'll know the AJAX save is working if your ACF Block looks like this at some point:
If the AJAX save is not working, check your browser's Javascript console for any errors. |
|
@asadrahbar If you could provid a temporary login to this site, I wouldn't mind taking a look at what's going on. |
Hey. If I create several blocks of the same type on the page, for example, testimonials, then the information entered in the last created block overwrites what was contained in the previous blocks of that type. I think it's a cache, but I can not figure out how to fix it. P.S. It's not a cache, just render elements with same id, name and etc. P.S.S Although, if the matter were in the same names, ids and etc, then changing data in any block of the same type overwrote old data in others, but it is not. P.S.S.S I think that happened because the same type blocks on one page have the same post_id. Look at the pictures:
Have you any ideas how fix it?) Sorry to trouble you)
The text was updated successfully, but these errors were encountered: