Creating php code node improperly escapes quotes

The example is provided above.

Create a "Basic Page". Set it to be php for the input. Create mypage.php in the same directory as your drupal install. Type the above code in:

 require_once('mypage.php'); 

Try to view the page. It will give the error saying unknown character referring to the ASCII character \.

Warning: Unexpected character in input: '\' (ASCII=92) state=1 in /modules/php/php.module(74) : eval()'d code on line 1

Warning: Unexpected character in input: ''' (ASCII=39) state=1 in /modules/php/php.module(74) : eval()'d code on line 1

Warning: Unexpected character in input: '\' (ASCII=92) state=1 in /modules/php/php.module(74) : eval()'d code on line 1

Warning: Unexpected character in input: ''' (ASCII=39) state=1 in /modules/php/php.module(74) : eval()'d code on line 1

Fatal error: require_once() [function.require]: Failed opening required 'php' (include_path='".:/usr/lib/php:/usr/local/lib/php') in /modules/php/php.module(74) : eval()'d code on line 1

If there is something more specific you need, please specify what would be more helpful.

I just installed clean yesterday. Installed locally, installed on my hosting. Same problem. Must be a problem with your setup. I was using 7.4, not sure how the version changed to 8.0. This problem did not exist in 7.0. The only thing I changed was the version of Drupal. Please try using 7.4.

Fixing category to bug report rather than support request since previous user was using the wrong version of Drupal.

What information do you want? I am using a shared host that I installed Drupal on. What else might help you? Should I post the installation (which is identical to what I downloaded from this site)? Is there anyone else who can try to reproduce this?

I have changed nothing from just copying files. I can look inside the database tables, and the code has been escaped. I go to edit the page, and it shows up escaped there. This didn't use to happen, I can go to my installation of 7.0, and this problem does not exist. There cannot be that many places where things are being escaped and stored in the database for creating a node.

Why am I doing it this way? Because I can write PHP code, Drupal is documented extremely poorly for new users, and it works. Why should I need to learn the hook system when all I want to do is display dynamic content? I like the menus and navigation tools, and can add non-dynamic code as well with revision history, comments, etc... If you can provide documentation on how I might accomplish this with the hook system, I'm all ears. I do not want to rewrite all of my code for something that has been working properly for quite some time, though. Are you suggesting I create my own module to do this? I'd rather focus at the issue at hand, which seems to me to be a perfectly valid use. I cannot even use:
echo "hello world";

without getting the same error.

Drupal not escaping when writing strings to the database would be a serious security problem making it vulnerable to SQL injection attacks. So I highly doubt that the actual queries to the database are unescaped.

If there is specific information that can help, please let me know what would be helpful. If you cannot help, please let someone else who is willing to do so help.

This worked in 7.0. I don't know if what you have is identical to what I was using, I was using 7.4 release. If that's the same as Drupal 7 HEAD, then it certainly is strange. I can try with a different version if you would like to make sure I am using the same version as you. Please direct me on how to get the exact same version you are using so I can test it. I want to make sure we are using the same code. If the problem goes away, we can at least trace it to the version I was using.

I'm not sure how you could use a WYSIWYG for editing pages. I select "Add Content" or "Edit Content" on a node and use the default editor:

!!myroot!!/#overlay=node/!!mynode!!/edit%3Fdestination%3Dadmin/content

Thank you for looking into this.

Is there a chance you are doing something different than what I am? If I am not using the proper terminology, there's a chance we are doing something different. If I am not being clear on what steps I am doing to create the problem, let me know and my apologizes for not using the proper terminology. Your concern about a WYSIWYG editor made me think we aren't doing the same thing.

Kernel 2.6.18-238.5.1.el5
Apache version 2.0.63
PHP version 5.2.14
MySQL version 5.0.92-community

I didn't have any modules added when I first notice the problem, although there are standard modules enabled that are not core, I can try removing those (I need to obviously add the php module to get it to work).

The system has not changed between 7.0 and 7.4, same versions of everything. I have an install of 7.0 still there and it is working properly on that same system. However, we have some differences on our system, although not sure what would cause the different behavior.

I'll try another clean install with a brand new database and see if that makes any difference.

I definitely can trace the problem to the form for editing/creating nodes (I did Basic Page for type) -> Database. If I fix the database to what it used to be (no escapes), everything works. If you know where that code is, I'll even look at it and try to debug it, but I am not familiar enough with the code to know where to start. There are some API functions to interact with the database that passes parameters, perhaps the problem might be with the database code.

I can try again tonight on the same server with the clean install and another box and see if it happens. If it happens on both machines with much different environments, I'll be a bit concerned. I can attach a debugger on the form editing code and try to step through it to see anything fishy on that machine.

What are you defining as core? I added no custom modules, I did not enable or disable anything other than the php module. I can start disabling other parts too to see if it goes away.

I've seen the same problem on two installs which was odd. I will also try re-downloading and installing clean to see what's going on, clean database, etc...

Hopefully it magically goes away.

Kernel 2.6.18-238.5.1.el5
Apache version 2.0.63
PHP version 5.2.14
MySQL version 5.0.92-community

I should have time to test some things out in a few hours, gonna start with another clean install/new database, and then with a new machine with a different configuration to see if that makes any difference.

Results are somewhat interesting:

Clean machine on windows install: works perfectly
Reinstall clean with a new directory, new database on the system described in post 22: same problem as described.

This at least explains why other people are having a hard time reproducing this.

One major difference is I have php 5.3 on the windows machine. I also have a different version of mysql ( 5.5.12 on Windows). I believe everyone who has tried to reproduce has done so with php 5.2.

Since this used to work on this system, I'm starting to think that there's some incompatibility with Drupal 7.4 and either php 5.2 or mysql 5.0. More likely php 5.2, but that's a guess.

The bad news is that I can only reproduce this on the shared host, so I don't have as much access to debug or screw around with the system too much. I'd like to just start digging in the source to figure out what could be wrong, I could diff key files to see if there's anything out of the ordinary. I don't think there is anything inherently wrong with the configuration since it used to work in 7.0. I'd be able to test any other versions of drupal as well, perhaps that could help narrowing things down.

Any advice would be appreciated on narrowing this down. I still think there's likely a bug in Drupal somewhere, but until we find the offending code, it's going to be hard to confirm. If someone knows the code base well enough to tell me where to narrow things down, I'll try digging it up myself, although not being super familiar with all the Drupal API being called, it might be tougher for me to debug. Thanks for your patience pingers.

I'm more concerned about what is sending the info to the database, I'm not sure that module does it.

That gave me an idea, I'm trying it without the php module, just filtered HTML, same thing happens, it has the quotes on it. \"hello world\" came from "hello world" (hoping this doesn't screw up when I submit the reply).

So it can't be specific to the php module, but whenever I press "Save", whatever is going out to the database. Do you know what that code is?

The weird part of it is that the title of the node comes out unscathed, but just the body is screwed up.

I am not aware how I can debug on my host's server, although I may try modifying the drupal code and have it try to write to a log. It won't be an easy process. I'm hoping looking at how it works on my other system will give me some insight on what to look for.

I was able to add the watchdog to both my working system and non working system. There were some key differences:

Working: [title] => "hello world"
Not Working: [title] => \"hello world\"

So the problem definitely is happening before it even tries to save it in the database and on the creation of the node object. Where is this done? For some reason my debugger isn't stopping at my breakpoints for me to examine the call stack.

I was wrong before that the title came out ok, the title does get screwed up.

I'm still tracing things, but my best guess now is it's coming from the form -> node conversion code. I'm trying to follow the code, trying to find a good candidate to put another watchdog in on the server to trace the problem. So making progress, hopefully I can narrow this down.

Narrowed it down more, inside of node.pages.inc in the node_form_submit_build_node function, I had a watchdog on form_state, and saw that it's escaped even that early. Looking more and more like form code. More debugging later.

Good point. I used your method, and it still comes out as escaped, so that means it's not related to the database. It's happening as early as processing the form values.

Thanks to everyone for their help so far, hopefully I can narrow it down. If anyone has a PHP 5.2 system set up, it would be really nice to test this case there.

I narrowed it down as much as possible for now. I put an error message on $_POST["title"], and it shows up escaped.

So there are a few possibilities, but I don't understand the code well enough to know where to look.

What happens on form submission? Is it some javascript that tries to validate things or runs before submitting? Does it run through some other layers before the code I was looking at _POST to pre-process it?

It's quite odd that it doesn't work on the one machine but does on the other.

I think you likely are finding the problem. I'll give it a shot. Since magic_quotes is deprecated in php 5.3, that could explain why it works for so many people. PHP has a default .htaccess file that got installed, I wonder if either has it disabled, or had it disabled in previous versions and no longer does (which wouldn't affect 5.3 systems, but would affect 5.2).

I'm going to take a look at let you know, but that very well could be it. If that's it, the most likely culprit would be a change between the .htaccess file in 7.0 and 7.4. But better to test and be sure before jumping to conclusions.

Configure Command: './configure' '--enable-bcmath' '--enable-calendar' '--enable-exif' '--enable-ftp' '--enable-gd-native-ttf' '--enable-libxml' '--enable-magic-quotes' '--enable-mbstring' '--enable-pdo=shared' '--enable-soap' '--enable-sockets' '--enable-wddx' '--prefix=/usr' '--with-curl=/opt/curlssl/' '--with-curlwrappers' '--with-freetype-dir=/usr' '--with-gd' '--with-gettext' '--with-imap=/opt/php_with_imap_client/' '--with-imap-ssl=/usr' '--with-jpeg-dir=/usr' '--with-kerberos' '--with-libdir=lib64' '--with-libexpat-dir=/usr' '--with-libxml-dir=/opt/xml2' '--with-libxml-dir=/opt/xml2/' '--with-mcrypt=/opt/libmcrypt/' '--with-mhash=/opt/mhash/' '--with-mysql=/usr' '--with-mysql-sock=/var/lib/mysql/mysql.sock' '--with-mysqli=/usr/bin/mysql_config' '--with-openssl=/usr' '--with-openssl-dir=/usr' '--with-pcre-regex=/opt/pcre' '--with-pdo-mysql=shared' '--with-pdo-sqlite=shared' '--with-pic' '--with-png-dir=/usr' '--with-pspell' '--with-sqlite=shared' '--with-ttf' '--with-xmlrpc' '--with-xpm-dir=/usr' '--with-xsl=/opt/xslt/' '--with-zlib' '--with-zlib-dir=/usr'

I noticed that --enable-magic-quotes is present.

magic_quotes_gpc Off On
magic_quotes_runtime Off Off
magic_quotes_sybase Off Off

Time to change the .htaccess file to see if that was it.

marcingy-

I think you found the source of the problem. I checked phpinfo on the working system, magic_quotes is set to "on". The .htaccess file is considerably different. I downloaded the 7.0 revision and it looked similar to the 7.4 .htaccess file. I did install from the fantasticodeluxe system, so it may have had some customizations to the .htaccess that was initially installed.

The weird thing is, it appears all is well if magic_quotes is enabled, but screws up if magic_quotes is disabled. The other weird thing is, it appears to have the magic_quotes behavior only when it is disabled, and not when it is enabled.

Perhaps I am understanding this wrong. Any thoughts?

That solved the problem. I had it under a subdirectory that also had the "correct" 7.4 .htaccess file, so it was passing results down the line. Fixing it in both places makes drupal work.

Thanks for all your help. I don't know why the default .htaccess file coming from my host is so much different.

Is there some other component that my host needs to update to not have this problem?