3.1.0 DP 5 Field Type Errors

Interesting, looks like it might be having trouble instantiating the field type class. If you look in your exp_channel_fields table, does that field have the right value for its field_type column? Should be whatever you name the add-on file, ft.x.php. And is this name different than the other files in your package? Like, does your add-on have multiple fieldtypes in it?

Also, if we could have a full stack trace for one of those errors, that might help us, too.

The field types in the database are correct. My add-on has two field types which I am declaring in addon.setup per the new docs:

'fieldtypes' => array(
 'construct' => array(
  'name' => 'Construct',
  'compatibility' => 'construct'
 ),
 'construct_node_chooser' => array(
  'name' => 'Construct Node Chooser',
  'compatibility' => 'construct_node_chooser'
 )
)

I’m still playing with the compatibility thing. I don’t know what that does and does not do. They aren’t really compatible with anything else so I set them to the name of the field-type. I also tried various values listed in the docs to see if that was causing a problem, no dice.

The top field type has been in the add-on since the EE 2.x days and has the same name as the add-on package. The other field-type is new. But the error is happening with both of them.

There is no strack trace, only E_WARNING, E_NOTICE, E_RECOVERABLE_ERROR etc.

I did one additional test, I removed my new field type, removed the fieldtypes from the add-on.setup, and put everything back the way it was when the field type was working on previous developer previews. It still throws the error when trying to edit the field and shows only a text input field on the publish page — not loading the display_field method at all. I had finished the main field type with DP 4 (I think it was) and it was working then.

Change your save_settings() method to something like this and save the field:

public function save_settings($data)
{
    // Make the field take up the full width of the publish page
    return array('field_wide' => TRUE);
}

Should fix it. No need to send back the entire $data array, it’s basically just POST and there so it’s easy to pluck things out of. That way you’re also not storing the entire contents of POST into your field_settings column, too.

Okay, that’s interesting. Out of curiosity, why would it have worked initially then stopped working?

Not sure exactly what changed, but a series of array merges was causing the field_id to be overwritten by the empty one stored in your field settings column. I think we’re going to build in some protection for that.