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.
Follow-up to #2374087: Create a persistent comment body field storage
We can now persist field storages. We should not create block_content body field storage in code since that means it is possible to deploy a field storage different from the type assumed in block_content_add_body_field()
. It also means that contrib or custom modules can rely on the field storage being present. See #1426804: Allow field storages to be persisted when they have no fields.
Comment | File | Size | Author |
---|---|---|---|
#18 | 2374125.18.patch | 15.99 KB | alexpott |
#17 | 2374125.17.patch | 16 KB | alexpott |
#17 | 14-17-interdiff.txt | 2.02 KB | alexpott |
#14 | 2374125.14.patch | 17.34 KB | alexpott |
#14 | 10-14-interdiff.txt | 6.19 KB | alexpott |
Comments
Comment #1
alexpottI've move the basic block content type to the Standard profile since this is inline with the Node module and it will fail with this patch because it tries to create the body field before the storage exists. I think we should go the whole way in this issue and remove...
From the BlockContentType entity and put this functionality in the UI. We should try to avoid all side effects in configuration entities - especially those that create other configuration entities.
Comment #3
alexpottWe can stop adding body fields by default like so...
Comment #5
BerdirThe component name is outdated, but comment is certainly not correct either ;)
Comment #6
alexpottThanks @Berdir.
Here's a patch the fixes all the tests. For me the only remaining question is should be introduce (or keep) some generic functionality somewhere to add the body field to block content type. And if the answer is yes - where?
Comment #8
alexpottSo it turns out migrate has a hard dependency on the basic block content type existing so we need to create one (and it's body field) through a migration. The migration tests are tricky but they caught this so huge++
Comment #10
alexpottSo I think the schema for
migrate.source.empty
is a bit tricky - we should just ignore the constants here - anything could be in there. This can be used to create anything migrate can create.Comment #11
alexpottComment #12
larowlanPutting on my list to review
Comment #13
yched CreditAttribution: yched commentedLooks like this needs a reroll - I reviewed on top of 55b8558.
So the three "body fields autocreated on 'bundle create' form submit" in core end up using three different patterns:
- node body: a legacy node_add_body_field_function()
- comment body: a public addBodyField() on CommentManager
- block body: an internal helper method on the BlockContentTypeForm()
That's a bit unfortunate ?
Unless I'm missing smthg, looks like having a body field isn't actually needed for that test ?
Comment #14
alexpottblock_content_add_body_field()
and used it everywhere. So now node and block_content are the same - and this set of related issues has not really changed anything wrt to the difference between them and comment.Comment #15
yched CreditAttribution: yched commented@alexpott: thnks - then aren't there tests modified here that could simply use block_content_add_body_field() instead of receiving new verbose code ?
Other than that, looks fine to me, but I'll let @larowlan review.
Comment #17
alexpottSilly me. Didn't remove the the method on the form creating a body field.
Comment #18
alexpottRerolled - conflicted with #2346039: Add missing migrations to MigrateDrupal6Test and fix the result in core/modules/migrate_drupal/src/Tests/d6/MigrateDrupal6Test.php
Comment #19
larowlanCan't see anything wrong with this - thanks!
Comment #20
catchLooks fine.
Committed/pushed to 8.0.x, thanks!