E-mails not being sent automatically
-
Hello there,
The e-mails are not being sent automatically.
Also, there are some e-mails that i force them to send and they keep appearing on the pending e-mails.Another question, is there anyway to change the sender e-mail?
Thanks in advance.
-
Hi, thanks for reaching out.
Did the feature stop working or has never worked before?
Did you try sending a test email from the menu?
What WordPress version have you got and are you able to visualize cron events on your installation?Hi,
The feature never worked before. I’m on the latest WordPress version and the test email is working fine. I can see the cron jobs on my installation. At the moment, the only cron running on the server is the wp-cron.php
Thanks
Yes but I was referring to wp_crons. There should be an event called ‘in_stock_email_event’.
To visualize wp_crons get this awesome super light plugin
hereCan you provide some example of emails that are not being sent? That could help a lot troubleshooting. For privacy you can email them to me at [email protected] or [email protected]
Thanks
Hi Frank,
I can’t find the event you’ve called on the wp-cron.php. Here is the file content:
<?php /** * A pseudo-CRON daemon for scheduling WordPress tasks * * WP Cron is triggered when the site receives a visit. In the scenario * where a site may not receive enough visits to execute scheduled tasks * in a timely manner, this file can be called directly or via a server * CRON daemon for X number of times. * * Defining DISABLE_WP_CRON as true and calling this file directly are * mutually exclusive and the latter does not rely on the former to work. * * The HTTP request to this file will not slow down the visitor who happens to * visit when the cron job is needed to run. * * @package WordPress */ ignore_user_abort( true ); /* Don't make the request block till we finish, if possible. */ if ( function_exists( 'fastcgi_finish_request' ) && version_compare( phpversion(), '7.0.16', '>=' ) ) { if ( ! headers_sent() ) { header( 'Expires: Wed, 11 Jan 1984 05:00:00 GMT' ); header( 'Cache-Control: no-cache, must-revalidate, max-age=0' ); } fastcgi_finish_request(); } if ( ! empty( $_POST ) || defined( 'DOING_AJAX' ) || defined( 'DOING_CRON' ) ) { die(); } /** * Tell WordPress we are doing the CRON task. * * @var bool */ define( 'DOING_CRON', true ); if ( ! defined( 'ABSPATH' ) ) { /** Set up WordPress environment */ require_once __DIR__ . '/wp-load.php'; } /** * Retrieves the cron lock. * * Returns the uncached <code>doing_cron</code> transient. * * @ignore * @since 3.3.0 * * @global wpdb $wpdb WordPress database abstraction object. * * @return string|false Value of the <code>doing_cron</code> transient, 0|false otherwise. */ function _get_cron_lock() { global $wpdb; $value = 0; if ( wp_using_ext_object_cache() ) { /* * Skip local cache and force re-fetch of doing_cron transient * in case another process updated the cache. */ $value = wp_cache_get( 'doing_cron', 'transient', true ); } else { $row = $wpdb->get_row( $wpdb->prepare( "SELECT option_value FROM $wpdb->options WHERE option_name = %s LIMIT 1", '_transient_doing_cron' ) ); if ( is_object( $row ) ) { $value = $row->option_value; } } return $value; } $crons = wp_get_ready_cron_jobs(); if ( empty( $crons ) ) { die(); } $gmt_time = microtime( true ); // The cron lock: a unix timestamp from when the cron was spawned. $doing_cron_transient = get_transient( 'doing_cron' ); // Use global $doing_wp_cron lock, otherwise use the GET lock. If no lock, try to grab a new lock. if ( empty( $doing_wp_cron ) ) { if ( empty( $_GET['doing_wp_cron'] ) ) { // Called from external script/job. Try setting a lock. if ( $doing_cron_transient && ( $doing_cron_transient + WP_CRON_LOCK_TIMEOUT > $gmt_time ) ) { return; } $doing_wp_cron = sprintf( '%.22F', microtime( true ) ); $doing_cron_transient = $doing_wp_cron; set_transient( 'doing_cron', $doing_wp_cron ); } else { $doing_wp_cron = $_GET['doing_wp_cron']; } } /* * The cron lock (a unix timestamp set when the cron was spawned), * must match $doing_wp_cron (the "key"). */ if ( $doing_cron_transient !== $doing_wp_cron ) { return; } foreach ( $crons as $timestamp => $cronhooks ) { if ( $timestamp > $gmt_time ) { break; } foreach ( $cronhooks as $hook => $keys ) { foreach ( $keys as $k => $v ) { $schedule = $v['schedule']; if ( $schedule ) { wp_reschedule_event( $timestamp, $schedule, $hook, $v['args'] ); } wp_unschedule_event( $timestamp, $hook, $v['args'] ); /** * Fires scheduled events. * * @ignore * @since 2.1.0 * * @param string $hook Name of the hook that was scheduled to be fired. * @param array $args The arguments to be passed to the hook. */ do_action_ref_array( $hook, $v['args'] ); // If the hook ran too long and another cron process stole the lock, quit. if ( _get_cron_lock() !== $doing_wp_cron ) { return; } } } } if ( _get_cron_lock() === $doing_wp_cron ) { delete_transient( 'doing_cron' ); } die();
Even on the plugin you’ve told me, i don’t have any cron with the name ‘in_stock_email_event’.
Thank you,
MiguelI released an update.
Please let me know if your issue was fixed. ThanksSame problem happening to me as well. I keep seeing the same alert even after manually sending the email.
The test email is working fine.Hi Frank,
The update seems to correct some issues but it brought others, like the e-mails on the list are being sent many times to the same person.
We had a client that got really mad about it, because the inbox folder was full of e-mails of stock alert.
Thank you,
Miguel@lpaweb This plugin uses wp_mail to deliver content. I’m unable to see which errors you got because every machine/configuration is different.. and according to documentation a successful submit doesn’t mean the email is received.. I’m assuming a negative submit doesn’t mean it hasn’t.. But I’m truly sorry about the situation. I’m going to bypass it and have the plugin assume an email has been sent always to avoid this situation again. If test email works and the email is received then it is all set.
Working on the fix now.
Understood.
Thank you Frank.
@lpaweb , @ketokitchen
I just released this update that should and “may” fix the issue with pending email submission and multiple resubmission.
Please make sure that “Test Email” is successful by following the 3 steps listed on the page. Please make sure you receive the email; Please make sure to go on the “SENT EMAIL” section and verify that your email is NOW listed in there. If it is not listed in sent email but it was received then there is an issue with the database.Let me know, thanks.
@frankspress
I just installed the new update and the problem persists. The notification is still showing in the pending alerts even when I manually try to send it.
The test email is working fine. I received it in my inbox and it appeared in the sent alerts.@ketokitchen That is very strange they both use the exact same block of code. Just to confirm, when you reload the page, is the notification still in pending ?
And are you able to read the browser console for any error?@frankspress when i first click on
the button to send the email, the alert disappears from the pending. When I reload the page it appears back.
Not sure about errors in the browser console but if you specify the steps to check I could help you troubleshoot that.
thank you for your time@ketokitchen @lpaweb ,
Lastest version is 2.0.2.I fixed an issue with email validation that could cause a lookup issue on the database since it’s case sensitive. I fixed that and the plugin table will be automatically fixed when you update the plugin.
If you can,
1 mark one or two products out of stock,
2 use private browser / incognito window click notify and add an email (non registered)
3 bring product back in stockAt this point you can check and verify that the email is actually sent when you click the “SEND NOW” button, or wait till it is automatically sent.
Let me know,
Frank@frankspress It looks that for me it’s having this problem for only one customer email because I was able now to manually send the email to another customer.
- The topic ‘E-mails not being sent automatically’ is closed to new replies.