Undefined index: instagram_lite_block_id when block is not created through core's Block Layout

Balu Ertl → made their first commit to this issue’s fork.

This is quite old MR so unsurprisingly a merge conflict arose:
→

Besides that improving the caching perspective is nice indeed but does not solve the original problem of the undefined index issue because the new approach still relies upon this non-existent array key at three places:

1. Line #461: $this->configuration['instagram_lite_block_id'] = $blockId;
   
2. Line #471: $cache_id = 'instagram_lite_media:' . $config['instagram_lite_block_id'];
   
3. Line #496: $this->logger->info('Instagram lite media data for %block_id has been purged.', ['%block_id' => $config['instagram_lite_block_id']]);

Anyway, back to the original issue. As far as I was able to track back the traces, the (possible) root cause is that the current way of obtaining a unique ID for the block instance is not prepared for those situations when $form_state->getBuildInfo() does not contain the needed value. Therefore we need to look for any other sources which we can obtain a unique block ID from. Here's an initial, half-baked draft that eliminates the exceptions and notices but definitely requires further polishing before the final merge.

Also updating the ticket title and description to reflect the situation more precisely.

Some further modifications were needed to get the block plugin class prepared for when required configuration keys are not present. Also some minor coding standard fixes.

The patch in #11 fixes the instagram_lite_block_id error but then causes an ajax error on submit for the block.

    if (isset($buildInfo['callback_object'])) {
      $this->configuration['instagram_lite_media_path'] = $buildInfo['callback_object']->getEntity()->uuid() . '/';
    }

In our case the 'callback_object' is Drupa\layout_builder\Form\UpdateBlockForm which unfortunately isn't an entity form and doesn't have a ->getEntity() method. Ironically the form does have a protected $uuid, but there's no way to get that uuid in this form.

I took a different approach. Here's a few changes/questions I'd like to propose.

Image directory

Saving to a block specific folder seems like it's going to be problematic to maintain. There are now several implementations of the block plugin and they don't have a very consistent way to be uniquely identified.

Is there a reason why we need to specifically save to a block specific folder? If we fetch the 'username' as part of the media request we could save the posts to a subdirectory that is username specific. This will work across blocks and still keep the blocks organized.

Purging files

In my opinion this should really be moved to a cron task. Deleting images on page load could be problematic, and it seems like we could be reusing the files if they exist instead of clearing them every time.

Storing #posts

I'm also not sure why there is a serialized save to the block with the posts. This is only going to be possible with block content entities, but also seems strange as caching should be already happening in the render layer since the files are saved to the local file system.

If I'm completely off base just let me know and I'll do another patch. I really appreciate this module, it seems like this module is the only one left that's actually working.

This is happening also on the 2.0.x-dev version.