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
action
to an empty string. While that
does sometimes work, it can sometimes also cause trouble. Set that
explicitly. I believe that an emptyaction
is 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_id
is 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.POST
is 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->query
can return both0
, no rows effected, andfalse
,
query failed. PHP will interpret0
asfalse
so you shoudlb e
checking the output withif (false !== $adoptees_delete)
and not
with the simple, and potentiallynotice
throwing, check you’ve
got. -
It is better to process the
POST
before the form thenunset
the
POST
data or, much better, redirect the request back to itself.
Otehrwise, you can get problems with multiple submissions of the
form.