Can't disable / enable whizzywig on certain form ids
westwesterson - September 28, 2007 - 22:10
| Project: | Whizzywig |
| Version: | 5.x-1.1 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | sdecabooter |
| Status: | closed |
Description
I can't get the whizzywig module to disable on certain form id's despite typing the ids into the disable box, and selecting Disable on these form elements.
This is critical when editing email text areas, HTML code is just not acceptable in an email without HTML support.
#1
Hi,
I cannot reproduce this behaviour.
I tried disabling the editor for the field of the 'welcome mail' Drupal sends to new users (admin/user/settings).
I added the ID of the textarea in the visibility filter box, like in the attached screenshot.
After that i went to the 'welcome mail' settings again (admin/user/settings), and the Whizzywig editor was not shown.
If you still encounter this problem, can you perhaps give some more detail about what you are trying to achieve, about your environment, installed modules,... anything that could be useful...
Kind regards,
Sven
#2
Here is a photo which shows my current predicament.
My problem is with the textarea for the signup module.
I enter the textarea id edit-signup-confirmation-email in the filter based on textarea IDs, then i select don't show on these ids, and then click submit.
Whizzywig still shows up for confirmation email textarea.
Is there something else i should be doing?
It's frustrating this doesn't work, because from all I can tell it should work perfectly.
#3
Did you also provide filtering on path? Maybe those two are clashing with each other?
I'll install the signup module on a testsite and see if i can reproduce this...
#4
I installed the signup module and added the textarea IDs to the visibility filter. This hides the Whizzywig editor for me...
The only thing i can think of is that the path filter is overriding the textarea ID filter...
Do you perhaps have something like 'Only show Whizzywig editor on paths mentioned below:' and 'node/*/edit' in the path visibility settings?
#5
well close enough. I had it set to node/*, perhaps this does take over the permission.
#6
I have the same problem. However, I notice a symptom which may help narrow it down. It seems to work if I enter only one textarea ID to exclude. Any more and it doesn't work at all.
I do not have any paths listed in the include / exclude paths box.
BTW I tried 5.x-1.x-dev to see if that would fix it but the problem is still there. I am also seeing 2 other problems which I will file separately.
#7
Hmm possibily a stupid question, but you do put each textarea ID on a new line do you?
#8
Yes, I do.
#9
Yes, I do.
#10
I find a similar problem with "Only show ..." as well. If I enter a single ID, well and good, it works. If I enter two (one per line) then it works for one of them but not the other.
This is very strange and very frustrating. I am going to try on a different install and let you know if I get different results.
#11
All right, I did a bit more testing, and I found this:
For either "Don't show" or "Only show" I get the same behavior. That is good because it is the same code, right? Here's what happens. If I list more than one ID in the box, only the *last* one listed "takes." I.e. it ignores all the IDs except the last one. That doesn't make sense, but that's what's happening.
#12
More info. I did some debug using the devel module and found the problem. I ran the code from the top of the function _whizzywig_validate_element_id, along with some printing of values:
$values = variable_get('whizzywig_visibility_id_val', '');$values_arr = split(PHP_EOL, $values);
I get the following result for $values_arr; it looks OK printed as a single array, but individual elements have an extra EOL at the end, except the last element:
Array(
[0] => edit-body
[1] => edit-field-review-0-value
)
This is an ID :edit-body
:
This is an ID :edit-field-review-0-value:
This is why it behaves as I observed above. I don't know why the split returns the extra EOL at the end of the elements, though.
#13
The following code change fixes the problems for me.
diff -u -p -r1.8.1 whizzywig.module--- whizzywig/whizzywig.module 22 Oct 2007 23:11:29 -0000 1.8.1
+++ whizzywig/whizzywig.module 23 Oct 2007 03:25:54.000000000 -0000
@@ -383,18 +383,18 @@ function _whizzywig_validate_element_id(
$valid = false;
// when returned valid, the Whizzywig editor will be shown
$values = variable_get('whizzywig_visibility_id_val', '');
- $values_arr = split(PHP_EOL, $values);
+ $values_arr = preg_split('/\s*\n/', $values);
I believe this should work in all cases, "\n" within a "preg" function being equivalent to PHP_EOL.
#14
Nice to see you could find what caused the problem.
I'm not totally sure the changes you suggested will work in all cases though...
I know some systems use \n to indicate the end of a line, and some \r\n, that's why i thought it would be better to use PHP_EOL, because from what i've read, this should work in all cases. However it seems it doesn't :)
Could you specify the environment on which your site runs? (OS, webserver,...)
I'll try to find some code that will work in all cases. I'll do some tests on different environments to see if your code works in more cases, and if so, i'll update it in -dev.
#15
My personal test site runs on Fedora Linux and Lampp.
My www site runs on Red Hat Linux and Apache.
#16
i will test this again today, but for reference, my site runs on 'Linux' (my host is vague as to what build, but i use Bluehost) and I have entered data with windows xp which explains why the newline was acting strangely.(uses \r\n instead of \n which is used on Linux, mac, and Unix builds)
Sorry I haven't been able to comment sooner, but I had to roll a site into production and had to go with tinymce. But I still think this is much more lightweight and robust solution than tinymce.
I have looked in a number of places online, but most only refer to the difference between windows and unix based systems (including macs) my guess is that this solution will fix the vast majority use cases, but still it should be tested to make sure.
#17
this fix works for me
#18
thanks for the fix up here...works great!
#19
Glad my little fix seems to work for you all.
Sven, I think it should be fine to roll the code with the '\n' because a lot of the Drupal includes use it, such as common.inc and many others. Therefore if there is a platform that does not support the '\n' notation, much of Drupal would be broken for that platform anyway.
According to this article, the possible candidates for EOL are \n, \r\n, or \r (the last on older Macs and some others). This article also says that Internet communication protocols require the use of CR+LF for all platforms; in Windows, this is '\n' but in Unix, it is '\r\n'. This may be the underlying cause of this issue because Posix servers will consider PHP_EOL to be LF (\n) but the edit window returns CR+LF (\r\n).
Still, to cover all ASCII-based systems, even ones ignoring the CR+LF protocol, the code line in question could be written as:
$values_arr = preg_split('/\s*\n|\r/', $values);#20
Ok i'll follow you in this one :)
Which code should be applied? The one from #13 or #19?
#21
I guess I would go with #13, since that has been tested by a few people already.
Thanks!
#22
Committed to dev release!
#23
Automatically closed -- issue fixed for two weeks with no activity.