Answers.Body: <p>You might have more luck over at the <a href="https://github.com/craftcms/cms/issues" rel="nofollow noreferrer">Craft GitHub Issues</a> site. Generally it's the place to go if you've got suggestions / feedback. This Stack Exchange site is used more for specific questions that need answers.  </p>
  
  <p>UPDATED: Added link to the GitHub Issues site as per Brandon's comment below.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-24T17:46:54.810Z
Answers.Text: Agree! Did that.
Answers.UserDisplayName: Janis Taranda
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-24T17:55:28.023Z
Answers.Text: FFR we’re transitioning to [GitHub issues](https://github.com/craftcms/cms/issues) for feedback and bug reports ;)
Answers.UserDisplayName: Brandon Kelly
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-24T16:23:38.100Z
Answers.LastActivityDate: 2017-02-24T18:17:05.963Z
Answers.LastEditDate: 2017-02-24T18:17:05.963Z
Answers.UserDisplayName: Steve Holland
Answers.Body: <p>I do not know where your problem is? In Wordpress, you can build pages with CustomFields, and I think the same with Drupal.</p>
  
  <p>Because you will have the same problem when Devs delete fields and play on the live system, the content is missing or the frontend error generated.</p>
  
  <p>Therefore, it is simply forbidden to simply delete fields, they do the same nevertheless is not the CMS to blame, then that is Human Failure.</p>
  
  <p>If you are familiar with the principle of the ContentBuilders (no static backend masks), then you would not get far with field configurations with YAML or JSON, then the editor determines which fields he needs for each article individually.</p>
  
  <p>I'm not sure if it's so much performance gain when you put the fields into the filesystem, because Craft has to double into the filesystem for the representation of a field in the backend (general fieldstyle, the field configuration) and then into the database To pick up the content.</p>
  
  <p>Craft 2 is fast, Craft 3 is even faster. Anyone who builds fixed fields does not have to worry about the backend performance.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-26T09:51:03.197Z
Answers.LastActivityDate: 2017-02-26T09:51:03.197Z
Answers.UserDisplayName: gisu
Body: <p>Clearly Craft CMS is not a thing for non-developers (like WordPress or Drupal is). Despite the option to create fields, sections, etc. in the administration panel, we still need to code templates (twig, html, CSS, etc.). So for me it's kind of a weird relationship where we define those things in administration with ease and luxury (no programming at all), and then still need to code standard way upon it in templates.</p>
  
  <p>In my opinion, this relationship creates a bunch of issues: </p>
  
  <p>1) Let's say we work in team and some other dev decides to remove some fields (or change handle names), because he/she does not know my part in templates. The page is screwed! And it's hard to rollback, because, well it's database.</p>
  
  <p>2) Content replication problem! Thanks god there is something upcoming in this area <a href="https://craftcms.com/news/craft-3-content-migrations" rel="nofollow noreferrer">https://craftcms.com/news/craft-3-content-migrations</a>, but still this is fishy - read on.</p>
  
  <p>3) Request to DB are made for content definitions, that mostly stay the same all the time. No need for that.</p>
  
  <p>The solution I see, in my opinion, is very simple. </p>
  
  <p>Let programmers to define fields, sections, globals, etc. (most of the settings contents) programmatically. If we know how to code with Twig, it shouldn't be so hard to edit some Yaml or PHP array. There is nothing to lose! </p>
  
  <p>After that:</p>
  
  <p>1) No request to DB for code defined stuff. Huge performance gain.</p>
  
  <p>2) There is no content replication problem for programmatically defined settings. It is just delivered via version control!</p>
  
  <p>3) We can create unit tests, do code reviews, etc. for those content parts. Even extend to more functionality ... and always refer to version control (revert/analyze bad changes etc.).</p>
  
  <p>Am I talking bananas? 
  BR, J</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-02-24T18:33:07.047Z
Comments.Text: What is the question? This feels much more like a rant than an actual question.
Comments.UserDisplayName: Lindsey D
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-02-28T21:34:29.920Z
Comments.Text: Closing this as a feature request, as there's no discernible question here.
Comments.UserDisplayName: Lindsey D
Tags: <field><migration>
Title: Problems with Craft CMS development strategy
ThreadText: # Problems with Craft CMS development strategy
  
  (Asked by: username_0 on 2017-02-24)
  
  Clearly Craft CMS is not a thing for non-developers (like WordPress or Drupal is). Despite the option to create fields, sections, etc. in the administration panel, we still need to code templates (twig, html, CSS, etc.). So for me it's kind of a weird relationship where we define those things in administration with ease and luxury (no programming at all), and then still need to code standard way upon it in templates.
  
  In my opinion, this relationship creates a bunch of issues:
  
  1) Let's say we work in team and some other dev decides to remove some fields (or change handle names), because he/she does not know my part in templates. The page is screwed! And it's hard to rollback, because, well it's database.
  
  2) Content replication problem! Thanks god there is something upcoming in this area <https://craftcms.com/news/craft-3-content-migrations>, but still this is fishy - read on.
  
  3) Request to DB are made for content definitions, that mostly stay the same all the time. No need for that.
  
  The solution I see, in my opinion, is very simple.
  
  Let programmers to define fields, sections, globals, etc. (most of the settings contents) programmatically. If we know how to code with Twig, it shouldn't be so hard to edit some Yaml or PHP array. There is nothing to lose!
  
  After that:
  
  1) No request to DB for code defined stuff. Huge performance gain.
  
  2) There is no content replication problem for programmatically defined settings. It is just delivered via version control!
  
  3) We can create unit tests, do code reviews, etc. for those content parts. Even extend to more functionality ... and always refer to version control (revert/analyze bad changes etc.).
  
  Am I talking bananas?
  BR, J
  
  **Tags:** field, migration
  
  > **Comments:**
  > **username_1**: What is the question? This feels much more like a rant than an actual question.  
  > **username_1**: Closing this as a feature request, as there's no discernible question here.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_4 on 2017-02-26. Score: 1
  
  I do not know where your problem is? In Wordpress, you can build pages with CustomFields, and I think the same with Drupal.
  
  Because you will have the same problem when Devs delete fields and play on the live system, the content is missing or the frontend error generated.
  
  Therefore, it is simply forbidden to simply delete fields, they do the same nevertheless is not the CMS to blame, then that is Human Failure.
  
  If you are familiar with the principle of the ContentBuilders (no static backend masks), then you would not get far with field configurations with YAML or JSON, then the editor determines which fields he needs for each article individually.
  
  I'm not sure if it's so much performance gain when you put the fields into the filesystem, because Craft has to double into the filesystem for the representation of a field in the backend (general fieldstyle, the field configuration) and then into the database To pick up the content.
  
  Craft 2 is fast, Craft 3 is even faster. Anyone who builds fixed fields does not have to worry about the backend performance.
  
  
  ---
  
  ### Answer by username_2 on 2017-02-24. Score: 0
  
  You might have more luck over at the [Craft GitHub Issues](https://github.com/craftcms/cms/issues) site. Generally it's the place to go if you've got suggestions / feedback. This Stack Exchange site is used more for specific questions that need answers.
  
  UPDATED: Added link to the GitHub Issues site as per username_3's comment below.
  
  > **Comments:**
  > **username_0**: Agree! Did that.  
  > **username_3**: FFR we’re transitioning to [GitHub issues](https://github.com/craftcms/cms/issues) for feedback and bug reports ;)  
  
  ---
  
  