Strips out PHP code

I am getting the same behavior here. Strips out php code when using the 'plain editor' button option as well as the 'coder' button option. I'm going to look into this a bit deeper to see what's going on.

I was having the same problem until I commented out the line that runs cleanHTML in yui_editor.js

else {
coderState = 'on';
// this.cleanHTML();
Dom.addClass(iframe, 'editor-hidden');
Dom.removeClass(ta, 'editor-hidden');

Now when I click on the "Edit HTML Code" button I'm presented with the untouched content of the textarea that lies beneath the yui_editor.

It works well for me.
I wonder if this line should just be removed from the yui_editor.js file so everyone can have this capability.

I commented out that line of code, but I found it in the coder.js file. This didn't work for me. I am trying to put a google map on my page but the YUI editor keeps stripping out the code. Got any other suggestions?

Thanks

Same here, commenting that line in coder.js only prevented YUI editor from cleaning the code when the "Edit HTML Code" button is toggled. As soon as one saves, YUI Editor is unfortunately cleaning up again.

I came up with a work-around for including PHP code so YUI Editor does not strip it out on save. It takes advantage of YUI editor not stripping out HTML comments. Click "Edit HTML Code" and paste this into the YUI Editor to see the work-around in action:

Notes:

• "PHP Filter" module must be enabled to put PHP code within content
• This should make the "PHP Code" input format available, check under
  Administer › Site configuration > Input formats
• When saving from the YUI Editor, under "Input format", make sure that you have chosen "PHP Code"
• Always switch back to normal view in YUI Editor before saving due to this bug:
  #458820: YUI Editor not saving with HTML "Coder button" enabled

Yeah, I am having the same problems here too. Using YUI Editor version 6.x-2.33
Hope this gets resolved soon!

I found two work arounds for this issue. One is this:

• Make "handleSubmit: true," into "handleSubmit: false," ... I don't know if anything gets lost for html formatting, but I haven't found any losses yet.

The problem with this method is you cannot preview or make changes or else YUI will take the code over on edit.

• The other option is to split the summary and put your php code into the summary instead of the body. Apparently, YUI does not intercept the summary formatting in plain text view.

Using some of the information found in previous posts here I've been able to come up with a patch that works well for me.

It only affects the yui_editor if the 'editcode' button has been added to the toolbar which seems appropriate to me.

The patch basically removes the editor's submit handler and disables the cleanHTML function call if the 'editcode' button has been added to the toolbar.
This prevents the editor from removing php or javascript code or making other modifications to the content of the editable textarea.

I apologize if the patch isn't in a correct format. Please let me know if I should resubmit it differently.

Thanks for a great module.

Well, I was wrong. That patch 'yui_editor_patch.txt' doesn't work as well as I thought it did. Back to the drawing board. Sorry for the confusion.

I was also wrong about making handleSubmit: false

While this does work for getting php code to load, it comes with some problems. The biggest I've found is if you have two yui_editor windows in one edit node, it will only process the last edit window. Perhaps this issue is not often a big deal, but it remains an issue.

As there seems to be some confusion here about what actually happens, let me clarify a few things.

1. cleanHTML() does not strip PHP tags.

2. Nothing in YUI editor strips PHP tags actually.

What happens is this: if you use the coder plugin it saves the html including the PHP tags with a call this.setEditorHTML(). No stripping takes place. But the code is assigned to the iframe with this piece:

this._getDoc().body.innerHTML = html;

Note that at this point the html still contains the tags. But the processing instructions are not stored in the DOM. That's the trouble. So if you read them back out with this._getDoc().body.innerHTML the processing instructions are gone.

To solve this problem you need to make sure the processing instructions survive in the DOM and are read out correctly. This could be an interesting problem, which I unfortunately didn't have the time for to solve.

See #580086: Fatal error: Unsupported operand types in content_profile.module on line 80 for a fix.