Drupal 7 version of Webform not updated for text format changes

Thanks David. I'm lost on a few of these changes. Why do you have change like this in the patch?

-    'confirmation_format' => filter_default_format(),
+    'confirmation_format' => NULL,

And then later do checking like this (which seems entirely unnecessary):

-    '#format' => $node->webform['confirmation_format'],
+    '#format' => isset($node->webform['confirmation_format']) ? $node->webform['confirmation_format'] : NULL,

Setting a default filter value that matches the user's default format seems like it's correct. After this patch the default format is NULL, until the user visits node/x/webform/settings and saves, then it will be set to whatever their default is unless they change it manually.

Also, you might have a programmatic node_save(); in that case you don't want to store the default format of whichever user triggered the node_save(), because that might be completely wrong.

If you're doing a programmatic node_save(), you should set the $node->webform['confirmation_format'] directly anyway. If you haven't set any webform properties or the $node->webform['confirmation'] field, then it doesn't even matter at all what the confirmation format is because there's not even a message at all.

All nodes should have a confirmation format no matter what. The idea that you'd have "NULL" confirmation format very confusing. Does that really mean "plain text" if the format is NULL and there's a confirmation message? It's much more clear to just have one set all the time.

If you wind up with content in the confirmation message but the format still NULL, that would be a bug in whatever code caused that to happen.

I don't see how you're arguing that NULL should be the default for node_save(), yet not specifying one would be a bug. If you're using node_save() (as administrator) you can just set $node->webform['confirmation_format'] to whatever you want. If you were an administrator creating a node through the interface, obviously the administrator's default would be used at the default in that situation also.

My point here is that all nodes have a format set at all times for the body field and all other fields, it shouldn't be any different with Webform.

After reviewing the D7 changes I have to agree you're right. It's just a little weird to me that confirmation_format stays NULL until the user goes to edit the node. It does make sense... but it's just a bit different in thinking. So anyway that all looks fine to me. Let's just get the unnecessary isset() check out and everything else looks fine.

I ran this patch against the 7.x 3.6 version.

- the update numbers (7306 and 7307 need to be increased, as 7306 is already in use now.)
- after changing them, the update ran successful
- I tested the "form settings" form (node/%nid/webform/configure)
- before: the text format for the "Confirmation message" would not be saved (trying to store a text in a tiny int)
- after running the patch and update, the text format for the "Confirmation message" is saved and used as expected

So for me this patch worked fine, as far as running into the issue of that text format not being saved,

I tested this patch and it did solve the text format change not being saved problem, and also the problem reported at http://drupal.org/node/1011668 as well. Thanks for the patch!

Thanks much -- the patch also worked for me. Reminder to future visitors: You'll need to run update.php after installing the patch, since a big part of the patch is a database update.

Thanks David, committed!

Hmm, using webform 3.6 on D7.
After this patch I get this:
PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: 'plain_text' for column 'confirmation_format' at row 1: UPDATE {webform} SET confirmation=:db_update_placeholder_0, confirmation_format=:db_update_placeholder_1, redirect_url=:db_update_placeholder_2, status=:db_update_placeholder_3, block=:db_update_placeholder_4, teaser=:db_update_placeholder_5, allow_draft=:db_update_placeholder_6, submit_notice=:db_update_placeholder_7, submit_text=:db_update_placeholder_8, submit_limit=:db_update_placeholder_9, submit_interval=:db_update_placeholder_10 WHERE (nid = :db_condition_placeholder_0) ; Array ( [:db_update_placeholder_0] => Bedankt [:db_update_placeholder_1] => plain_text [:db_update_placeholder_2] => <confirmation> [:db_update_placeholder_3] => 1 [:db_update_placeholder_4] => 0 [:db_update_placeholder_5] => 0 [:db_update_placeholder_6] => 0 [:db_update_placeholder_7] => 0 [:db_update_placeholder_8] => Verstuur je aanvraag [:db_update_placeholder_9] => -1 [:db_update_placeholder_10] => -1 [:db_condition_placeholder_0] => 4 ) in drupal_write_record() (line 6776 of /includes/common.inc).

I take it back... I was looking with the wrong set of eyes or something... :S
Was still running 3.4-beta.

Sorry for the inconveniance.

This change isn't yet in 3.6 yet anyway, it'll be in 3.7.

Sorry to hog a fixed issue, but this is badly needed, so any ideas when can we expect a new release? Or maybe publish a dev release?

I am having the issue described by this ticket and I tried to apply the patch provided in #10 using Patch.exe, but it is failing. I tried to get help in the forum after reading the manual on patching but was only referred back to the manual. I am not familiar with patching at all. In the form settings, I try to save the conf message as full HTML and set the advanced option to show the form in a teaser and get error: Notice: Undefined index: 0 in ckeditor_profiles_compile() (line 424 of C:\wamp\www\JustRightBiking\sites\all\modules\ckeditor\includes\ckeditor.lib.inc).

I don't know if this is a windows7 (64 bit) issue. Can you point me to a good patching tool or just a patched module folder?

Sorry to hog a fixed issue, but this is badly needed, so any ideas when can we expect a new release? Or maybe publish a dev release?

You can always get the dev release by clicking "View all releases". I'll be making a new official release in the next week or so.

While Updating webform module to 7.x-3.11 get this error again in update 7307:

PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: 'plain_text' for column 'confirmation_format' at row 1: ALTER TABLE {webform} CHANGE `confirmation_format` `confirmation_format` INT unsigned NULL DEFAULT NULL COMMENT 'The filter_format.format of the confirmation message.'; Array ( )

Issue still there in Version 7.x-3.11.

Here is the solution:

File: webform.install

/**
 * Update the confirmation_format column for default text format changes.
 */
function webform_update_7307() {
  // These changes are modeled after user_update_7010().
  db_change_field('webform', 'confirmation_format', 'confirmation_format', array(
    'description' => 'The {filter_format}.format of the confirmation message.',
    'type' => 'int',
    'unsigned' => TRUE,
    'not null' => FALSE,
  ));

Should be:

/**
 * Update the confirmation_format column for default text format changes.
 */
function webform_update_7307() {
  // These changes are modeled after user_update_7010().
  db_change_field('webform', 'confirmation_format', 'confirmation_format', array(
    'description' => 'The {filter_format}.format of the confirmation message.',
    'type' => 'varchar',
    'length' => 255,
    'not null' => FALSE,
  ));

Thanks sweo, this problem arises when you update from Drupal 6 to 7, add a new text format (or rename an existing one), then upgrade Webform later. If upgrading Webform immediately after upgrading Drupal core, this problem shouldn't occur.

In any case, still an important thing to fix.

the same trouble for updating from 3.8 to 3.11

root@ns2:/home/***/public_html# drush updatedb
The following updates are pending:

webform module : 
  7307 -   Update the confirmation_format column for default text format changes. 
  7308 -   Update the confirmation_format column to allow it to store strings. 
  7309 -   Add the ability to auto-save as draft between pages. 
  7310 -   Remove orphaned and unnecessary rows in the webform table. 
  7311 -   Add an index for sid_nid_uid to webform_submissions. 

Do you wish to run all pending updates? (y/n): y
SQLSTATE[HY000]: General error: 1366 Incorrect integer value: 'full_html' for column 'confirmation_format'  [error]
at row 1
Finished performing updates. 

removing 7307 update fix update path
so error is in 7307

Although it doesn't seem like this has affected too many users (there are only about 300 sites reporting using a version prior to 3.9 even now), this patch should fix the problem by taking the recommendation of David in #24. Since webform_update_7301() isn't needed in D6->D7 upgrades any more, we can move webform_update_7307() directly into its place since it effectively replaces the need for that change anyway. Then users upgrading from versions prior to 3.9 can upgrade to the latest release without webform_update_7307() throwing errors.

Maybe I'm completely missing something here, but whatever I do, field descriptions seem to be filtered through filtered_html.

On admin/config/content/formats Full html is listed first & I gather that makes it the default. I've also set filter_fallback_format to full_html which makes it the fallback filter format.

From the component field settings page:

As rendered:

All but the <strong> tag is filtered out.

David, thanks for the tip. I knew that already, I was just trying things out. It's already reset to default.

And on your other point, I've achieved what I needed to do using markup components.

Thanks.