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.
Updated: Comment #0
Problem/Motivation
We should use yml files so the uuid is consistent
Proposed resolution
Make yml files for comment and taxonomy term fields and instances used by forum module
Remaining tasks
Patch
Review
User interface changes
None
API changes
None
Related Issues
Follow-up from #2077435: Use a yml file to create the forum vocabulary.
Comment | File | Size | Author |
---|---|---|---|
#12 | interdiff.txt | 5.95 KB | andypost |
#12 | drupal8.forum-module.2106243-11.patch | 12.04 KB | andypost |
#10 | drupal8.forum-module.2106243-10.patch | 10.71 KB | jibran |
#10 | interdiff.txt | 3.47 KB | jibran |
#6 | interdiff.txt | 1.47 KB | larowlan |
Comments
Comment #1
larowlanWorking on this
Comment #2
andypostAlso there's related issue from list https://drupal.org/node/1653026#sub-tasks #2105963: Make sure all YML files in Forum module has no type-casting to string.
Comment #3
RainbowArrayComment #4
RainbowArrayWorked on this patch with larowlan's guidance. It doesn't get us all the way there due to the following issues:
https://drupal.org/node/2030073
https://drupal.org/node/2080823
Or at least that's part of the issue. The config files aren't loading in the correct order. They're loading by alpha order rather than by dependency.
Manually doing an entity load on the field was still leading to the same error when running the DBlog test, where on creating a forum topic, the forums select list is empty.
So this is a start. More work needed!
Comment #6
larowlanThis includes #2077435: Use a yml file to create the forum vocabulary so should be postponed on that (but want a test run first).
Comment #7
larowlanmmm green
Comment #8
larowlanwaiting on #2077435: Use a yml file to create the forum vocabulary
Comment #9
larowlan#2077435: Use a yml file to create the forum vocabulary is in
Comment #10
jibranInterdiff contains manual changes in
core/modules/forum/forum.install
.Comment #11
larowlanyay forum_install() looks so. much. cleaner.
Comment #12
andypostThe approach with comment body field is not working so I changed the field to
forum_comment_body
- I think it makes sense to store comment body for forum content in separate tableAlso added uuid for 'General discussion' forum to disallow duplicate creation when module re-installed
EDIT related
#1969800: Add UUIDs to default configuration
#2106459: Core config has everything as string
Comment #13
larowlanOh nice! I thought of this then thought it wasn't possible to specify a uuid. This is awesome, especially for deployability.
There are several places in core that specify ->comment_body. For example:
When you say 'The approach with comment body field is not working' can you specify why/where?
Comment #14
andypostthere's some reasons:
1) I got failure twice when installed forum module with error that instance can't be created without field (field is deleted when last instance removed - remove article content and then try to install forum)
2) performance - having separate table for body makes queries faster
3) deployment of separate table seems more useful
suppose it's easy to fix rdf and other tests
Comment #15
larowlanI guess the other option is to check for the field in forum module preinstall?
Comment #16
larowlanI guess the other option is to check for the field in forum module preinstall?
Comment #17
larowlanCan #1426804: Allow field storages to be persisted when they have no fields. help here?
If they comment body field can't be removed (even if no instances) then the problem goes away yeah?
Comment #18
andypost@larpwlan all your point are valid. But I still think that better to have separate fields for forum
Comment #19
Berdir12: drupal8.forum-module.2106243-11.patch queued for re-testing.
Comment #21
larowlanFixed by other CMI issues