I see no reason why $_POST['delete'] should not be set assuming there are no page redirects involved. I can’t tell from your code if that is the case, but it superficially appears not to be. I do see other potential problems.
-
You are setting your form
actionto an empty string. While that
does sometimes work, it can sometimes also cause trouble. Set that
explicitly. I believe that an emptyactionis also invalid, at
least in HTML 5 and I think HTML 4 also. -
Depending on context you may need
global $wpdb;before you can use
$wpdb. It is safer just to include that part than to assume it is
available. - If
app_idis a numeric column type you _might be causing yourself
trouble by quoting$delete_id. -
You are passing unvalidated/unsanitized user data into the database.
That is very dangerous. As is, a user could delete rows from your
table with very little effort.POSTis not safe. At the very, very
least use$wpdb->prepare:$wpdb->query($wpdb->prepare("DELETE FROM $wpdb->rc_vol_adopt_apps WHERE app_id = %d",$delete_id));That said, I usually run my own checks to make sure the data is what it should be.
-
$wpdb->querycan return both0, no rows effected, andfalse,
query failed. PHP will interpret0asfalseso you shoudlb e
checking the output withif (false !== $adoptees_delete)and not
with the simple, and potentiallynoticethrowing, check you’ve
got. -
It is better to process the
POSTbefore the form thenunsetthe
POSTdata or, much better, redirect the request back to itself.
Otehrwise, you can get problems with multiple submissions of the
form.