Soma Posted November 18, 2013 Share Posted November 18, 2013 A co-worker asked me what the problem could be, as the html of a normal TinyMCE textarea field gets stripped out completely. - Configuration of the field is all correct. - Turning on/off the content type html or unknown doesn't have any effect. - I then tried to hook into saveReady and echo out the value, and it has no html at all at that point. - Also hooking into before FieldtypeTextarea::sleepValue the value already has no html when it gets there. - Changing Browser doesn't have any effect. - It's a PW dev install I think 2.3.4 or 2.3.5. - I never experienced this or know of anyone here having that issue. Any ideas what to look for or try? There is no other modules or hooks that would interfere with textfields. Link to comment Share on other sites More sharing options...
Hani Posted November 19, 2013 Share Posted November 19, 2013 I was having an issue with a 404 error appearing when adding an image using TinyMCE for a client once (see here: http://processwire.com/talk/topic/4340-tinymce-images-saving-leads-to-404/) - so I know mod_security rules can do funny things that cause issues with HTML in TinyMCE. Perhaps look into that? (I ended up having the webhost, Liquidweb, help me out and they whitelisted the rules that were causing the issue.) 1 Link to comment Share on other sites More sharing options...
Soma Posted November 19, 2013 Author Share Posted November 19, 2013 Thanks Hani, but nothing like this. I've been looking into it right now more closely and it works for other fields, and the thing is it works only for textarea language TinyMCE fields. Normal Textarea TinyMCE fields it is broken and doesn't work and html get's stripped out. This is with dev 2.3.3. I'm currently trying an update. Link to comment Share on other sites More sharing options...
ryan Posted November 19, 2013 Share Posted November 19, 2013 That sounds really unusual. I'd probably be looking at the webhost to see if they are stripping it out before ProcessWire gets to it. Just because some other fields work (or it works in language mode), doesn't necessarily mean they aren't doing it... mod_security rules can be triggered by combinations of things that don't always make much sense from our context. Just as a test, try adding this to the top of your /site/templates/admin.php: wire()->addHookBefore('InputfieldTextarea::processInput', function($event) { $textarea = $event->object; $name = $textarea->name; if($name != 'your_field_name') return; $value = wire('sanitizer')->entities($_POST[$name]); $textarea->message($value); }); Try saving a page with that textarea field on it containing some text. Does the green message at the top of the screen contain HTML? If not, it's probably being stripped out by the server before PW gets to it. The hook above is looking at that field before anything else in PW touches it. 1 Link to comment Share on other sites More sharing options...
Soma Posted November 19, 2013 Author Share Posted November 19, 2013 Thanks Ryan, that's what I did but not using $_POST[name] but with $field->attr("value") and it was already stripped out. Lots of confusion. Testing around and looking at database revealed the real issue. It's that there's a "stripTags" option setting for textarea fields. It looks like that was checked before it was changed to TinyMCE. Changing it to TinyMCE hides that setting but is still save in the config in DB. So kinda mean. That also explains why changing it to multilanguage field and back to textarea makes it work again. So it's a bug that must be harder to find than fix. It was tricky because I wasn't aware that much that there's a stiptags option on textarea fields that is hidden once Wywiwyg is enabled. 2 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now