WYSWYG Editors and textarea fields

Posted: Tue Sep 13, 2005 3:31 pm

I asked this over at nukefixes, but I thought I would submit it here too as some food for thought to any audience that doesn't see it over there.

In working on compliance for 7.8, one issue has me completely baffled.

I thought after spending 2 weeks on it, I think it is time to consult others that maybe have figured this out already.

I have recoded the News module for 7.6 and 7.8 to 100% compliance.

In doing so, I discovered a bizarre issue relative to the use of any WYSIWYG editor relating to the textarea function.

Here's the jist of it.
You can use any one of these WYSIWYG editors; however, when creating the data in PHP's TextArea, the editor itself actually creates a compliance error for every HTML element that you use in that editor.

Let me give an example.
Let's suppose you are on the "Add News" screen in administration.

You type out an article that has text in the "hometext" and "bodytext" fields. This article has 10 hard return "br" and 2 bold "b" elements.

In that scenario, when you hit "Preview" you will be generating 56 compliance errors on that screen. Now this is not to say that the HTML output on the News page will have errors, as that is not the case, only the administration screen will reflect these errors.

That is to say that the administration screen gets broken down into 4 frames and each frame will have 14 errors in it.

1 = Preview
2 = storytext
3 = extendedtext
4 = notes

The errors themselves will break down as 10x - Invalid br elements in textarea and 2x invalid strong (and the other two are /strong) elements in textarea.

Now what bugs me is that I have tried every trick in the book to try to convert the generated output on this screen to be compliant.

I have even messed with the includes/javascript definitions to try to force it that way. On top of that, I've tried changing the values of these fields in the news/admin/index.php. None of my attempts have succeeded. The only thing I can think of is that there would need to be a complete template of conversion for this file to alter the displayed text of the textarea fields, but maybe I am completely off. I simply just don't get it.

To complicate matters, to a certain degree, this is also the case with the normal (non-WYSIWYG editor) display of versions like 7.6; however, in that case br elements are not displayed. Rather, you just see a source value of a blank line wher the br element would appear in a WYSIWYG editor output (I'm assuming a /n function?). However, with things like bold, italic and other code, you would in fact get errors for every one of those tags on the preview screen.

So, this prompts the question. What is PHP-Nuke doing wrong by default in having (displaying/echoing) improper HTML content inside a textarea field? Further, what can be done that would allow you to preview the actual look and feel with this code, but without it generating compliance errors? Would it be necessary to have an HTML Preview window for these functions?

The real issue here rolls back to compliance. If you want to be able to view any particular submission (whether that be a download text, weblinks text or any other page that has the potential for HTML code in a textarea field) for compliance, it is important the display itself (in administration) be compliant.

Now here's the kicker. I can do this with either BBCode or HTML in the Forums module, I can preview and get ZERO compliance errors.

So this prompts the question, what are they doing there that we aren't doing here? Is it the templates? Or is it the way that phpBB handles HTML and BBCode?

Anyway... Just thought I would ask as I'm completely baffled on how to fix this. Maybe there is nothing we can do about this for now, but I thought I would ask anyway.

Thanks!
Steph

Site Admin Joined: Jun 04, 2004 Posts: 6432

This is very interesting. I tried it on a patched version of 7.5 with FCKeditor and NSN News, but adding the formatting in the textarea didn't increase the number of validation errors.

Posted: Tue Sep 13, 2005 6:55 pm

I don't have NSN News, so I can't say for sure what might be different about the coding of that module. In PHP-Nuke regular news, every time you add html formatting, the number of validation errors increases; however, as I said, it is even more dramatic with TinyMCE as the BR's add errors (beyond what say 7.6) would add.

Again, this is only on the admin preview screens. When presented on news pages, there are zero compliance errors.

You can see this demonstrated at my 78 test domain. I can even give you an admin ID if you want to login and see what I mean.

Again, I'm baffled.

Steph

Posted: Tue Sep 13, 2005 6:58 pm

I went first to the test domain, but remembered that it was only on the admin page. If you set me up and pm the info, I will take a look.

Posted: Tue Sep 13, 2005 7:19 pm

Actually, no need to set up another admin - the same problem occurs on the submission page (I also noticed the non-compliant use of the blink tag when the topic isn't specified).

But that gives me something to work with...

Posted: Tue Sep 13, 2005 7:31 pm

Oops.. Because FCKeditor hides the WYSIWYG control in an iframe (cheating!), accurate validation is not possible, at least not by saving the page as HTML and validating by upload. Suggestions?

Posted: Tue Sep 13, 2005 7:43 pm

Well, actually so does TinyMCE. See above that generates 4 frames, each have validation errors. Hence the report. Sad

Posted: Tue Sep 13, 2005 8:24 pm

When I view the source on TinyMCE, it shows TEXTAREAs. FCKeditor replaces that with IFRAMES. Are we talking about the same thing?

Since the saved TinyMCE source contains TEXTAREA (as well as the value of the TEXTAREA field, W3C is able to determine (correctly or not) that it's invalid. Since only the IFRAME reference, not the actual HTML or value, is saved on the FCKeditor page, W3C has no way of determining that it's invalid.

Yes, I realize that it doesn't solve the problem...sorry...

BTW, even though we can replace the blink tag with a compliant text-decoration: blink style, it still only annoys visitors with Gecko browsers... I suggest eliminating it.

Posted: Wed Sep 14, 2005 9:59 pm

I don't know what I was thinking, it was a 20-hour day, what can I say... I was thinking Div's not Iframes.

Anyway, after another two days of working on this full time, I finally figured out what needs to happen on my own. I was hoping you others would help me... but alas... not. lol

With about 20 PHP documentation screens open, and about 300 re-uploads of reworked code, I finally stumbled onto the solution.

I have finally fixed this issue (or at least I think I have). It involves a substantial amount of recoding and exposes where FB went completely wrong in implenting TinyMCE with Nuke.

As soon as I have tested it completely, I will post the solution(s), but as it stands now, all 4 Div's are coming up 100% compliant! Hooray!

The real problem here is going to be the requirement in recoding all of the modules that use TinyMCE to properly support it for compliance. Needless to say, it will be done as part of "After-Patched" but it just pisses me off that he is such a lousy coder and doesn't test this stuff.

In this discovery process, I also figured out that by using TinyMCE in things like the Feedback module, you end up getting encoded messages by email (FB is just such a schmuck for not testing). I have resolved that too, but again, it involved a substantial amount of coding to support HTML output.

Oh well... sheesh.

Steph

Posted: Wed Sep 14, 2005 10:19 pm

Great! With help from Sixonetonoffun, I recoded the FCKeditor for Nuke with improved security and flexibility in mind, and I'd be happy to support After-Patched in any way I can. Maybe what Six and I did can provide enhanced security and support for TinyMCE or other WYSIWYG editors (there is no reason why it shouldn't). Although I can't work 2 20-hour days in a row, I am definitely willing to work...

Posted: Wed Sep 14, 2005 10:54 pm

Well, that might be a possiblity later, but as it stands now, the idea behind "After-Patched" is to establish a 100% Bug-Free and W3C Compliant core of baseline code and to use that as a platform that would assist other developers in fixing their solutions and moving forward.

In other words, the concept is to fix what is out there now and to make it do what it should have always done all along. Thus, allowing people like you to take that code and intregrate these new features without having to modify that core code to achieve functionality and compliance when implementing additional solutions.

The other aspect of it is also to give a 100% Compliant platform for theme developers to work from, so that future Nuke themes can be more robust as well as 100% Compliant themselves.

The theme in my 78.64bit.us test domain is a good example of how Nuke themes SHOULD be built, but it is still a work in progress as we are working toward Stict Compliance and even more optimization.

If you load it up in a tester though, you will notice that it is about 80% CSS! Quite frankly it is unlike anything anyone has ever seen in the PHP-Nuke World, but it took recoding Nuke baseline code to make even the concept of creating it feasible.

Anyway, regarding this existing editor scenario, I am going to be changing the way the editor is integrated completely, so that it is not loaded as overhead in areas where it is not needed. On top of that, I am TRYING (another major problem) to use a GZIPPED version of the editor that is like 10K instead of 100K. It's a bitch that this thing gets loaded on every page, so addressing that will help. But if it has to, then I at least want to use something much smaller!

Steph

Posted: Wed Sep 14, 2005 10:59 pm

Great ideas, all around. Please continue to keep us posted, and tell us about snags so we can at least try to help...

Posted: Thu Sep 15, 2005 6:33 pm

Steph,

I am offerring to be a tester of "After-Patched" as well as contribute 100% compliant module work for it. My goal is to re-code all my modules to be 4.01 Strict in preparation for what would most likely come with "After-Patched" down the road. As I wrote in a post on 64bit.us, I have completed re-coded the HTML in my new module that I am working on to be 4.01 Strict! What fun...

Use me and abuse me... of course, that might mean I have to drop all my module work. Sad

New Member Joined: Jan 18, 2007 Posts: 4

here is my problem ! every where i place a <TEXTAREA> the WYSIWYG pops out on me . I have no clue how to stop it ! it is blowing my blocks to peices and its getting irratating ! please give me an ideal of why its doing this ?

Posted: Fri Jan 19, 2007 5:31 am

You are using 7.7 or higher, and it includes TinyMCE. This was not implemented very well and causes this to happen. I haven't looked into removing TinyMCE, but if you remove the JS that loads it, this problem will go away. I'll check, but off the top of my head, I'd guess it's probably in the includes/java script.php or other includes/ file.

Posted: Fri Jan 19, 2007 1:39 pm

i figured out how to shut tinymce off but this is not the method i want to use because it takes use away from other TEXTAREA's where i do want to use the editor . it was simple to shut off . i just went into my config.php and looked for $nuke_editor = 1; and changed it to $nuke_editor = 0; <--- this shut the editor off completely ! With it shut off completly it gives me a problem like in my messages control . I have no way to do things such as center the message text . grrrrrrrr ! LOL very irratating ! Does anyone think its possible to code the php block files to turn off/on the editor ?

Posted: Fri Jan 19, 2007 1:43 pm

You can always type the HTML yourself. Wink

Posted: Fri Jan 19, 2007 2:47 pm

html codes do not work for some reason . i write them in and try to save message and it only removes them . they barely even worked with the tinymce on and it has the center text button and i would have to click it and save only to have to do it a few more times before it actually centered the text .

Posted: Fri Jan 19, 2007 3:00 pm

In order to use HTML in user submitted forms in Nuke you have to allow the tags in the AllowableHTML array in config.php.

The TinyMCE thing in 7.9 really didn't work right anyway, and I disabled it after a week or so.

Posted: Fri Jan 19, 2007 5:44 pm

yeah it really doesnt work all that well in 8.0 either . any how to give every one a clue of what im doing . I was trying to do a link us block with a textarea and a button that copied the link from the textarea to the clipboard so people could just copy and paste into there webs . the problem was the textarea was using the tinymce and blowing the side box way wider than it shoulda been . After a 24 hour battle striaght with this i came up with a solution to this problem . in the php block instead of writing in the textarea i used <input type=text> with a blank value . the reason for the blank value was i couldnt figure out how to git the link code to go into the value without cutting it off here or there so ... i made a quick .js file with the link writin in there and when the copy button is clicked it writes the link to the textbox and then copies it . if anyone would like this block to see this method or use for themselfs i will be zipping it and placing in my website for download . Once i have it in place i will post the address to my site for you to go git the block .

Posted: Sat Jan 20, 2007 5:12 pm

I *think* there is a way to disable TinyMCE for specific textarea, but to post the HTML to show as HTML tags (rather than being displayed inline) you need to use special characters (like &gt instead of <).