0

(This is for D8, although parts of this filter settings API were already in D7.)

As far as I understand, a filter plugin exposes its settings solely with FilterBase::settingsForm() - the central architecture then automatically stores the submitted form values and loads them when creating the plugin instance, so that a filter plugin can find them in $this->settings.

I'd like to reorganize and clean up the submitted form values before they're stored, but I'm not sure where to intercept the form. Should I attach a #validate or a #submit? If the latter, how do I ensure that my #submit runs before FilterFormatInterface::submitForm()?

2 Answers 2

0

It looks like your only options right now are relying on generic form API features, like #process and #value_callback. FilterFormatFormBase doesn't call into the plugins for validate/submit, like we do for example for block plugins.

2
  • Thanks, #value_callback seems like a fairly good choice. Commented Apr 15, 2015 at 13:50
  • Wait, no, #value_callback doesn't work. It only seems to get called for individual fields, not fieldsets - I can't use it to aggregate and reorganize those settings. Commented Apr 15, 2015 at 19:00
0

My new approach reverses the situation. Apparently I can't alter the structure of the values after the form is built - but I can change how the form is presented.

So instead of building the form in the user-friendly structure A and then failing to convert the values to developer-friendly structure B, I'll build a form as B and use a #theme hook to render it as A.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.