Custom Field Settings

Okay, update on the situation. It wasn’t working because save_settings() was never being called on an insert, only an edit. I added the following three lines on line 4577 of cp/admin_content.php:

$this->api_channel_fields->fetch_all_fieldtypes();
$this->api_channel_fields->setup_handler($_POST['field_type']);
$this->api_channel_fields->apply('save_settings', $_POST);

And now I can unset the $_POST variables manually. The next step to find is how I get the settings to persist…

Whoop, that would indeed cause problems.

Mind dropping this one into the bug tracker? We’ll get it all straightened out.

Something seems to be off with the bug tracker - I can only see the guidelines and can’t actually get to the submit form.

The save_settings issue should be fixed in this latest build.

And I believe Derek fixed up the bug tracker for you (your member group, didn’t have saef access).

The next step to find is how I get the settings to persist…

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.

Hehe, very good Leevi 😉 .

Yes, that column (and a few other tweaks) will go in when we have enough meat to justify a proper upgrade (can’t modify the db in build updates).

Any chance of publishing some quick docs on how to add the custom field custom settings in this thread? Or did I cover it all.

Sure thing - although you pretty much have it all covered. In fact, you added a step that isn’t strictly necessary. The native array doesn’t need to be altered, since that key should never come in through POST.

1. Uncomment line 4470 (line number depends on your build - reads “base64_encode(serialize($ft_settings))” 2. In save_settings return an associative array. - Returning one of the native keys overrides - Your own keys are added to the serialized array - Everything you return is available on publish via $this->settings, but not on the frontend.

That’s pretty much it. Make sure you do your own data prepping, cleaning, etc. And remember that the EE superobject points to the current controller instance, so you can access _get_ft_post_data, which is helpful if you’re prefixing your fields.

Oh and don’t build your own workarounds for global fieldtype settings (ala field frame) just yet … cough cough.

Thanks Pascal,

One more quick question. Will the settings eventually be available on the font end? I’m sure this would come in handy but at the moment I can’t think of a use case.

Another quick question observation.

You say that:

• Returning one of the native keys overrides

Can you explain this?

- Returning one of the native keys overrides

Should’ve read “…overrides the native column”. So for example if you have a piece of information that makes sense as a content type - return it as field_content_type. That saves PHP a bit of work, and also makes it available on the frontend.

Will the settings eventually be available on the font end?

We’re not opposed to the idea and global settings might add a new perspective, but finding a genuine need for it has been difficult.

It would have to be something that can’t be added/modified when the field is saved and something that isn’t entirely appropriate as a tag parameter.

The rule of thumb we’ve followed for our own fields is that the tag alone outputs the data in as simple a format as possible and the developer can use tag parameters or tag pairs to modify the data to their needs.