Blocks in block editor have vanished, but they do exist

[mikerockett]

Description

I've seen this a few times now, and not 100% sure how to reproduce, but from time to time, the block editor in a module fails to render for all items, only showing an "Add content" button.

Edit: Once it has disappeared from one editor, it affects all modules.

The last time this happened, all I did was expand all blocks in the editor, and then collapse them again – I did not save anything.

I checked the JS code being hydrated, and the form.blocks assignment is not present at all – ie, this one:

twill/views/partials/form/utils/_block_editor_store.blade.php

Line 1 in 6457e56

window['{{ config('twill.js_namespace') }}'].STORE.form.blocks = {!! json_encode($form_fields['blocks'] ?? []) !!}

However, when I view the item on the site, the blocks render perfectly fine, which means they are accessible. But, if I were to go back to the editor and save the item, the blocks will disappear – so now, I'm unable to save without destroying the entire item.

I'll do some more digging to see what I can find – my hope is that something on my end is breaking the flow of things on the backend (even though I doubt it – it's not a super custom setup).

Versions

Twill version: 3.0.2
Laravel version: 10.13.5
PHP version: 8.1
Database engine: Postgres 15

[mikerockett]

I think I know what this is related to, but not able to determine the source of the issue as yet. I run my app on Octane (with Swoole), and my guess is that a static something, somewhere, is not playing nice as restarting services fixes the issue.

Update: Definitely related to Octane. After restarting services, I loaded up one of the editors containing a block editor, and the blocks appeared. Refresh the page, and gone.

I think it might be due to what I'd done in #2281, which is to create singletons for the different services, including TwillBlocks. I see it as a 'hotfix' and may have overdone it, so I'll dig a little more to see what I can find. It's a pity, because in this case, I get no errors of any kind – which makes sense, as something is being emptied or unset somewhere, and that is persisting to the next request.

[mikerockett]

I’m not able to test this theory right now, but I think that this has to do with the custom pushonce blade directive, which sets arbitrary properties on the View factory, and these properties persist between requests.

In this case, there is a pushonce call for vuexStore:block_editor. An identifier of sorts is then created, pushed as an arbitrary property with a value of 1, and that is then persisted to the next request.

[mikerockett]

Ok, that was indeed it – arbitrary props on the view factory. In any case, Laravel does have a baked in @pushOnce handler, so I'll open up a PR to switch to that.

In the meantime, and in case anyone else has bumped into this, it’s as simple as overriding the pushonce directive as follows (in a service provider’s boot method):

$blade = $this->app['view']->getEngineResolver()->resolve('blade')->getCompiler();

$blade->directive('pushonce', function ($expression) {
  [$stack, $id] = explode(':', trim(substr($expression, 1, -1)));
  $id = implode(':', [$stack, $id]);

  return <<<PHP
    <?php if (! \$__env->hasRenderedOnce('$id')): \$__env->markAsRenderedOnce('$id');
    \$__env->startPush('$stack'); ?>
  PHP;
});

This is different to pushOnce, which takes two arguments instead of a colon-delimited string.

[adss332]

@mikerockett Hello, i added the same code in boot method, but it doesnt work for me unfortunatelly, did u find any different decision to solve that problem? Thank u in advance!

[mikerockett]

@adss332 No, as the custom directive works for me. Hopefully #2301 can be merged.