The “System” menu gives access to a set of information and system check really useful to understand of Newsletter (and generally your WordPress) is working and to read Newsletter logs when there is the necessity to debug bad behaviors.
- The delivery diagnostic page
- The logs page
- The Status panel
- Action call
- WordPress scheduler auto trigger call (wp-cron.php)
- PHP memory limit
- Performances and single email delivery speed
The delivery diagnostic page
This tool shows how emails are sent from your site. It shows a flow representation with the systems involved that help in finding out where a problem could lie.
The page has a test functionality you can use to send a test email: the test can report an error when it can be detected or a success message. Sometimes, even with an apparent successful delivery, the mail does not show up in the destination mailbox. It means it has been dropped in one of the steps from the site to the receiver.
You can read the “email delivery issue” where many cases are listed and explained.
For very technical debug purposes, a list of “functions” attached to the WP standard mail delivery process are listed: it’s a list of procedures from various plugins which could change the standard behavior of WP (and broke it…).
The logs page
The Logs panel is where the log files generated by Newsletter are accessible. Newsletter writes into the log files following the detail level set on the Settings page (from “none” to “debug”).
The debug level generates a lot of content and sometimes even sensitive data can be logged. Use it strictly when needed and for a short period of time. Last but not least, remember to delete the log files once done.
Log files contain a secret token in the name that is regenerated on every deletion and are rotated monthly.
The Status panel
The status panel gives you an overview of your system parameters and shows warnings when those parameters are not within the average values expected for stable and reliable mail delivery and general plugin stability.
This test has been removed since it fails with many providers (even if it should not!) but does not compromise the correct plugin functioning. In other words, the issue of Newsletter actions not being triggered cannot be detected safely with this test.
In rare cases, the URLs generated by Newsletter to perform common action (tracking, subscribe, unsubscribe, profile saving, and so on) are blocked by security plugins, server filters, URL cleaners that remove the parameters, and so on.
That test tries to understand if there are any of those blocks active. It can even report an error when the blog cannot “call itself” reporting a curl error. This is not actually an issue since the action is activated from outside the blog, but it is an issue that needs to be resolved since it compromises the correct work of the internal WordPress scheduler.
See the wp-cron.php call test below.
WordPress scheduler auto trigger call (wp-cron.php)
WordPress keeps alive its scheduler calling itself on a regular basis (if the site has enough traffic). Some providers due to rules or misconfiguration block that call. Hence the scheduler stop working and the newsletter delivery cannot be completed at the configured speed or completed at all.
Ask the provider to solve that issue if possible. Anyway, take a look at our page on how to keep the scheduler working smoothly.
PHP memory limit
Newsletter checks IF the constant
WP_MEMORY_LIMIT is set on WordPress
wp-config.php file and reports IF it is too low and should be raised. Anyway, your PHP could be configured to use a greater amount of memory and WordPress won’t decrease it, but that value is not available on the status panel since it is modified by WordPress in the admin context.
When in doubt, you can explicitly set the max memory with the constant
WP_MEMORY_LIMIT using for example
64M means 64 megabytes and should be enough. With a great number of plugins, with resource-consuming plugins (like WooCommerce) or a complex theme, you can raise it to 128M.
The typical error you have when you run out of memory is a blank page reported in the error log of your server. Your provider can eventually check it and tell you how to get the error log file.
Performances and single email delivery speed
The number of emails per hour your system can send depends on many parameters. Newsletter measures the mean time required to send a single email (in seconds) and this value helps to evaluate how many emails per hour you are theoretically able to send.
For example, if you can send 1 email per second, in 1 hour you should expect to send no more than 3600 emails. If you deliver the email without using any external service you should see very low values (but the real delivery can be delayed by your provider: a sent email is actually passed over to an underlying mailing service).
Using an external delivery service you should count on network latency: expect .2 second per email if your provider has a decent bandwidth for you.
This performance indicator can change over time, it is (usually) connected to your provider resources. Using an external delivery server can significantly change the performance. We are always working on integration extensions to external delivery services, using the latest features they provide.
If a very low speed is reported (with a warning) it means the provider is very very slow in accepting the email to be sent, the external system is slow or the connection to that system is incredibly slow. You should definitively contact the provider or accept a very low number of emails per hour.
The Scheduler page
WordPress has an internal scheduler to execute background jobs, like the future publication of a post or our newsletter delivery job.
The page shows information, pretty technical, about this scheduler giving warnings and solutions when problems are detected. You can refer to the page about the delivery speed and the cron for more information.