Input format selection broken on node edit form

I absolutely love this ..
+10

For the uninformed, Alex did some great work on the formproc module (alexreisner.com/drupal/modules/formproc), which
was developed for Drupal completely separately from the Forms API (lack of communication, d'oh).

Alex has tons of experience in writing form processing code, and I convinced him to try and get as many of his features for formproc in
before the 4.7 release.

This is a clear boon to the API, making it more readable, and lessening the amount of properties we need.

This mechanism could also be used for menu arguments.

Could you port the other callbacks too (specifically execute and process/ after_build).

As happened with hook_node_info so should happen with these: we allow only array('functionname' => array(arg1, arg2, arg3)) syntax. Note that this adds #process_arguments functionaility, makes form.inc execute less code and makes form.inc shorter.

I'm not fond of standardising on one format, as having an => array() always hanging around when a vast vast minority of callbacks ever use parameters (but enough to not just drop the arguments entirely). This reminds me of all the null, null, null, $variable stuff in the old form api.

In those normal cases, though, the array() is a default and the user doesn't need to set it. Transparent from the perspective of someone making a simple form. Am I misunderstanding the code?

If it's simple, all is dandy. Look at filter_form, there you see what Adrian's problem is. However, I think consistency and speed worths an extra => on _very_ rare occasions.

I meant: an extra => array()on _very_ rare occasions.

Here is the discussion that lead to hook_node_info as of now:

[Sat Aug 27 2005] [19:06:15] <chx> but... do you want to always write return array('name' => t('something'), 'type' => 'example_module', 'base' => 'example_module'); instead of return t('something') ???
[Sat Aug 27 2005] [19:06:53] <Dries_> chx: yes, i always want to write that
[Sat Aug 27 2005] [19:07:09] <Dries_> chx: maybe a dozen people have to write that
once :)

And here is the sentence that lead to this patch:

[Mon Nov 28 2005] [17:46:27] <Dries_> chx: programmers have to write less, but in the mean time, we have to write more code, and every single page request (thousand of these per second) have to execute your is_array() checks :P

Same train of thought IMO.

Reroll to keep up with head

Ok, tested this patch:

Create account/login: both are working fine
Node submit: tried both a page (basic) and a poll (more advanced), and both are working fine.
Checkboxes/Radios: Futzed with the themes in admin/theme and settings saved fine.
Date element: this did NOT work, but a clean HEAD does the same thing: I entered a profile field of "birthdate" and put in a date (Apr 7, 1987 -- and no that's not my birthdate :P) and it got reset to "01/01/1".

So overall, it doesn't seem to break anything that wasn't already broken, and does create consistency among the various form-related things. +1.

Committed. Thanks.

This patch backed out part of Patch #39605 and filters no longer work.

Here's a patch that fixes it.

Also fixed in http://drupal.org/node/39778

Before I applied this patch, the 'input formats' fieldset on the node add/edit form shows up empty. After applying it, the fieldset shows up with all options displaying, and when the node is saved, the filtering system functions correctly depending on the selected format, and the selected format is remembered and re-populated on editing.

So in short.. this 1-line patch is ready for core, and should go in ASAP.

I committed 39778. This is fixed now? Please mark this issue 'fixed' after testing. Thanks.

Yes, this has been fixed.