Custom Fieldtype Data
Development and Programming
I’m writing a fieldtype and I need for it to have some custom field options. It is my opinion that exp_channel_fields should have an additional field called ‘field_options’ so developers can store a their options with the field. Storing the options in a separate table doesn’t really make sense to me, being that nearly all custom fields will have some custom field options.
function display_settings($data)
{
// If the 'field_options' column does not exist, add it to hold the field options
if (!$this->EE->db->field_exists('field_options', 'channel_fields'))
{
// Load the dbforge class
$this->EE->load->dbforge();
// Create the field
$fields = array(
'field_options' => array('type' => 'TEXT')
);
// Add the column to the table
$this->EE->dbforge->add_column('channel_fields', $fields);
}
// Check if the User ID has been previously entered
$field_options = ($data['field_options'] == '') ? '' : $data['field_options'];
// Load in the langauge file
$this->EE->lang->loadfile('vimeeo');
// Input for User ID
$this->EE->table->add_row(
lang($this->EE->lang->line('ft_vimeo_user_id')),
form_input(array('id'=>'field_options','name'=>'field_options', 'size'=>8,'value'=>$field_options))
);
}The code above works, but I am wanting storing a serialized array of multiple form inputs in my ‘field_options’ column. I was assuming that I could capture the post data of the the fields and serialize an array in the save_settings function, but apparently the data is stored to the database before the save_settings function is called.
So here are my questions: 1) Would my method of creating the field_options column in the exp_channel_fields database be considered a best practice? If not, what should I be doing?
2) How can I intercept the post data before it is saved to the database?
Thanks!
Anyone? Anyone? Anyone?
Question #2 was answered with a bugfix in the newest build.
However, I’m still in the dark about where I should be saving my field options. I wish a mod would speak up.
Here here. Why should EE-native fields get all the settings (each with its own distinct field even)? If the Custom Field API is going to replace FieldFrame, settings are a must. As it stands, this is broken for me.
Here here. Why should EE-native fields get all the settings (each with its own distinct field even)? If the Custom Field API is going to replace FieldFrame, settings are a must. As it stands, this is broken for me.
Check out the readme for NSM TinyMCE. I figured out how to enable per field settings. You can use my code as an example of how to save / read them as well. It’s all really well commented.
Thanks Leevi, just checked it out, very nice. I’ll probably wait it out until official supported methods are out on this one, and focus time on extensions I can port hack-free for the moment.
I really hope they have some official supported methods on this soon. I would hate for their to be an influx of different fieldtypes with different ways to save the fieldtype options. It would be a hot mess.
I’m going to go ahead and report this thread to the bug tracker. Hopefully we can get some answers.