Make text field use D7 '#text_format' selector

A change from a different patch sneaked in the previous one.

re #4: those comments are not relevant to this specific patch. Widgets implemented as specific form 'elements', potentially reusable in non-CCK forms, was done in CCK D6. I'm not sure I remember all the reasons off-hand, and returning to a more classic FAPI implementation might possibly be discussed. But this should happen in a separate thread and definitely not hold on this patch, which just makes the current code inline with the new D7 construct for input formats.

Anyone ? This is simple and straightforward, no real reason to have this languish, AFAICT...

Sure, why not - but we could as well commit it as is, just needs someone to mark it RTBC ;-)

Will reroll shortly for the remarks above.

@sun #10
(count($element['#columns']) == 2) ? $element['#columns'][1] : 'format';
"braces should wrap the entire statement, not just the condition. "

Sounds odd, and I cannot find where is this stated. Do you have a link or something ?

Updated patch :
- Adressed comments above (except sun's remark about braces around conditionl expressions, which I can't see applied in the rest of core)
- Better code comments about why text_field_widget_validate() is needed. I also tried to use a #value_callback instead of a form_set_values() in validate, but it turns out to be impossible because of form processing order.
- Fixed the bug mentioned in http://drupal.org/node/372743#comment-1388568.
Relies on a needed fix for filter_form() - patch in #411596: filter format form when only 1 format available.

Since all concerns raised since the last RTBC are adressed, setting back to RTBC

I don't agree. I strongly suggest we commit this now and revisit when that other issue - not yet created - lands...
The code in this patch is correct and harmless. It *could* be better if the feature it reiies on was more flexible, but pretty please let's not block #372743: Body and teaser as fields and other important followups (#409750: Overhaul and extend node build modes...).

I feel this is taking a somewhat dramatic turn... The fields code still has a number of TODOs, which are slowly being striked out. We can add a TODO note to revisit this when a patch for form_process_text_format() lands (I created #412016: Custom key name for #text_format. for this). I suspect this might take some discussion and a few iterations.
Again, there's a patch congestion around fields API, let's not add to this by postponing over details on other APIs.

Rerolled.

#process uses $edit. $edit doesn't contain values for '#type = value' elements. filter_form() currently uses a 'value' when only one format is available.
That's why #value_callback didn't work, btw.

Sun tells me that the latest patch in #304330: Text format widget removes the use of 'value', though.

Updated patch. The changes that went in #304330: Text format widget now let us do the job in a #value_callback instead of a form_set_value() in #element_validate.
Also contains the fix for #423308: Textarea widget broken (missing return in text_textarea_process()) and comes with tests for both widgets.

"Failed to install HEAD" - works fine on my setup, requiering retest.

Rerolled after http://drupal.org/node/323112

The params and PHPdoc for text_field_widget_formatted_text_value() are directly taken from form.inc's value callbacks :

/**
 * Helper function to determine the value for a checkbox form element.
 *
 * @param $form
 *   The form element whose value is being populated.
 * @param $edit
 *   The incoming POST data to populate the form element. If this is FALSE,
 *   the element's default value should be returned.
 * @return
 *   The data that will appear in the $form_state['values'] collection
 *   for this element. Return nothing to use the default.
 */
function form_type_checkbox_value($form, $edit = FALSE) {
  ...
}

I will reroll for the remark about ''[column 1]", but for the rest, I'd suggest committing the current, and fixing the existing core value callbacks consistently if it considered necessary ?

Rerolled for the '[column 0]' / '[column 1]' PHPdoc bit sun mentioned in #32.
The other remarks should go in a 'document #value_callback / fix signature of existing core implementations' issue, IMO. Created #447930: #value_callback documentation and signature (D7) for this.

Oops. Thks sun.

Rerolled.

I missed comment #38 somehow. Dries : This has been discussed before. text_field_widget_formatted_text_value() is not a hack, it's translating form values structure into storage structure. As Damien wrote in #24, there's no reason to expect or enforce that both structures match, and a value_callback is a valid way to do that. Somewhere else in core, you'd do that in a _submit handler, field widgets cant use that and rely on FAPI callbacks.

#414424: Introduce Form API #type 'text_format' is still highly hypothetical, and it's been pointed several times that making all core formatted textareas consistently use the current official D7 construct (#text_format) will make enriching / moving away from it easier.

I'm a little puzzled at how complex it is to get this fairly simple patch in :-/

Doh... Here's the patch.

Let's hold this. While working on the last test failures in #372743: Body and teaser as fields I noticed a few hiccups when the user only has access to one input format - raises notices on preview. Investigating.

Will teach me to rant about patches that take too long to get in, I guess :-(

So the issue was that when the current user only has access to one format, the format selector is hidden with '#access' = FALSE, and FAPI then doesn't make the format value available in our #value_callback. Saved format was then 0, while node body, for example, receives the actual format (which is necessarily the current default format) in its submit handler.
Storing 0 is no good because, although *at display time* it gets interpreted as 'the default format', it might be a different format than when the node was edited.
This also caused notices on preview.

Attached patch fixes this by explicitly saving the default format if no format value is available.
I'm aware it's not helping Dries to not consider text_field_widget_formatted_text_value() as a hack :-(.
The only alternate solution I see in a foreseeable future is #412016: Custom key name for #text_format..

This got committed along with #372743: Body and teaser as fields