Frequently Asked Questions (FAQ) for WP Mailster
Please review the below FAQ before contacting our support.
When you want to use WP Mailster you don’t need to browse to a website, login there, and do something to send the message there – you just use your favorite mail client.
Simply write an email to the mailing list’s address – and nothing else. In our quick start example, you would send an email to project_group2@googlemail.com – via Outlook, Thunderbird, Webmailer, or any way you like.
No, you do not need to purchase the paid WP Mailster versions every year.
There is no problem with continuing to use your “old” installations/downloads – they will continue to work. The limitations/restrictions only apply again, when you install a (free) release that was downloaded after your subscription period over your existing installation.
WP Mailster is a part of WordPress which is a PHP based web application. That means: it can not act/run without being triggered and it can not run forever when triggered. This is a technical limitation coming from PHP, not from WP Mailster or WordPress.
Triggering means that somebody accesses the site. During the page load WP Mailster is handling the jobs to do (mail retrieving/sending).
Thus mails can only be send/retrieved when somebody is browsing your site, otherwise the delivery is delayed or never done. As your site might not be browsed every few minutes 24×7 we recommend you to use a cronjob that opens the site periodically (e.g. by a command-line tool like wget).
If you cannot create a cron job we can offer you to host a job for you on a server of us (in return for a small yearly fee).
Please read the section about send errors in our troubleshooting documentation.
The mail queue shows all emails that are planned for sending. The ones that are locked (red lock symbol) are already prepared for sending.
Every outgoing email goes through this status. So there is nothing to worry about – all emails will go out at some point.
We definitely want to. But as our resources are limited all translations (except English and German) are made by volunteers.
If you are a native speaker in a language that we do not support yet and are interested in helping us please visit our translation project on WordPress.org.
The reason is that the link to the image is relative (images/banners/MailsterBannerNewsletter.jpg) and does not contain the URL (http://www….) the image has to be retrieved from. You have to make sure that the URL is included.
A potential pitfall is the WYSIWYG-editor in WordPress- some editors strip out the URL of the site ending up in a relative link. You should be able to disable this behavior in the editor’s settings.
You might get an error message like this when checking the connection settings: “Certificate failure for [server] Server name does not match certificate” or “Certificate failure for [server] unable to get local issuer certificate”.
If you use your own mailing server (with a self-signed certificate) you need to deactivate the automated certificate check to get a connection to your inbox. Do this by adding the following line in the special parameter box: /novalidate-cert
Your server needs the PHP IMAP extension installed (see system requirements), otherwise WP Mailster can not work at all. There is nothing that we can do about that, you need to contact your hoster and see whether they can enable/install the PHP IMAP extension.
If that is not possible you need to use a different hoster providing a more suitable environment.
Please note that it does not matter whether you want to use IMAP or POP3 for accessing the mailing list inbox. You need the extension in both cases, it is not specific to the IMAP protocol.
Your webhoster uses a PHP configuration (typically mod_php) that only allows a certain number of processes to be opened through a library of the PHP IMAP module. In shared environments, this can lead to the above error when WP Mailster opens the inbox throught the PHP function imap_open.
This problem is caused by the webhoster’s environment – you need to talk with your hoster whether they can solve the issue for you. If they can’t do this you are not able to execute WP Mailster in that environment.
In most situations this connection errors show up when your webhoster (where WordPress/WP Mailster is installed) is blocking outgoing connections such as connection attempts to 3rd party email servers. This is done to avoid spam sending. Please contact your hoster so they configure their firewall to allow you to send emails.
Your issue is very likely coming from a large email causing an PHP out of memory error. This is resulting from the fact that every PHP environment has a memory limit. This limit is hit when the email is tried to be retrieved from the mail server.
Please remove this email from the mailing list in question. Either through a mail webfrontend or with the “Delete first email in inbox” tool the “Tools” section in the mailing list’s settings.
In order to prevent have this happen in the future:
- Raise the PHP memory limit. Your hoster can help you with that.
- Introduce a maximum email size for WP Mailster. You can find this setting in the “List behaviour” tab of the mailing lists settings. If larger emails are in the inbox, WP Mailster will not try to process them but simply delete it and tell the sender what happened.
Notices are the least important of warnings that a PHP environment will report. According to the official PHP website, notices are generated when: “the script encountered something that could indicate an error, but could also happen in the normal course of running a script.”
We generally recommend to disable the error reporting on your WordPress Site.
Another approach is to modify PHP environment’s settings, see this article for help: How do I turn off PHP notices?. If this is beyond your level of technical comfort you should contact your hoster to help you with that.
A mailing list is a set of recipients that should all get the messages send to the mailing list’s email address.
A group is a way of organizing users. Think of it like a bucket of users. It comes in handy if you want certain users be recipients of multiple mailing lists. Then you would not add the users directly to the recipients of a mailing list, but rather add a group.
An example would be that you have three groups: Management, Project Coordinators and Developers.
If you want to run a company-wide mailing list (e.g. all@example.com) and a project mailing list (e.g. project.import@example.com) then you would add
- all three groups (Management, Project Coordinators and Developers) as recipients of the company-wide mailing list
- only the Project Coordinators and Developers groups as recipients of the project mailing list
Why all that?
In case someone joins the project team you would only add the user to the Developers group. Then the user would be automatically be a recipient of both the project and the company-wide mailing list.
The same thing applies if someone leaves: the user only needs to be removed form the groups and thus is automatically removed from the mailing lists that have this groups as the recipients.
So to sum up: if you run many lists and have many users that are largely managed by the admin, then it might be handy to organize users in groups and add the groups as the recipients.