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 Logs panel
The Logs panel is where the log files generated by Newsletter are accessible. Newsletter write information of log file following the log level setting 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 contains a secret token which 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.
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 and error when the blog cannot “call itself” reporting a curl error. This is not actually an issue since the action are activate from outside the blog, but it is an issue that need to be resolved since it compromise 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 base (if the site has enough traffic). Some providers due to rules or misconfiguration block that call. Hence the scheduler stop to work 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 to 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.
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.