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.
I've seen a bunch of issues by people struggling with the way config is handled. Since many site editors (not site builders or devs) would like to be able to add / edit forms, one could argue that the YAML Forms should indeed be content entities.
I can see that this is a big change and would probably not be easy. It should not be done without some greater discussion about this, but I do think this is something to think about. Would you be open to this?
Comments
Comment #2
jrockowitz CreditAttribution: jrockowitz commentedI am absolutely not for changing YAML Form's from config entities to content entities.
The fact that any entire form can be represented and exported as single file has significantly helped me to build, debug, and maintain this module. I have also been able to create and maintain test forms for every single form and element feature.
The real issue is how Drupal 8 is handling config entities and requiring all config entities to updated when performing config exports and imports.
People are working on addressing this issue.
Comment #3
yobottehg CreditAttribution: yobottehg commentedI wanted to propose the same issue as i'm having trouble with configuration deployment because of the forms.
In my opinion form templates should be configuration but forms itself should be a content entity like it is in cores contact module.
I understand that its easier for testing purposes but perhaps we could create forms based on the templates which are config for testing ?
Comment #4
jrockowitz CreditAttribution: jrockowitz commentedI am also having the same issue with blocks that are edited on the production website. Contact forms are also configuration.
Have you tried using CMI tools?
Comment #5
seanBI agree that the way core handles config is not working well for blocks, contact forms and yaml forms. In my opinion they could all be viewed as content.
CMI tools can solve the issue, but the general concept of yaml forms being content is still something we could discuss.
Comment #6
fenstratMoving to Webform queue, see #2827845: [roadmap] YAML Form 8.x-1.x to Webform 8.x-5.x.
Comment #7
jrockowitz CreditAttribution: jrockowitz commentedComment #8
mcpuddin CreditAttribution: mcpuddin commentedJust to pipe in on this conversation, from my experience, webforms are something historically created by content editors, while blocks are something created by site builders or developers. Content editors typically live on live while site builders / developers live on dev. With that said, when you have most Drupal websites who probably follow this similar workflow where they've treated webform as content, it's going to be quite a showdown come the near future as this module will probably be one of the key building blocks of Drupal 8.
I have created a similar issue #2848992: Webform Workflow on Live to get advice on how to deal with this from a workflow perspective.. especially if you want to do it independent of a developer.
Comment #9
mcpuddin CreditAttribution: mcpuddin commentedHonestly, looking into drush cmi tools does seem like a good solution given the benefits of having webform in config. So basically by ignoring the entire Drupal configuration system and drush and instead using the 3rd party drush scripts does seem like an idea that could work. I'm going to look into that more....
Comment #10
mcpuddin CreditAttribution: mcpuddin commentedJust as a note, talking with our team members, we enabled a module called EntityQueue and had 1,400 different queues which were also Config Entities. Having that many config entities hosed the system. It sounds like using Config Synchronization system was designed well but did not do good with flexibility of workflows nor with scalability. So what I'm trying to say is deciding to use Config Entities for Webforms sounds great for speed and development, but not good for large scale production. Definitely would like that not to be true and to be hear counter arguments...
Comment #11
jrockowitz CreditAttribution: jrockowitz as a volunteer and commentedI agree that the Config Synchronization system needs to be more flexible. In the long term, Drupal needs to allow config to occasionally be treated as content and even allow content to treated as config. It would be nice to manage certain nodes (and paragraphs) using code.
The pattern that a Webform is a config entity that is used as the 'bundle' for a Webform submission content entity, this is a fundamental core pattern. This is the same pattern used to manage Content types to Nodes, Vocabularies to Terms, and more...
Personally, I am still not comfortable exporting all my config from my dev environment and importing it into production. I manage my configuration updates using partial config imports via drush (called from an update hook) and sometimes I will just update the config file via code.
Finally, I think core needs to provide a hook to ignore certain config, this would solve a lot of problems.
Comment #12
seanBI think we can all agree core could use more flexibility in the config import/export section. That could solve a lot!
I'm not sure though if you can compare a webform with a content type or vocabulary in the way it's being used (even though technically you can use the same pattern). Content types and vocabularies are mostly created by sitebuilders, while webforms are traditionally more likely being created by editors. There are lot's of examples of sites with hundreds (even thousands) of webforms, while finding sites with hundreds or thousand of content types/vocabularies are a lot less common.
Does anyone have any insight on how scalable the config entities are? If it is not a problem to have thousands of config entities and the flexibility for config import/export is fixed this will probably work out fine. If not, it is good to at least know the limitations we are dealing with.
By the way, I do want to thank jrockowitz for his hard work on getting a very nice webform module for D8. Even though we might disagree on the config vs content thing, the module is a vital part to most Drupal 8 sites I'm currently building, and will build in the future. Just think that was worth being said :)
Comment #13
jrockowitz CreditAttribution: jrockowitz as a volunteer and commentedThe key take away from my "webform to submissions" vs "vocabulary to terms" comparison is that I am leveraging a predefined pattern used in Drupal core which significantly reduces the amount of code required to manage and store submissions.
Configuration is imported from the file system into a single database table The performance bottleneck is probably happening when core is trying to figure out dependencies during a config import.
The good news is that the Webform config entity has literally no dependencies which should make it very easy and fast for core import any changes to a Webform.
I am been searching core's issue queue and I am not seeing anyone complaining about configuration import performance issues or limitations.
Comment #14
mcpuddin CreditAttribution: mcpuddin commentedWe've run into issues with heavy config's like entityqueue. Webform is a heavier config as well.. A good test would be to create a thousand random webforms with 10-20 elements, and see if Drupal can work. It completely hozed us when we did that for entityqueue, but then again, we didn't debug and just decided to go with a homegrown solution that didn't use config.
Comment #17
mcpuddin CreditAttribution: mcpuddin commentedWe tried config_ignore and it did a good job of protecting the webforms but with multiple deploys a day, we'd either have to suffer the warnings it throws on import or always be exporting updates on live. Both just added much more work for the developers pushing. Unfortunately we haven't found an easy workflow that the developers were happy with.
Comment #18
albertski CreditAttribution: albertski at Xeno Media, Inc. commented@mcpuddin I went with a combination of Configuration Split and Config Ignore following this blog and it seems to be working great (I believe they recently added the ability to not add a folder which may prevent the warning you were receiving).Comment #19
albertski CreditAttribution: albertski at Xeno Media, Inc. commented@mcpuddin after trying it some more I did not get it to work. I created issue: #2883110: How to exclude configuration.
Comment #20
seanBMaybe you can try this, I found this to be very helpful. https://blog.liip.ch/archive/2017/04/07/advanced-drupal-8-cmi-workflows....
Comment #21
albertski CreditAttribution: albertski at Xeno Media, Inc. commentedThanks @seanB that way did work. Also, I was able to get the method I mentioned above to work as well. Just had to make my ignore config slpit have a negative weight so it is called first.
Comment #22
optimusprime619 CreditAttribution: optimusprime619 commentedHi, my apologies if I am mistaken or asking an invalid query with reference to the current context. But does being a configuration entity not prevent webform from being revisionable in the future? (based on https://www.drupal.org/node/1818734)
I understand that it is possible to have revisioning for webform node content type and am also aware that not everyone would have the same requirement as me in needing webform to be revisionable or subjected to a workflow similar to content types like articles or page. Some insight regarding the same would be very helpful.
@jrockowitz can't stress enough on how awesome you are with the module updates and the tutorial videos. Thank you!
Comment #23
jrockowitz CreditAttribution: jrockowitz as a volunteer and commentedWebforms (and config entities) are not revisionable via Drupal 8 core. It is also important to note that Webforms, which were nodes, in previous versions of Drupal were also not revisionable.
Comment #24
optimusprime619 CreditAttribution: optimusprime619 commented@jrockowitz Thank you very much for the response and clarity on this.
Comment #25
Alumei CreditAttribution: Alumei commentedInstead of trying to make config behave more like content to support the content like use case.
How about using BundlePlugins provided by the Entity API module to cater to both.
The Idea would be to use plugins to describe the webform definition storage behavior. One for Config and one for Content. Using plugin derivatives to generate plugin definitions for each available webform, stored in content or config respectively.
Comment #26
jrockowitz CreditAttribution: jrockowitz as a volunteer and commentedNow that there is a release candidate, it is time to close this discussion.
@Alumei This blog post as includes information about using Drush CMI Tools.
Comment #27
jrockowitz CreditAttribution: jrockowitz as a volunteer and commentedComment #28
thtas CreditAttribution: thtas commentedI realise this issue is closed, but figure this might be a good place to leave this for people searching like i was.
This sandbox module is inspired by the comment here. It switches out the webform storage class for one which uses KeyValueStorage instead of the default YAML storage. Seems to work ok but it's far from battle tested. so it's far from using Nodes to store webform config, but it at least helps remove your webforms from the CMI processes.
https://www.drupal.org/sandbox/thtas/2994250
Comment #29
BarisW CreditAttribution: BarisW at LimoenGroen for gemeente Leidschendam-Voorburg commentedThere's also https://www.drupal.org/project/webform_config_ignore
Comment #30
mpp CreditAttribution: mpp at District09 for District09 commentedFor the record, I don't agree with this statement. Webforms are an editorial feature (content), not a webmaster feature (configuration).