Storing array of PHP $_POST variables as array

Question

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.

Answer 1

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.

Answer 2

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