Forum

Thread tagged as: Problem, Error, Blog

Disappearing Blocks

I've had a client email with an issue of "disappearing" blocks, which I've been able to successfully replicate. It's a bit wonky to describe, but I'll do my best (steps below the diagnostics and template).

I've been able to replicate this issue within the Blog app as well as in vanilla Pages content on a fresh install of 2.8.6.

Here are my diagnostics:

HEALTH CHECK

Perch is up to date
PHP 5.4.4 version is okay, but a little out of date. Consider updating soon.
MySQL 5.5.25 is up to date
Image processing available

SUMMARY INFORMATION

Perch: 2.8.6, PHP: 5.4.4, MySQL: 5.5.25, with PDO
Server OS: Darwin, apache2handler
Installed apps: content (2.8.6), assets (2.8.6), categories (2.8.6), perch_forms (1.8.2)
App runtimes: <?php $apps_list = array( 'content', 'categories', 'perch_forms', );
PERCH_LOGINPATH: /admin
PERCH_PATH: /path/to/admin
PERCH_CORE: /path/to/admin/core
PERCH_RESFILEPATH: /path/to/admin/resources
Image manipulation: GD
PHP limits: Max upload 128M, Max POST 128M, Memory: 512M, Total max file upload: 128M
Resource folder writeable: Yes
HTTP_HOST: local.website.come
DOCUMENT_ROOT: /path/to/website
REQUEST_URI: /admin/core/settings/diagnostics/
SCRIPT_NAME: /admin/core/settings/diagnostics/index.php

And here's my testing template code (with strange namespacing to rule out ID conflicts):

<perch:blocks>
  <perch:block type="block_test_1" label="Heading">
    <h2><perch:content id="block_test_1_text" type="text" label="Heading" /></h2>
  </perch:block>
  <perch:block type="block_test_2" label="Pull quote">
    <blockquote><perch:content id="block_test_2_quote" type="textarea" size="s" label="Quote" /></blockquote>
  </perch:block>
  <perch:block type="block_test_3" label="Feature image">
    <img src="<perch:content id="block_test_3_image" type="image" height="400" width="800" crop="true" label="Image" />" />
  </perch:block>
</perch:blocks>

Here's what I've concluded: If a new block is created from an unsaved block, and that initial unsaved block is deleted before saving, all "child" blocks of that unsaved, deleted block are also deleted upon saving.

To replicate the issue (using the above code as an example):

  1. Add a "Heading" and type in something
  2. Add a "Pull Quote" and type in something
  3. Delete the "Heading" block (via the X in the upper-right of the block, so it fades out of view)
  4. Leave the "Pull Quote" block in place
  5. Save the region
  6. The "Pull Quote" block is gone

And it's worth noting that ALL child blocks with a deleted, unsaved parent are lost.

However, if a new child block is created off of a previously-saved parent block, and that previously-saved parent is deleted, the child block is not deleted upon save.

Here's what I mean:

  1. Add a "Heading" block
  2. Save the region
  3. Add a "Pull Quote" block
  4. Delete the "Heading" block (via the X in the upper-right of the block, so it fades out of view)
  5. Save the region
  6. The "Pull Quote" block is NOT gone

In the meantime, I've suggested my client works in "Draft" mode and hits save before deleting any blocks. This will ensure that there is never an unsaved "parent" block that could cause child blocks to disappear. Put another way, as long as the "adding blocks" and "deleting blocks" phases are kept in-between saves, it's safe.

I hope that makes sense -- let me know if I can provide any further information.

Richard Terrick

Richard Terrick 3 points

  • 6 years ago
Drew McLellan

Drew McLellan 2638 points
Perch Support

What do you mean by parent and child? Blocks can't be nested.

Hey Drew,

I realize blocks can't be nested, so using parent/child was a poor choice of words on my part. Here are my definitions for the purpose of this bug report:

  • parent block = the block that has the block-add-bar that is used to spawn another block
  • child block = the block spawned via a block-add-bar of a specific block

This distinction is important because it seems to be directly related to the bug. Which is to say, when the block used to spawn other blocks via the block-add-bar is deleted before the region saved, all blocks spawned by it (either directly or indirectly) are gone when the region is saved.

Lol. I realize this must look like the ramblings of a crazy person... Blocks spawn child parent spawn delete rarrararrrr! So here's another test to help clarify.

Using the template code in the above post:

  1. Add a "Heading" block
  2. Repeat 3 more times, without saving the region -- use the block-add-bar from most recently created block each time to add the next block
  3. Delete the 3rd Heading block using the little X icon
  4. Save the region
  5. Both the 3rd and 4th Heading blocks are gone, because the 3rd block, which was deleted, was used to spawn the 4th block

You can take this same test and if you change which block is deleted you'll see the relationship I mean (of course you'll need to start fresh each time you run the test, as once a block is saved the bug no longer exhibits itself).

  • delete the first block, and they ALL disappear
  • delete the second block and blocks 2, 3, and 4 disappear
  • delete the third block and blocks 3 and 4 disappear
  • delete the fourth block and only block 4 disappears

Here's how it cropped up in the real world, with a client editing a blog post:

  1. Added a Heading
  2. Added a Feature Image
  3. Added a Textarea
  4. Added another Heading
  5. More Textareas
  6. Added more and more content
  7. Decided they didn't want that first Heading, so clicked the X button to remove it
  8. Continued editing content and rearranging blocks, spending time writing the post, etc.
  9. Saved the region (for the first time)
  10. Because the first Heading spawned (directly or indirectly) every block added after, once the region is saved EVERY block has disappeared (!!!)

Of course the argument could be made that this isn't the best way to write a post, but it happened, and my client was none to please for having his time wasted.

Hope that clears things up.

Drew McLellan

Drew McLellan 2638 points
Perch Support

The concept of blocks spawning other blocks simply doesn't exist. Leave it with me and I'll see if I can reproduce the error.

Whatever you call it, whatever concept exists or doesn't exist, all I know is content is not being saved, and I've been able to replicate it over and over.

Drew McLellan

Drew McLellan 2638 points
Perch Support

As I say, leave it with me and I'll see if I can reproduce the error.

Drew McLellan

Drew McLellan 2638 points
Perch Support

I've managed to reproduce the issue to some extent - what I can't tie down is this scenario where the choice of add-bar used makes any difference.

Fixes a bug where blocks were not always persisted if higher up blocks were deleted before saving

The 2.8.7 update resolved the issue above within the Pages app, but the problem still exists within Blog. Is an update to the Blog app required and forthcoming?

Drew McLellan

Drew McLellan 2638 points
Perch Support

It should be no different in Blog - it's all the same code.

I've just done a completely fresh install of Perch 2.8.7 and Blog 4.6 for the purpose of testing this bug and the issue is still present in Blog, while it's fixed in Content.

Which is to say, this code "works" in Content:

<perch:blocks>
  <perch:block type="block_test_1" label="Heading">
    <h2><perch:content id="block_test_1_text" type="text" label="Heading" /></h2>
  </perch:block>
</perch:blocks>

While this code, added to an otherwise untouched post.html template, still exhibits the bug in the Blog app:

<perch:blocks>
  <perch:block type="block_blog_test_1" label="Heading">
    <h2><perch:blog id="block_blog_test_1_text" type="text" label="Heading" /></h2>
  </perch:block>
</perch:blocks>

The only difference between the two blocks of code is the use of perch:content and perch:blog (and different IDs to rule out namespacing). Perhaps this points to the fix?

Please let me know if I can provide any further information.

Drew McLellan

Drew McLellan 2638 points
Perch Support

Thanks, we'll take a look at it.

Any updates Drew? Not wanting to be a pest, but anxious to get this update through to my clients.

Drew McLellan

Drew McLellan 2638 points
Perch Support

No, I've not looked at it yet.

Thanks for the quick reply. When will you be looking at it?

Drew McLellan

Drew McLellan 2638 points
Perch Support

I don't know. It's logged to be looked at for a future release.

Drew McLellan

Drew McLellan 2638 points
Perch Support

This should be now fixed in 2.8.8. Thanks for your patience!

Hey Drew. I appreciate the efforts, but it looks like the bug (or a slightly different version of it) is still present in Blog. I've updated my vanilla test build to 2.8.8 and am using the same code as before, in the stock post.html template. (I haven't tested from a fresh 2.8.8 build, only from updating 2.8.7.)

At first, things look good:

  1. Add three "heading" blocks - I've typed in "A", "B", and "C"
  2. Delete heading "A"
  3. Save region
  4. "B" and "C" are still present (yay!)

For a moment, I was rejoicing. However, if we start over:

  1. Add three "heading" blocks - "A", "B", and "C"
  2. Delete heading "B"
  3. Save region
  4. Only "A" is still present (ie, deleting "B" caused "C" to also disappear)

Furthermore (again, starting from a fresh blog post):

  1. Add three "heading" blocks - I've typed in "A", "B", and "C"
  2. Save region
  3. Add three more "heading" blocks - "D", "E", and "F"
  4. Delete "D"
  5. Save region
  6. Only "A", "B" and "C" are still present (ie, deleting "D" caused "E" and "F" to also disappear)

Here's my test blocks section again:

<perch:blocks>
  <perch:block type="block_blog_test_1" label="Heading">
    <h2><perch:blog id="block_blog_test_1_text" type="text" label="Heading" /></h2>
  </perch:block>
</perch:blocks>

And my diagnostics summary for the test build:

Perch: 2.8.8, PHP: 5.4.4, MySQL: 5.5.25, with PDO
Server OS: Darwin, apache2handler
Installed apps: content (2.8.8), assets (2.8.8), categories (2.8.8), perch_blog (4.6)
App runtimes: <?php $apps_list = array( 'content', 'categories', 'perch_blog', );
PERCH_LOGINPATH: /perch
PERCH_PATH: /path/to/perch
PERCH_CORE: /path/to/perch/core
PERCH_RESFILEPATH: /path/to/perch/resources
Image manipulation: GD
PHP limits: Max upload 128M, Max POST 128M, Memory: 512M, Total max file upload: 128M
Resource folder writeable: Yes
HTTP_HOST: local.perchtest.com
DOCUMENT_ROOT: /path/to/www.perchtest.com
REQUEST_URI: /perch/core/settings/diagnostics/
SCRIPT_NAME: /perch/core/settings/diagnostics/index.php

Again, I'm only seeing this behaviour in Blog, and not in Pages. Let me know if I can provide any further information.

Another, slightly more worrisome test showing "saved" content disappearing. Starting from a fresh blog post:

  1. Add three "heading" blocks - I've typed in "A", "B", and "C"
  2. Save region
  3. Delete "B"
  4. Save region
  5. Only "A" remains (ie, deleting "B" caused "C" to also disappear, even though the region was saved before deleting "B")

So from what I can tell, the first block is safe to delete, whether before OR after saving the region. If any other block is deleted at any time, all blocks below it will disappear.

Drew McLellan

Drew McLellan 2638 points
Perch Support

I'll take another look at it.

This issue appears to be solved in Perch 2.8.11. Thanks Drew!