[development] Slight API change in 4.6.10 and 4.7.4
dpal_gaf_devel at marsdome.com
Thu Oct 19 20:27:10 UTC 2006
Heine Deelstra wrote:
> The 4.6.10 and 4.7.4 releases saw the addition of a new default form
> field to protect against cross site request forgeries.
> This has consequences for
> 1. 4.6 modules and themes that output raw HTML forms
> Those forms will always fail for authenticated users.
> 2. 4.7 modules and themes that rely on a defined set of form fields to
> be present
> Certain modules and themes output only specific form fields. As they
> do not output the form_token, the form will always fail validation for
> authenticated users.
Perhaps the subtleties of English are getting in the way, but all
modules and themes output only specific form fields; every field in an
HTML form is a specific field. At first, I couldn't make any sense out
of this, and so went to the web site, where the explanation was the same
but the examples shed some light.
I think that what you're saying is that some modules and themes output
an explicit subset of form fields from a $form. Or maybe more
precisely, judging from the followup note by Rob Barreca, some modules
and themes call form_render on an explicit subset of fields in a given
$form, and never call form_render($form) to render the rest of the form.
Is that correct? If so, does that complete characterize the problem, or
are there other ways to trigger the incompatibility in 4.7.*, excluding
totally unreasonable, contrived examples.
> In addition, certain modules unset a few form fields, then save the
> remainder of the form. These modules need to account for the new
> field. Tip: devise something robust.
> See for details:
> Converting 4.6.9 modules to 4.6.10 <http://drupal.org/node/90004>
> Converting 4.7.3 modules to 4.7.4 <http://drupal.org/node/89999>
> Converting 4.6.x themes to 4.6.10 <http://drupal.org/node/90021>
> Converting 4.7.x themes to 4.7.4 <http://drupal.org/node/90024>
> Kind regards,
> Heine Deelstra
More information about the development