2

I have written a custom plugin (that creates a custom post type) and allows any user to submit a new post from a form on my website. To prevent bots, I have setup an e-mail confirmation code which they must click, where this changes the post status from Draft to Published.

Unfortunately the wp_mail() code shown below seems to be executing this confirmation URL automatically. As soon as the post is submitted, it is set to Draft until it reaches this code, and then it automatically publishes.

Removing this block makes everything work as expected. Does anyone have any idea as to the reason and how to fix it?

$confirm_url = site_url(). '/verification?id=' . $post_id . '&hash=' . $hash;

// Send a verification e-mail to the user to confirm publication
$subject = 'Please confirm your Slicer Profile submission';
$body = $confirm_url;
wp_mail( $profile_email, $subject, $body );
  • It is not clear at all what does "executed" means, and whether it has anything to do with wordpress. – Mark Kaplun Mar 26 '18 at 4:56
  • Sorry for the confusion. When the link stored in $confirm_url is ran (i.e. /verification?id=1234&hash=abc123xyzd) it changes the post status from Draft to Publish. This is not supposed to happen until the user clicks the link in their e-mail, but this code block is making that happen automatically. As in, when this wp_mail code block is there, it publishes immediately. – Aidan Knight Mar 26 '18 at 5:03
  • I updated the explanation in my original post to make it more clear. – Aidan Knight Mar 26 '18 at 5:09
  • will phrase what I meant differently. How do you know that your code puts it in a draft in the first place, and how do you know it is not the email client that "runs" the link? – Mark Kaplun Mar 26 '18 at 5:18
  • 1
    ... you have decided what is the problem with no supporting evidance that that is actually the problem – Mark Kaplun Mar 26 '18 at 5:19
4

Please try the following, I think having a return from the site_url() function could be creating a problem with the $confirm_url variable.

That and you have an unescaped slash in your url.

$site_url = site_url();
$confirm_url = $site_url. '\/verification?id=' . $post_id . '&hash=' . $hash;

// Send a verification e-mail to the user to confirm publication
$subject = 'Please confirm your Slicer Profile submission';
$body = $confirm_url;
wp_mail( $profile_email, $subject, $body );

You might need to switch to magic-quotes too, ie:

$site_url = site_url();
$confirm_url = "{$site_url}/verification?id={$post_id}&hash={$hash}";

// Send a verification e-mail to the user to confirm publication
$subject = "Please confirm your Slicer Profile submission";
$body = $confirm_url;
wp_mail( $profile_email, $subject, $body );

The parenthesis around the variables in the double-quotes aren't necessary, but some devs find them easier to read in long strings.

  • This is actually being used in the main php file of a custom plugin. The wp_mail() and site_url() functions are working. For some reason, the url specified for $confirm_url just seems to be getting ran with that code block (i.e. they don't need to click it themselves) – Aidan Knight Mar 26 '18 at 4:51
  • Forgot to note, if I remove that block of code, everything works as expected (minus them receiving an e-mail of course). The custom post type is inserted and set to "Draft", then just waits for confirmation. So everything is good except something in that code block is executing the URL. – Aidan Knight Mar 26 '18 at 4:52
  • no no no no no. you should never guess the location of where wordpress is installed. Instead you should write a proper plugin that will process a form (or however else the info is sent) – Mark Kaplun Mar 26 '18 at 4:53
  • @MarkKaplun All of my data is coming from a form, the code block I provided is the tail end of the handler. This bit just sends the user the confirmation e-mail after inserting the post into the DB and setting the status to Draft (it's supposed to change to Published once they click that, but this block of code is automatically doing that for some reason) – Aidan Knight Mar 26 '18 at 4:56
  • I see your point @MarkKaplun but if the functionality isn't going to be distributed, what's the problem with anticipating wp-load.php being 3 folders up from where a plugin containing a non-WordPress file is located? If I'm creating a single plugin for a single private site... How is this a liability? I prefer to do things that way because then the integration-script (wether it's for an api-post, db-save, or what have you) is simpler to port over to other platforms because it's agnostic php. – admcfajn Mar 26 '18 at 5:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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