Answers.Body: <p>The Field Types <code>defineSettings</code> method defines the settings that get handled when you create the field. Those field settings get stored as <code>json</code> in the <code>craft_fields.settings</code> column when the field is created.</p>
  
  <p>The <code>BaseFieldType</code> class has another method you can add to your class called <code>defineContentAttribute</code>. In your case, getting the column to be the data type you want would look like:</p>
  
  <pre><code>public function defineContentAttribute()
  {
      return [
          AttributeType::String,
          'column'  =&gt;  ColumnType::LongText
      ];
  }
  </code></pre>
  
  <p>The <code>PlainTextFieldType</code> and <code>RichTextFieldType</code> classes have similar use cases which modify the default <code>defineContentAttribute</code> value if you want to take a look at a few more examples.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-09-27T20:26:36.200Z
Answers.Text: This was exactly what I had overlooked. Implementing this resolved my problem. Thank you.
Answers.UserDisplayName: Sonja Leaf
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-09-27T20:23:41.383Z
Answers.LastActivityDate: 2016-09-27T20:23:41.383Z
Answers.UserDisplayName: Ben Parizek
Body: <p>I’m working on a plugin that includes a custom fieldtype. Using Craft 2.6.2911, the fieldtype’s <code>defineSettings</code> looks like this:</p>
  
  <pre><code>public function defineSettings ( ) {
      return [
          'json_data'  =&gt;  [
              AttributeType::String,
              'column'  =&gt;  ColumnType::LongText
          ]
      ];
  }
  </code></pre>
  
  <p>When I add this field to a tab group, the new column is added to the <code>craft_content</code> table as a <code>varchar(255)</code>, not a <code>text</code>-type column.  Is there an additional definition I need somewhere?</p>
  
  <p>I did not see a relevant note in the changelog for builds of Craft between 2.6.2911 and 2.6.2944.</p>
  
  <p>When reviewing my database schema, I'm seeing the following: </p>
  
  <pre><code>| field_jsonSync             | varchar(255)           | YES  |     | NULL    |                |
  </code></pre>
  
Tags: <plugin-development><fieldtypes><custom-fieldtype>
Title: Plugin fieldtype settings for ColumnType::LongText being inserted as varchar(255)
ThreadText: # Plugin fieldtype settings for ColumnType::LongText being inserted as varchar(255)
  
  (Asked by: username_0 on 2016-09-27)
  
  I’m working on a plugin that includes a custom fieldtype. Using Craft 2.6.2911, the fieldtype’s `defineSettings` looks like this:
  
  ```
  public function defineSettings ( ) {
      return [
          'json_data'  =>  [
              AttributeType::String,
              'column'  =>  ColumnType::LongText
          ]
      ];
  }
  
  ```
  
  When I add this field to a tab group, the new column is added to the `craft_content` table as a `varchar(255)`, not a `text`-type column. Is there an additional definition I need somewhere?
  
  I did not see a relevant note in the changelog for builds of Craft between 2.6.2911 and 2.6.2944.
  
  When reviewing my database schema, I'm seeing the following:
  
  ```
  | field_jsonSync             | varchar(255)           | YES  |     | NULL    |                |
  
  ```
  
  **Tags:** plugin-development, fieldtypes, custom-fieldtype
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2016-09-27. Score: 3 | Accepted answer
  
  The Field Types `defineSettings` method defines the settings that get handled when you create the field. Those field settings get stored as `json` in the `craft_fields.settings` column when the field is created.
  
  The `BaseFieldType` class has another method you can add to your class called `defineContentAttribute`. In your case, getting the column to be the data type you want would look like:
  
  ```
  public function defineContentAttribute()
  {
      return [
          AttributeType::String,
          'column'  =>  ColumnType::LongText
      ];
  }
  
  ```
  
  The `PlainTextFieldType` and `RichTextFieldType` classes have similar use cases which modify the default `defineContentAttribute` value if you want to take a look at a few more examples.
  
  > **Comments:**
  > **username_0**: This was exactly what I had overlooked. Implementing this resolved my problem. Thank you.  
  
  ---
  
  