A quick summary of where I stand right now:

We have a low traffic site here that was redone in Drupal about 8 months ago, before I was in the picture. An external design firm sold the owners on the technology as a way to enable non-programmers to update site content easily. Unfortunately, they did it wrong - they built our theme in-place over the Bartik theme instead of subclassing it, things like login boxes are written directly in the Basic Page Body textareas that our non-programmers are supposed to be updating, on and on and on beyond what's relevant to this post. Had I been here when it was forked over, I'm not even sure I would have taken delivery.

I've been meaning to pick up Drupal one of these days to go in and try to refactor this hot mess, but the non-Drupal work that actually keeps us all employed around here has prevented that.

Fast forward to now. I've got a feature request for the Drupal site that they want ASAP. It's a very simple application. Given the rush, I decided to develop the application as a straight PHP app to monkey patch onto the Drupal site. Based on some forms I had to maintain within the Drupal frontend (not using webforms, mind you) that I am able to $_POST back to some non-Drupal PHP with, I thought I could get away with this.

Now as I am trying to integrate my super vanilla PHP code into our Drupal environment I am running into all sorts of problems. At first my $_SESSION array wasn't persisting from page to page but I was able to figure that part out on my own by googling.

TL;DR: The question

Where I am stumped is with my $_POST array. I POST form data (an honest to God, completely naive HTML form) from one non-Drupal .php file to another non-Drupal .php file and it never arrives. The right way to do this - and the way it will get redone someday - is clearly to use the provided Drupal APIs for building forms.

Unfortunately, I am in such a position that there is absolutely, positively no time to rewrite this the right way today. With that in mind, is there a way to pass this POST data directly to the php file I am using for form processing?


It looks like maybe I am getting redirected internally and the data is not coming along for the ride. Could this be it? If so, it looks like Forms specified using the API Drupal provides can do something like :

$form['# redirect'] = false;

to prevent their being redirected. Is there some perhaps hidden input field I could pass in with my non-Drupal forms to accomplish the same thing?

  • This turned out to be a wild goose chase that had nothing to do with Drupal. A messy install is a neat scapegoat but I spent 8-9 hours trying to chase down a phantom. I'd answer here but it has nothing to do with Drupal - it was a config problem coupled with mysql_real_escape_string(). MEH. – chucksmash Jan 16 '13 at 2:28
  • It happens to the best of us. Let me throw out a suggestion, though – the form API is actually not a crazy thing to wrap your head around. It has some advanced functionality (like #ajax) that can make it more complex, but Drupal's form elements + form_validate() and form_submit() handlers make forms easy, secure, and – gosh I'll say it – downright fun to build. Here's a simple example: drupal.org/node/717740 – Charlie Schliesser Jan 28 '13 at 17:28

To tackle your exact question, let me first tell you that what happens in the form is the correct thing.

When you submit the form, it takes data, validates it and calls appropriate submit handlers to take care if the rest. The form, once its routing is completed, does a 302 redirect to the same location so a browser F5 hit does not resubmit data. It's a general practice to avoid double submissions.

You will need to make a module that alters the form using hook_form_alter and alter the form.

You can change form's action URL to the other PHP file or add an extra submit handler that posts data to the other raw php file using drupal_http_request.

You will find sanitized and structures data in $form_state['values'] (second param of a submit handler is usually called $form_state). $_POST is also available at this stage.


This wasn't a Drupal problem at all.

My problem was that I was getting an empty $_POST array when I tried to process a naive HTML form with naive PHP. I was blaming this on Drupal because I'm unfamiliar with it but know enough about it to know that it changes the way $_SESSION variables are to be handled (as arrays) and that we are on a pretty non-standard setup (as mentioned in the question).

The actual cause of the problem was something else entirely. It was a series of warnings in my Apache error logs that gave it away.

Part of what I was doing to sanitize the input from users was to use mysql_real_escape_string() on input. I didn't realize that this actually required an active connection to a mysql db. What was happening was that the Apache user under whom the php was executed did not have valid credentials to the db so the function was returning FALSE when it was unable to connect.

Remedying this situation caused $_POST to work as expected. It also explains why I couldn't find any documentation on how Drupal breaks $_POST: it doesn't break it.

This answer isn't strictly related to Drupal but I've decided to include it after all so that any poor schmuck who finds himself going down the same dead end I was following can save himself a few hours of googling.

Further, mysql_real_escape_string is deprecated as of PHP 5.5.0 so you (I) should probably be doing this better anyway. And use Drupal's provided form API instead of rolling your own.

Not the answer you're looking for? Browse other questions tagged or ask your own question.