Using FCKeditor module I am able to include php code whhen using php filter and FCKEditor.

When using WYSIWYG with FCKERditor for the PHP filter FCKEDitor destroys my php code in a node.

Comments

sun’s picture

Category: bug » feature
Status: Active » Postponed (maintainer needs more info)

Can you please clarify what exactly you mean and how exactly you intend to use PHP filter?

realityloop’s picture

With the FCKEditor module I am able to switch to code view and enter php code.
eg:

<php? echo "Hello World"; ?>

When I switch back to visual editing the code is left alone and will function correctly when I save the node.

When using WYSIWYG doing the same when I click back to visual edit it breaks the php code

sun’s picture

Title: FCKeditor destructive to php code, FCKeditor module isn't » Add support for (keeping) PHP code in HTML editors
Status: Postponed (maintainer needs more info) » Active
bendenoz’s picture

Actually I'm not sure this issue is specific to FCKeditor.
It looks like any php code working prior to switching on the wysiwyg module gets removed.
It should not be the case for PHP code enabled content...

Repro steps :

- In admin/settings/wysiwig : remove any editor for PHP code input format
- Create new content, switch input format to PHP Code
- Edit body to " echo "Hello World"; " and save -> the node works
- in admin/settings/wysiwig : set PHP code input format to any editor
- Edit the node and save (without making any changes)
- the content is gone

TwoD’s picture

Component: Editor - FCKeditor » Code

Just adding this for reference:
TinyMCE Codeprotect plugin.
Has anyone used this? Comments?

FCKeditor's ProtectedSource option.

If we implement this, and we have solutions for the other editors as well, should we go for leaving the PHP code in "plain sight" when editing, or hide it to only be edited in View source mode?

Btw, I'm thinking of perhaps putting this in a separate module as blending PHP into the whole What You See Is What You Get thing is usually not standard procedure. And this does not seem to be possible without much tweaking of some editors (TinyMCE). which is better done in a native plugin along with a Wysiwyg wrapper than inside the implementation layer.

But let's discuss that later. First we need to figure out a good way to do this.

bendenoz’s picture

Well ideally you'd want the code to be interpreted in normal view, and see the source code in source view :-)

I think the real problem here is that wysiwyg actually _breaks_ nodes that contain php code, so it should either stop supporting them altogether or at least leave the content as it is (as mentionned, the standalone fckeditor does that). May be this should be changed from feature request to support request?

PHP code is quite useful for inserting relative links that won't break when moving the site to different locations, and having wysiwyg is a must if the rest of content is going to be edited by other people who are allergic to html...

TwoD’s picture

Hehe, yeah that'd be neat. ;)

Wysiwyg module does not officially support PHP code, so this would be a new feature. But Wysiwyg module does not actively do anything to prevent it from working either. It's the editors themselves which break the code as they are simply not designed to handle it. When the content is retrieved from the editor's WYSIWYG mode it's already broken and Wysiwyg module does not know what it should look like. The editor might even have tried to correct some incorrect HTML caused by not interpreting the PHP code and what's left is a mess. (I do think people will soon realise we can't do anything about that issue and change their code to compensate.)

The FCKeditor module uses the ProtectedSource option to preserve PHP tags in WYSIWYG mode and we could use that too. But we also need to make sure the other editors can handle it as well (starting from the same release) or all hell will break lose if user B destroys user A's PHP code just because they prefer different editors. Maybe we could escape and hide PHP code when attaching the editor and restore it when detaching. A Drupal plugin could do this, but we need to know how the editors will react to various ways of escaping content. A simple HTML comment might be enough most of the time, but we've already had troubles inserting comments properly with the Teaser Break plugin. This needs some experimenting...

bendenoz’s picture

Understood about the protected code option in fckeditor.
I believe in that case only those editors capable of protecting the code should show up in the third popup menu.
At least make sure it remains empty / disabled for the time being until one solution is validated, this will save a lot of frustration for users wanting to switch from fckeditor to wysiwyg.
Thanks

TwoD’s picture

What third popup menu? And what should be left empty? I'm sorry but I must have missed something as I don't understand what you mean.

bendenoz’s picture

Ok sorry for the confusion. I guess I meant drop down menus.
Just to be clear, in my setup I have both the core module "PHP Filter" enabled and Wysiwyg 6.x-2.x-dev.
When I first go to /admin/settings/wysiwyg after enabling the module, I have three dop down menus, one for each input formats available : "Filtered HTML", "Full HTML" and "PHP code". Right now they are all populated by the editors I have installed.

So desired behaviour would be for the third one (PHP Code) to only show the editors that will _not_ break the PHP code, and as long as no editors support it this third line should be disabled for the time being

I hope this makes sense

TwoD’s picture

oh I see, you mean you should not be able to select an editor for an input format with "PHP Filter" enabled, unless it's capable of handling PHP code. Hmm, I think that might cause even more confusion and people would begin wondering why they suddenly can not use some editors for a specific input format when they're available on others. This would also be a very hard decision to make for each editor, especially since it is possible to make some editors behave better by using certain settings or plugins, as demonstrated above. I think we'd be better off implementing a general purpose workaround/plugin, based on some way to hide the serverside code while in WYSIWYG/HTML mode. Editors which are not really WYSIWYG but treat the contents as text or some other markup should not be harmed by this.

tjodolv’s picture

Just popping in to say that this feature would be much appreciated. The way it works now, everytime certain nodes are edited by "regular" admins, someone with PHP-knowledge has to come and re-add stuff like views_embed_view('MYVIEWNAME');

beyond67’s picture

subscribe

mcottier’s picture

I am close to getting TinyMCE working so it allows PHP code without stripping it out. I have TinyMCE installed with the WYSIWYG module, and have the advcode (advanced code) and codeprotect plugin's installed and running on Drupal 6.16.

Right now it even puts a placeholder image that shows "<? code ?>" in the TinyMCE editor when viewing it in normal WYSIWYG mode. When in Source Code view, where you want to add/change the php code it will let you add it, then you click update and the PHP image placeholder icon shows now where the code is. But the final problem I am having is when switching back to the source code view it changes the PHP code to "[img]/sites/all/libraries/tinymce/jscripts/tiny_mce/plugins/codeprotect/img/codeprotect.gif[/img]".

Not sure what is going on, but I need to get it going and if I do I will post here what i did. It has something to do with the source code viewer (which is advcode in this case, not the default TinyMCE HTML source viewer, but I did try it to) not restoring the php code back. The code is stored in the PHP placeholder image icon's "alt" tag when viewed in regular WYSIWYG mode, but somewhere the connection is not being made when it is suppose to restore the code in source view mode.

Up to this point it has required no hacks really, just uploading the 2 plugin's and adding the button/plugin loader to the WYSIWYG tinymce.inc module file.

TwoD’s picture

Looks like you have the BBCode plugin enabled.

I doubt we'll ever require any separate editor plugins to be downloaded, or support them in Wysiwyg's core. The .inc files are only meant to contain metadata about the "standard" versions of the editors, the rest we leave up to contrib modules to support via Wysiwyg's API.
You should instead implement hook_wysiwyg_plugin() in a separate module to let Wysiwyg know where to load these plugins from. Then there would also not be a need to put them in TinyMCE's own plugins folder, as you can use the 'path' key in the array(s) returned from the hook implementation to say where to load the plugins from. A single hook implementation could include metadata for both plugins.

mcottier’s picture

Thanks for the help TwoD, that helped fixed that part but now it just shows <p><img src="/sites/all/libraries/tinymce/jscripts/tiny_mce/plugins/codeprotect/img/codeprotect.gif" alt="php%20echo%20%27test%27%3B%20" border="0"></p>.

I will keep messing with it, i think i really just need a statement that leaves the code untouched like

tags are, but it's hard to find/know where to put it. I actually did find the file that does it for script tags in the TinyMCE library, but adding "php" or "?php" to the allowed tags doesn't work still :( And I am doing this on a development site. On the live site I have CKeditor installed which allows php code just fine by itself, if i un-comment the function that allows php code in the ckeditor.config.js file. But when you put php code inside of other tags (input tags for example) it changes it to "cke_protected", and I have given up on trying to fix that. Mainly though CKeditor doesn't have syntax highlighting in source code view either, which is something that is really needed for us.
TwoD’s picture

Well, not all of these problems are fixable (given a reasonable amount of workarounds and hacks), since most editors are by design targeting markup editing, not script editing.

I'm however sure that someone will eventually add highlighting to at least the source mode in CKEditor - given what its architecture looks like and supports.

I'm not sure what the image problem is caused by, but I'll see if I can take a look at it when I get back home.

mcottier’s picture

yeah i figure CKeditor will have it eventually to, and they seem to be pretty good at updating it so who knows, maybe it will happen sooner then i think :)

and the php problem in CKeditor is really not that big a problem because for now we use php includes, but also the tags i am having problems making CKeditor not change to "cke_protected" can in the end just be in the php code itself like this: <?php echo "<input>".$variable."</input>"; ?>

but then since CKeditor doesn't process php in edit mode you won't see all that stuff, and be able to edit it in WYSIWYG mode. not good when a lot of staff edit the website.

and wow thanks, any insight into making this work would be much appreciated.

modctek’s picture

subscribing

butler360’s picture

Subscribing.

thomas4019’s picture

subscribing

natehill’s picture

subscribing

chrisnovak’s picture

subscribing

enkara’s picture

CKEditor module keeps PHP code. I tried this module but I can't use it without this feature. I think it's a good module, so I hope it's fixed soon. Subscribing!

RobbM’s picture

Subscribing.

ledom’s picture

Subscribing

TwoD’s picture

There are workarounds for this you can implement in a small custom module so Wysiwyg will not need to be modified (no need to keep track of a patch until this gets support in Wysiwyg).

CKEditor: #1403918-1: "<?php" replaced by "<!--?php" by CKEditor
TinyMCE: #1403918-6: "<?php" replaced by "<!--?php" by CKEditor

Those modules can be combined to one if using both editors.

suryabhi’s picture

Issue summary: View changes
Status: Active » Closed (outdated)