Removing Fields on update

  • Resolved lewisself

    (@lewisself)


    5 years, 4 months ago

    Hello,

    I’ve been using blocklab for a few days now and every time I create a block and template it works perfectly. However, when coming back to a block to edit and update the block fields it seems to delete some of them. I’ve tried to work out which ones were being deleted but sometimes it was just one, sometimes two.

    To debug the problem I created a fresh WordPress install with twentyNineteen activated and only the block lab plugin. The issue still occurs for me. The console log shows no errors as well so I’m quite confused about what the problem could be.

Viewing 11 replies - 1 through 11 (of 11 total)
  • Thread Starter lewisself

    (@lewisself)

    I forgot to mention, I double checked the slugs were different as I know duplicates are deleted

    Plugin Author Ryan Kienstra

    (@ryankienstra)

    Hi @lewisself,
    Thanks a lot for bringing this up, and for testing this with a fresh WordPress install.

    1. This is happening in the Block Lab UI, like this, right?
    https://cldup.com/6rxZ5mJvMW.png

    2. It sounds like the fields were deleted on clicking ‘Update’, right?

    3. What fields were present before the fields were deleted, and what fields were deleted? For example, in the screenshot above, there’s a ‘Range’ field. Before and after screenshots would be really helpful, if possible.

    4. What versions of Block Lab and WordPress is this using, if not the latest?

    Thanks!

    • This reply was modified 5 years, 4 months ago by Ryan Kienstra.
    Thread Starter lewisself

    (@lewisself)

    Thanks for getting back to me Ryan.

    Yes It was when using the blocklab UI and when updating an existing block.

    https://www.lewisself.co.uk/block-lab-test.png – I added an additional text field and this is the new block after updating – https://www.lewisself.co.uk/block-lab-test-2.png

    I’m running WordPress 5.2.2 and blocklab 1.3.3. After having a look again, could it be some conflicts with naming my fields?

    Plugin Author Ryan Kienstra

    (@ryankienstra)

    Hi @lewisself,
    Thanks for the details. If it’s alright, I’ll look at this tonight.

    Plugin Author Ryan Kienstra

    (@ryankienstra)

    Request To Test

    Hi @lukecarbis,
    Good to see you earlier. Could you please try to reproduce this? I couldn’t ??

    After mainly recreating the screenshot above:

    https://www.lewisself.co.uk/block-lab-test.png

    …and adding a text field, it saved as expected:

    https://cldup.com/gGDPmTz372.png

    Maybe something is happening somewhere in save_block(), but I can’t tell where:

    https://github.com/getblocklab/block-lab/blob/ff62e03c8de8c9a427e77772191a4d0636fc576d/php/post-types/class-block-post.php#L866

    Thanks, Luke!

    • This reply was modified 5 years, 4 months ago by Ryan Kienstra.
    Plugin Author Ryan Kienstra

    (@ryankienstra)

    Hi @lewisself,

    After having a look again, could it be some conflicts with naming my fields?

    Hm, I’m not sure if that’s the issue. In the screenshots above, all of the fields have different names:
    https://www.lewisself.co.uk/block-lab-test.png
    https://www.lewisself.co.uk/block-lab-test-2.png

    Did you ever add a field with the same name as one in the block? In that case, yes, it’d be expected that the new field with the duplicate name didn’t save.

    For example:
    https://cldup.com/UykJ4z-9v8.png

    Thread Starter lewisself

    (@lewisself)

    Hi Ryan,

    I’m wondering now if it could be something to do with my localhost, I’m using laragon. I’ll set up a new WordPress install on my live website and see if I can reproduce the issue.

    Does the save_block function run when the block is first published? It works fine the first time, it’s when I come back to edit the block that I get some fields being deleted.

    I made sure that all the field names and slugs were different but I meant if it’s somehow conflicting with something in WordPress.

    I’ve also noticed that you have the Gutenberg plugin installed when trying to reproduce this, could you give it a test without and see if it makes a difference? I didn’t have this installed on the sites.

    • This reply was modified 5 years, 4 months ago by lewisself.
    • This reply was modified 5 years, 4 months ago by lewisself.
    Thread Starter lewisself

    (@lewisself)

    I made a subdomain on my live website and it works as expected. My Localhost PHP and MySQL versions are as follows

    PHP: 7.1.14
    MySQL: 5.7.19

    After updating these to the following, the issue was resolved.

    PHP: 7.2.19
    MySQL: 5.7.24

    • This reply was modified 5 years, 4 months ago by lewisself.
    Plugin Author Ryan Kienstra

    (@ryankienstra)

    Hi @lewisself,
    Thanks for testing this again.

    Does the save_block function run when the block is first published? It works fine the first time, it’s when I come back to edit the block that I get some fields being deleted.

    Yes, save_block() runs on first publishing a block.

    I’ve also noticed that you have the Gutenberg plugin installed when trying to reproduce this, could you give it a test without and see if it makes a difference? I didn’t have this installed on the sites.

    Good point. I tested this with Gutenberg disabled and WP Core 5.2.2, and couldn’t reproduce it there:

    https://cldup.com/Pd0eVbnACb.png

    After updating these to the following, the issue was resolved.

    Interesting, I’m not sure why it wouldn’t work on PHP 7.1.14.

    Thread Starter lewisself

    (@lewisself)

    In order to update the PHP and MySQL versions I had to update laragon itself. When setting the PHP version back to 7.1.14 I couldn’t reproduce the problem. I have a feeling it’s probably some issue with Laragon.

    Thanks for all your help though.

    Plugin Author Ryan Kienstra

    (@ryankienstra)

    Hi @lewisself,
    Thanks, that’s good to hear that it’s working now.

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘Removing Fields on update’ is closed to new replies.