Answers.Body: <p>Project config is designed to sync the architecture of your site, not the content, so structural changes can be made without affecting the content. Forms are seen as content, like entries, so this would be the expected behaviour.</p>
  <p>The suggested workflow would be to create the form on the production site, then pull to local environment to do any front-end work, then push those changes to production.</p>
  <p>The <a href="https://github.com/nystudio107/craft-scripts" rel="nofollow noreferrer">nystudio107 craft scripts</a> are pretty useful for syncing databases and assets if needed.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-07-04T12:15:26.520Z
Answers.Text: Then again, static translations are also content
Answers.UserDisplayName: Urs
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-07-04T21:25:47.857Z
Answers.Text: But they’re not stored in the database so aren’t effected by the issues that project config solves.
Answers.UserDisplayName: dmatthams
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-07-05T11:48:20.730Z
Answers.Text: Yeah, just sayin that there are also other places where that separation isnt complete. Imho translations should be in the database as well. The reason they‘re not is just performance. A solution (getting off topic) might be an extension that stores translations in the db and writes a copy to the code base. Like a reverse project config
Answers.UserDisplayName: Urs
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-07-06T09:38:14.853Z
Answers.Text: I understand where you're coming from, but I find the easy way to think about it is that if it can be edited by the client, then it is out of the scope of project config.
Answers.UserDisplayName: dmatthams
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-07-06T20:46:13.343Z
Answers.Text: Yeah I just think client should also be able to edit translations (not only freeform, talking generally)
Answers.UserDisplayName: Urs
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-07-07T09:23:20.047Z
Answers.Text: This plugin may help you do that: https://plugins.craftcms.com/translations-admin
Answers.UserDisplayName: dmatthams
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-07-03T11:18:00.790Z
Answers.LastActivityDate: 2020-07-03T11:18:00.790Z
Answers.UserDisplayName: dmatthams
Answers.Body: <p>In my experience none of the Solspace plugins migrate their admin stuff the &quot;Craft&quot; way.</p>
  <p>I would not recommend <code>useProjectConfigFile</code> if you are using Freeform or Calendar, as this will lead to confusion.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-07-01T20:52:13.747Z
Answers.Text: Apparently freeform sees the form as content, not as definition. Indeed, this has proven a tad acrobatic: edit the form in the live instance, but add translations in the codebase on local. I found my workflow now; I have a sync-script that downloads the entire database to ddev on one command. It's not magic, and you still have to keep your head together as hell, but if it helps I can share it –
Answers.UserDisplayName: Urs
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-07-01T15:04:34.677Z
Answers.LastActivityDate: 2020-07-21T14:32:12.703Z
Answers.LastEditDate: 2020-07-21T14:32:12.703Z
Answers.UserDisplayName: Steve Mock
Body: <p>On my development instance, I added a freeform form. Now I would like to deploy that form to the staging, or later, live site. </p>
  
  <p>When committing my changes, I noticed that nothing was added to <code>project.yaml</code>. So I guess the changes are just saved in the DB and will not be synced at git-based deploy.</p>
  
  <p>Is that by design? Can I enable <code>useProjectConfigFile</code> somewhere?</p>
  
  <p>If not: how do I export the form definitions and deploy them to another instance? By MySQL?</p>
  
Tags: <plugin-freeform>
Title: Freeform with project.yaml?
ThreadText: # Freeform with project.yaml?
  
  (Asked by: username_0 on 2020-05-10)
  
  On my development instance, I added a freeform form. Now I would like to deploy that form to the staging, or later, live site.
  
  When committing my changes, I noticed that nothing was added to `project.yaml`. So I guess the changes are just saved in the DB and will not be synced at git-based deploy.
  
  Is that by design? Can I enable `useProjectConfigFile` somewhere?
  
  If not: how do I export the form definitions and deploy them to another instance? By MySQL?
  
  **Tags:** plugin-freeform
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2020-07-03. Score: 1
  
  Project config is designed to sync the architecture of your site, not the content, so structural changes can be made without affecting the content. Forms are seen as content, like entries, so this would be the expected behaviour.
  
  The suggested workflow would be to create the form on the production site, then pull to local environment to do any front-end work, then push those changes to production.
  
  The [nystudio107 craft scripts](https://github.com/nystudio107/craft-scripts) are pretty useful for syncing databases and assets if needed.
  
  > **Comments:**
  > **username_0**: Then again, static translations are also content  
  > **username_1**: But they’re not stored in the database so aren’t effected by the issues that project config solves.  
  > **username_0**: Yeah, just sayin that there are also other places where that separation isnt complete. Imho translations should be in the database as well. The reason they‘re not is just performance. A solution (getting off topic) might be an extension that stores translations in the db and writes a copy to the code base. Like a reverse project config  
  > **username_1**: I understand where you're coming from, but I find the easy way to think about it is that if it can be edited by the client, then it is out of the scope of project config.  
  > **username_0**: Yeah I just think client should also be able to edit translations (not only freeform, talking generally)  
  > **username_1**: This plugin may help you do that: https://plugins.craftcms.com/translations-admin  
  
  ---
  
  ### Answer by username_2 on 2020-07-01. Score: 0
  
  In my experience none of the Solspace plugins migrate their admin stuff the "Craft" way.
  
  I would not recommend `useProjectConfigFile` if you are using Freeform or Calendar, as this will lead to confusion.
  
  > **Comments:**
  > **username_0**: Apparently freeform sees the form as content, not as definition. Indeed, this has proven a tad acrobatic: edit the form in the live instance, but add translations in the codebase on local. I found my workflow now; I have a sync-script that downloads the entire database to ddev on one command. It's not magic, and you still have to keep your head together as hell, but if it helps I can share it –  
  
  ---
  
  