Answers.Body: <p>Craft has the project config feature for moving settings across environments.</p>
  <ul>
  <li>Official docs: <a href="https://craftcms.com/docs/3.x/project-config.html" rel="nofollow noreferrer">https://craftcms.com/docs/3.x/project-config.html</a></li>
  <li>PYLO article: <a href="https://putyourlightson.com/articles/understanding-project-config-in-craft-cms" rel="nofollow noreferrer">https://putyourlightson.com/articles/understanding-project-config-in-craft-cms</a></li>
  <li>CraftQuest video: <a href="https://craftquest.io/lessons/using-project-config-in-craft" rel="nofollow noreferrer">https://craftquest.io/lessons/using-project-config-in-craft</a></li>
  </ul>
  <p>Project config saves out database-stored settings as configuration files. Craft reads those in and applies changes.</p>
  <p>Ideally, you'd do this via a version control workflow, so you make the changes in your local environment, deploy them to staging, and then to production.</p>
  <p>For project config to work properly, you need to adhere to a workflow that flows one-way only. Make changes in one environment (e.g. local) and then move them upstream to staging and then production. You don't want to make changes in production while making them in staging or local. You'll have a mess with project config conflicts.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-02-02T00:29:41.910Z
Answers.Text: Our users won't be doing config changes on prod, but there will be content changes, are content changes independent of config changes?
Answers.UserDisplayName: lopu
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-02-04T16:23:50.950Z
Answers.Text: Yes, they are different. Content changes are tracked solely in the database and not in project config.
Answers.UserDisplayName: CraftQuest
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-02-01T02:25:39.707Z
Answers.LastActivityDate: 2022-02-01T02:25:39.707Z
Answers.UserDisplayName: CraftQuest
Body: <p>Has been a pleasure using Craft 3 for a while to build headless JAMstack websites.</p>
  <p>The issue we have run into is keeping our staging and production environments as separate as possible.</p>
  <p>We would ideally like to have 2 Craft instances running on different URLs, 1 where we can test adding and modifying fields for our headless staging frontend to use.</p>
  <p>And then 1 for production, where clients can add content, and where we can then apply the newly tested field updates.</p>
  <p>My thoughts on the way to do this would be the following.</p>
  <ol>
  <li>Make field updates on staging</li>
  <li>Test new field updates</li>
  <li>Switch prod into maintenance mode</li>
  <li>Push current prod state to staging (database export/import) and file changes.
  (ideally somehow merge prod's content updates with staging's field updates)</li>
  <li>Then push staging updates (merged with prod) back to prod.</li>
  <li>Disable maintenance mode</li>
  </ol>
  <p>The issues I predict is merging field updates with newly added content using old field types.</p>
  <p>I'm hoping that doing this doesn't require duplicate actions of adding fields through the GUI on both staging and prod once the feature has been approved on staging.</p>
  <p>Is there a field migratory maybe?</p>
  <p>Kindly, and thanks for any responses.</p>
  
Tags: <craft3><craft-features><craft-pro>
Title: Is there a way to keep fields synced between 2 craft instances
ThreadText: # Is there a way to keep fields synced between 2 craft instances
  
  (Asked by: username_0 on 2022-01-31)
  
  Has been a pleasure using Craft 3 for a while to build headless JAMstack websites.
  
  The issue we have run into is keeping our staging and production environments as separate as possible.
  
  We would ideally like to have 2 Craft instances running on different URLs, 1 where we can test adding and modifying fields for our headless staging frontend to use.
  
  And then 1 for production, where clients can add content, and where we can then apply the newly tested field updates.
  
  My thoughts on the way to do this would be the following.
  
  1. Make field updates on staging
  2. Test new field updates
  3. Switch prod into maintenance mode
  4. Push current prod state to staging (database export/import) and file changes.
     (ideally somehow merge prod's content updates with staging's field updates)
  5. Then push staging updates (merged with prod) back to prod.
  6. Disable maintenance mode
  
  The issues I predict is merging field updates with newly added content using old field types.
  
  I'm hoping that doing this doesn't require duplicate actions of adding fields through the GUI on both staging and prod once the feature has been approved on staging.
  
  Is there a field migratory maybe?
  
  Kindly, and thanks for any responses.
  
  **Tags:** craft3, craft-features, craft-pro
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2022-02-01. Score: 1
  
  Craft has the project config feature for moving settings across environments.
  
  * Official docs: <https://craftcms.com/docs/3.x/project-config.html>
  * PYLO article: <https://putyourlightson.com/articles/understanding-project-config-in-craft-cms>
  * username_1 video: <https://username_1.io/lessons/using-project-config-in-craft>
  
  Project config saves out database-stored settings as configuration files. Craft reads those in and applies changes.
  
  Ideally, you'd do this via a version control workflow, so you make the changes in your local environment, deploy them to staging, and then to production.
  
  For project config to work properly, you need to adhere to a workflow that flows one-way only. Make changes in one environment (e.g. local) and then move them upstream to staging and then production. You don't want to make changes in production while making them in staging or local. You'll have a mess with project config conflicts.
  
  > **Comments:**
  > **username_0**: Our users won't be doing config changes on prod, but there will be content changes, are content changes independent of config changes?  
  > **username_1**: Yes, they are different. Content changes are tracked solely in the database and not in project config.  
  
  ---
  
  