Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Idea summary
What is the problem to solve?
(Missing functionality X, prevent Y from happening, make Z easier to do)
Who is this for?
(Evaluators, site visitors, content authors, site managers, (advanced) site builders, frontend developers, backend developers, core developers, site owners, other?)
Result: what will be the outcome?
(Describe the result: how will this improve things for the stated audience(s)?)
How can we know the desired result is achieved?
(Usability test, a metric to track, feedback)
--- Original report ---
Follow-up to #2683085: Improve the message details in Broken Class in Block Module
Problem/Motivation
I feel like we need a better solution than just wording updates. Is there any way to force the creation of a stub block if the related UUID block_content doesn't exist? If we did that creation, that would make the problem solved by pane go away.
The above problem, combined with things like a read only filesystem for your live site makes the Site Building Experience (SBX) very bad of managing configuration surrounding blocks. Considering the bad SBX, marking as major.
Steps to reproduce:
- Install site on a read-only filesystem (platform.sh is read-only)
- Enable config_readonly in environment.
- Attempt to place a block in that environment. Failure. (Read-only disables the creation of a block, see #2728679: Remove 'Place block' from the block layout page when config is set to read only)
- Build the block on local.
- Export to config.
- Deploy to read-only environment. Failure. (This block is broken or missing. You may be missing content or you might need to enable the original module.)
- Disable config_readonly on read-only environment.
- Build the block that environment.
- Next, dump the entire environment's db (This is a huge DX failure)
- Import db into local. Add configuration to VCS.
- Push to read-only environment
- Re-enable config_readonly.
Proposed resolution
Something, anything.
Remaining tasks
TBD
Comments
Comment #2
heddnComment #3
jonathanshawWow, that is just awful.
However, I'm not finding it that easy to grasp the problem from the IS.
If I'm understanding it right, the core problem is that the block's config and content need to be created on the same environment, and this clashes with a typical good practice of developing config on local and pushing it to production through VCS, while content is created on master.
At the moment this central issues seems a bit buried in the middle of a sequence of things you might mistakenly try.
I suggest
1) clarifying what the basic problem is, assuming you know already that 1-3 will fail, and that you are intent on committing config to a VCS;
and then
2) describing separately the currently necessary workaround.
3) Things you might mistakenly try could be separate, if they're worth mentioning.
As a platform.sh customer it's a hot issue for me :)
Comment #4
heddnre #3: the crux is 8-10. One possible work-around (which I haven't tested yet) is to build a custom block type that allows a reference to a block_content item.
Comment #5
swentel CreditAttribution: swentel commentedThere's always https://www.drupal.org/project/simple_block for very simple content blocks.
Could be sub-issue of #2248369: [meta] Deploying configuration that depends on content
Comment #6
heddnre #5: that assumes I want to store the content in configuration. Which I don't, I just want to store the fact that a block exists on the homepage, push that to dev/stage/live and manage the block content as I would a node content item.
Thanks for a link to #2248369: [meta] Deploying configuration that depends on content. This is definitely either a duplicate or child of it.
Comment #7
jonathanshawSome thoughts then:
1) Are there any contrib modules implementing #2361423: Add a step to config import to allow contrib to create content based on config dependencies to solve this?
2) #2248369: [meta] Deploying configuration that depends on content#13 suggests the default_content module might be able to help. I'm not sure what that workflow would be.
3) I wonder if Features has anything that offers a way forward.
Comment #8
jonathanshawIt seem like #2249303: Implement fallback plugin for Block plugins is the key issue for this in practice.
According to #7 of that, it is possible to create a block on production, NOT PLACE IT, sync db to dev, place the block, export the config from dev back to production, and everything works fine.
Comment #10
tim.plunkett#8 is correct
Comment #11
heddn#8, I decidedly do not like having to sync the database to extract config. But I'm starting to use a more paragraph's driven workflow where I build a paragraph on a landing page content type and place the block via a block content reference in the paragraph. This avoids the problem entirely.
However, my work around doesn't fix the problem. It would be nice to create the container (from block module) in my local environment and place it. Then later create the related content. Or even better automatically create the related content item when first deployed to a environment. We already have all the config items for the related block, we are just missing the bock content itself (if it is a basic block). If it is a custom block backed by code, then the content is primarily driven by that code and "It Just Works" (tm) should be possible.
Comment #13
james.williams CreditAttribution: james.williams at ComputerMinds commented@heddn you can write update hooks to script the content creation. We've always used these in custom modules/profiles on deployments anyway, and ensure to run them before any config imports. For example, create a block with
\Drupal\block\Entity\Block::create($values)- and you can just hardcode a UUID inside the values there, to match the value in the config that you want to deploy. I recognise hardcoding a UUID feels nasty, so it's not ideal, but I hope you agree this is a much nicer solution that having to sync databases around!Comment #14
hoporr CreditAttribution: hoporr commentedCrosslinking issue: https://www.drupal.org/node/2756331
Comment #15
geerlingguy CreditAttribution: geerlingguy at Midwestern Mac, LLC commentedEither #2756331: Custom blocks cannot be properly exported and imported or this issue should probably be marked a duplicate.
Comment #16
yoroy CreditAttribution: yoroy at Roy Scholten commentedI agree with #3 that the problem is not yet that well described in the issue summary. Adding the "idea template" to the issue summary. Short answers to the 4 questions will help us compare and weigh ideas for their relative impact. Thank you!
Comment #17
yoroy CreditAttribution: yoroy at Roy Scholten commentedHmmm, I somehow thought this was in the ideas queue, sorry!
Might still be useful to clarify the actual problem a bit :)