Here's how to reproduce the problem:
1- Create a new role, let's call it "editor";
2- Set your site's default input format to format "A";
3- Set the default input format for the role "editor" to format "B";
4- In the user permission menu, disable the "show format selection" permission for the role "editor";
5- Log in as "editor";
6- Create a new node containing a text area. Enter some text in the text area.
----> See: the input format is B. So far so good.
7- Press "save" to create the new node;
8- Edit the new node using the "Edit" tab. Add some text in the text area.
----> See: the input format is still B. Good.
9- Press "save" to save your modifications;
10- Edit the node again, by clicking again on the "edit" tab;
-----> Problem: the input format of the text area is no longer B. It is now the site's default, A.
Workaround: enable the user permission "show format selection".
Code discussion:
Somehow, in function better_formats_textarea_process(), the $format variable receives the value "0", whereas it should be the id of the format B ("1", or something like that). Because the node is not new, the $format variable is not overwritten by the value of $default, and the input format goes back to the site's default format.
I don't have any patch for now. I'll let you know if I find something.
Thanks,
jf
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | better_formats-DRUPAL-6--1.format_save_on_insert_update.patch | 1.38 KB | dragonwize |
| #1 | better_formats-DRUPAL-6--1.format_save_on_insert_update.patch | 1.27 KB | dragonwize |
Comments
Comment #1
dragonwize commentedI have confirmed this.
I worked on this issue for a few hours and it still has me slightly confused as my debugging doesn't support the solution.
During debugging I notice another issue. If you leave a CCK textarea blank then CCK only saves default values into the DB. In this case the default field value is NULL which is not a valid format and because the content is no longer new but instead existing it would automatically get the site default.
So to fix that I checked if the current value was not set and if so gave it the proper BF default to fix that issue. Surprisingly, it seems to have fixed this issue as well. I say seems because brief testing has shown it to be fixed but the fix doesn't fit my finding during debugging.
I plan to give this more testing before committing. It would be great if you could put it through some testing as well and report back.
Thanks for finding this.
Comment #2
dragonwize commentedJust as I thought. That patch doesn't fix this issue completely. It only fixes it if the BF default is the same as the selected format. If the default format is changed then the node is save again, it is then saved with the current default instead of the selected format.
Comment #3
dragonwize commentedOk, I've got another patch that seems to be working now in all my tests and fits the debug data as well. Please give this one a round of testing. If all is good I will commit this patch.
Comment #4
dragonwize commentedCommitting this critical patch.
Comment #5
jfduchesneau commentedThanks a lot for the patch! I'll give it a try as soon as possible.
thanks,
jf