0

I'm working on a WordPress process, but this seems more like a general PHP and array manipulation question with specific relevance to WordPress, in this case relating to WooCommerce.

If I have a form that may submit anywhere from 1 to around 35 entries of the same type, then to my understanding I can create it as follows. I'm using first and last names.

The form inputs, simplified, look like this:

echo '  <input type="text" name="first_name[]" id="first_name" />';
echo '  <input type="text" name="last_name[]" id="last_name" />';

In the full version of the above, lines are replicated as many time as necessary, with an iterated variable distinguishing ids sequentially from each other, and with other values pre-filled and hidden. There's a parallel version meant to post variables as hidden fields.

The post action looks like this:

if (isset($_POST) == true) {
    $att_data = array(
        'last_name'         => $_POST['last_name'],
        'first_name'        => $_POST['first_name']
    );

The WordPress function add_post_meta then ought to add $att_data to the database. It works fine as a direct "add" action without a form, or with a dummy variable in place of the $_POST[...]. Unfortunately, however, what using versions of the form/submit/$_POST gives me on my debug console is 

["last_name"]=> NULL ["first_name"]=> NULL

So, the form is submitting or at least the post action is posting and the the array is being sent, but the $_POST variables are not being captured. Why not?

ADDITIONAL: Wait a second - I'm wondering if WooCommerce clears all $_POST variables before re-directing... Am researching now.

CK MacLeod
  • 932
  • 6
  • 10
  • Have you tried dumping the full `$_POST`, just to see what it contains? – rnevius Feb 19 '15 at 15:54
  • 1
    Have you tried a `var_dump($_POST);` to see what's going on with the variable? EDIT: yeah, what @mevius said. – Jake Bathman Feb 19 '15 at 15:54
  • Unfortunately for testing purposes, the submit action re-directs to a new page, so var_dump($_POST) just gives me the post variables on the new page. Before I write a new function producing a new form in a new area outside the active form on the page in question, or, come to think of it, to stop the re-direct from occurring (it's part of the WooCommerce checkout action), I first wanted to be clear that my syntax "should" work as written. I will do that (it's a more complex operation than it sounds like) unless there's a simple way to capture the $_POST dump somewhere else, that I don't know. – CK MacLeod Feb 19 '15 at 16:13
  • a var_dump($_POST) on the page, with re-direct disabled, produces an empty Array. Am now wondering (though, I don't even know if this is reasonable), if WooCommerce flushes $_POST variables submittted by its checkout form, in which my form is "nested" (not literally "nested," since that's disallowed - my form piggybacks on WooC's "place order." – CK MacLeod Feb 19 '15 at 17:25
  • can you try `die(var_dump($_POST)`? I use that all the time. – helgatheviking Feb 19 '15 at 17:37
  • Hi helgatheviking, or Helga, if I may (you're talking to a fan of your work, and we've previously had some interesting discussion). Same result with die(var dump: Empty array. – CK MacLeod Feb 19 '15 at 17:56
  • Interestingly, I now seem to be making some progress using "get" instead of "post," AND displacing the form from within the WooCommerce checkout form to its own position (via woocommerce_before_checkout_form, which Helga will know well). For the first time, I'm adding the array variables as intended. I feel like I should throw a party, except I have a long way to go, and, if this is the only solution, I'll have to work around GET limits. It's at a very primitive stage, but if anyone wants to see it, I can direct you to the working/development version on-line. – CK MacLeod Feb 19 '15 at 19:06

2 Answers2

0

I had a similar issue recently, though not with wordpress. I used the htmlentities() and serialize() functions so it looked like this htmlentities(serialize($array)) and that worked for me.

Hope this helps

Oshane S.
  • 1
  • Thanks for your reply, but I'm not sure where you apply those two functions. When I add a line after the array define - `$att_data = htmlentities(serialize($att_data));` - it doesn't produce good results: (mostly just an odd version of the same "Null" dump. – CK MacLeod Feb 19 '15 at 16:24
  • It has to be applied before the post array data is sent. When I did it I had a 'value' attribute this exactly --> `` <-- the $list variable was an array. So if you could let me see full code for the form inputs, maybe I can see where it would work best. – Oshane S. Feb 19 '15 at 16:34
  • `echo ' ';` would be a simple version of supplying a hidden value that is repeated (to produces a sub-array of Suzys. – CK MacLeod Feb 19 '15 at 16:49
  • (Hit return too fast on prior comment: A more complicated version, using variables and values from elsewhere, looks like this: `echo ' ';` – CK MacLeod Feb 19 '15 at 16:51
  • Darn, did it again: I've tried different versions for input, and I'm not sure how the value, which is to be user-supplied, of course, would be handled. `echo ' ';` for example (The needed input on this is actually incredibly simple - which is what makes this problem so frustrating!) – CK MacLeod Feb 19 '15 at 16:56
  • I can only imagine the frustration. I think someone with more wordpress experience should assist you. – Oshane S. Feb 19 '15 at 20:08
  • As partly indicated above, I've stumbled across an alternative solution that, though less than ideal for a number of reasons, seems to be working. I'm thinking that, when I've made more progress and have the time (I'm on a deadline!), I'll share it, here providing my own "answer," which isn't really an answer (because it uses GET not POST), then raise what appears to be the underlying issue over in WordPress-land. It's possible that by then someone else will have explained why GET works here, but POST doesn't. – CK MacLeod Feb 19 '15 at 21:03
  • Ok, well glad to know you found a solution – Oshane S. Feb 20 '15 at 00:46
0

I don't have an answer to the basic question as to why $_POST does not work in this particular context (WooCommerce checkout Place Order), but I believe that my syntax was likely correct or close, since the same or virtually the same syntax worked when I substituted a "get" method for "post" in the form, changed the variables to $_GET variables, and separated the new form from the old one. Also, perhaps indicatively, $_POST did not work in the second form either, even in its new position. It was only by chance and desperation that I happened to discover that $_GET did work.

Since security is not really a concern at this point in the routine (just booking reservations names for an already logged-in user buying tickets), and since I believe that the requests will come in below the $_GET 3000-character limits, or that there will be other workarounds for the latter if necessary, I'm going to go with the $_GET solution until and unless I am able to discover (or someone just tells me!) what the problem in Woo Checkout is. That would seem to be a WordPress/WooCommerce question, not, as I originally suspected, a PHP question.

I am left with a new task that will lead me to ask a question that is also on the WordPress/PHP borderline (just like this site a lot of the time, at least for me), having to do with sorting the output based on the resultant array. I see similar questions posed all of the time, but have not yet run across this particular one being answered, but that will be the topic of another post, since I am not presently sure whether the answer will be more PHP (array sorting) or WordPress-specific. If anyone reading this thread feels like short-circuiting my current plans, either by anticipating my question or directing me to a resource that will do the job, please be my guest.

Thanks to all those who made suggestions, who at least basically confirmed that nothing on the surface was wrong with the syntax, and who provided suggestions for debugging.

CK MacLeod
  • 932
  • 6
  • 10