Score:0

Attach a webform to a content type such that you fill out the webform when editing the content

cn flag

Adding an entity reference of type Webform makes it so when creating the content, the specific webform can be selected and it can be set to open or closed, but the webform is filled out by people viewing the content, rather than by content creators when editing the content.

Another sort of entity reference could theoretically make it so the webform is shown when creating/editing the node or other content (or user), and the resulting webform submission retains a one-to-one relationship with that piece of content: The webform result can be shown when viewing the content, and when the content is edited the webform data can also be edited at the same time.

Is there a way to do this through entity reference and an inline entity form?

(I do not think so, so have already opened up a feature request, A content editor can fill out a webform embedded in a node edit form [#3347845] | Drupal.org but still looking and hoping there's a way, or someone has custom code to do similar or advice on how to do this even if it requires creating a module.)

in flag
This might be an [XY problem](https://meta.stackexchange.com/a/66378). A webform or inline entity form might be the wrong solution to begin with. Can you explain the requirement, and why you need a form inside a form?
cn flag
@Joseph 1. Already built with nodes by a previous developer. 2. Content workflow. 3. Essentially as noted in the feature request this allows a sort of dynamic fields, say five are fixed and allows your content to work with and as content, but you can choose different editor-defined webforms with extensive different fieldsets. 4. Give content managers lots of power (making webforms) without having to become sitebuilders (modifying (horrifyingly complex) content types).
in flag
Sounds like something [Paragraphs](https://www.drupal.org/project/paragraphs) can do. It's content, it can be revisioned/moderated with the host content, you can define multiple types containing different fields, can be filled and displayed together with content, works in both Field UI and Layout Builder. If your content admins are comfortable building webforms, then building paragraph types should be just as easy.
mx flag
Webforms are a way to collect similar data that can be gathered together, maybe run some stats on it, and empowering site editors doesn't sound like a stats kinda task. If editors have a set of preferred components to use in creating new content (as they should) they can give you that list and you can create Paragraphs for them, so Paragraphs can be used in Fields when creating content. Seems like you just need to recreate existing Webforms components as Paragraphs or [Bricks](https://www.drupal.org/project/bricks)
cn flag
The general point/purpose that keeps getting missed is it is typical to allow editors to create webforms, and *not* to create content types or paragraphs. That's where the idea of putting them together comes from: sitebuilder tools stay sitebuilder tools (content types / paragraphs / fields) but we give a similar ability to editors to define part of what is collected when editing content by defining webforms that can be paired there.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.