When you post a comment with the default HTML Filter enabled, default options, a 5.2 site shows the php escaped on preview and after post. The 4.7.7 does not, the php is removed for display. The php doesn't run in either case it seems so that is good. I have clean installs of 5.2 and 4.7.7. These versions are both running on unix boxes and have verified this on ubuntu and redhat at two different hosting locations (ok, one was my house!).

To re-create
To re-create, just make a comment with a full php echo statement on both versions, you'll see what I mean. 4.7.7 will not show the php code, 5.2 will. At least from my test runnning php 4.4.4.

Verified by others
I originally posted this in the forums, and another user has since verified my findings with more testing. He also provides more detail and points out some more wrinkles regarding inconsistencies. His testing revealed:

(quoting cog.rusty at http://drupal.org/node/171006)
In 4.7 using Filtered HTML input format, with HTML Filter enabled:
It strips out php tags and everything they contain.

In 5, using Filtered HTML input format, with HTML Filter enabled (without the codefilter module)
It escapes php tags and everything is displayed as plain text.

In 5, using Filtered HTML input format, with HTML Filter disabled (or just Full HTML input format)
It strips out everything in php tags just like 4.7. This stripping becomes somehow erratic when the php code is not in a single line and the line break filter is enabled.

I'm not really sure if this is a bug, but it looks funny. Shouldn't php be removed for display by default since you could make a mistake with setting input filters and be showing sensitive source code to the world -- albeit escaped? If you want to show the php code then an external module like codefilter should be required.

Thanks

Comments

cog.rusty’s picture

cog.rusty commented

To tell the truth, I like it better the way it works now instead of stripping the whole thing.

cog.rusty’s picture

cog.rusty commented

but you may have a point in the use case you describe.

chrisschaub’s picture

chrisschaub commented

I'd actually feel better if it stripped out the php, period. Before it got into the database. My reason is that there are so many people setting "default" filters for roles and users. So, a moderator has a default filter that allows php and goes in, edits a comment and then saves it. Code that wouldn't have normally run does it's thing. I think stripping the php unless the user has set eval to true is the safest thing to do by far. Hmmm

WorldFallz’s picture

WorldFallz commented
Version: 5.2 » 7.x-dev

Bug Bingo!

Confirmed head still operates this way. Moving to d7, fix can then be backported to previous versions.

marcingy’s picture

marcingy commented
Status: Active » Closed (works as designed)

Drupal's filtering does not work on the concept of removing data upon input. It works on the theory of stripping/escaping on output. This is behaving as per design ie the offending tags are removed I believe this is by design and marking the issue as such.