<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>

CC BY-SA 4.0
2020-07-04T12:15:26.520Z
Then again, static translations are also content
Urs
CC BY-SA 4.0
2020-07-04T21:25:47.857Z
But they’re not stored in the database so aren’t effected by the issues that project config solves.
dmatthams
CC BY-SA 4.0
2020-07-05T11:48:20.730Z
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
Urs
CC BY-SA 4.0
2020-07-06T09:38:14.853Z
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.
dmatthams
CC BY-SA 4.0
2020-07-06T20:46:13.343Z
Yeah I just think client should also be able to edit translations (not only freeform, talking generally)
Urs
CC BY-SA 4.0
2020-07-07T09:23:20.047Z
This plugin may help you do that: https://plugins.craftcms.com/translations-admin
dmatthams
CC BY-SA 4.0
2020-07-03T11:18:00.790Z
2020-07-03T11:18:00.790Z
dmatthams
<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>

CC BY-SA 4.0
2020-07-01T20:52:13.747Z
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 –
Urs
CC BY-SA 4.0
2020-07-01T15:04:34.677Z
2020-07-21T14:32:12.703Z
2020-07-21T14:32:12.703Z
Steve Mock
<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>

<plugin-freeform>
Freeform with project.yaml?
# 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 –  

---

