Does it give any info in addition to "error"? who is your web host ?

You can change what your users receive by editing the preferences of their user group (probably "normal users").

No, it just lists "Error" (with a red dot to the left) for each user.

My Web host is Verio.

I just changed the Notification options for Normal Users from Short to Full text. Aside from the send error, will that take care of my notification email issue?

I don't know Verio.

Do you have access to your PHP error log?
Can you ask your tech support why emails were not sent? (b2evolution uses the standard PHP mail() function).

What do you mean with "my notification email issue?"

Where would I find the PHP error log?
I opened phpMyAdmin and found the evo_email__log, but it also lists just "error" in the results field for each email message sent.

I don't think I would get very far with Verio tech support on why the messages were not sent, as they probably would say it's an issue with b2evo. (Again, it was working fine before the upgrade.)

My notification email issue is the second one I first mentioned in this topic (the "full text" problem).

The PHP error log location depends on your host. Again Verio would have the answer. Sometime syou can find it in the control panel.

If you can't find it, set $debug = 2 as explained here:
http://b2evolution.net/man/advanced-customization/debugging/debugging

Then try to make b2evolution send an email in real time (not with a scheduled task) and hope that you will see error messages display on the screen (but it's possible Verio has blocked them).

Also tell us your PHP version. It will appear in your system status screen in b2evolution.

It is very possible we have added things to the mailing process. For example we where not putting a Date header in emails before which was wrong. But it should still work. Verio is the first host I hear about which has a problem with our email sending.

I don't appear to have access to the PHP error log on my (virtual) server, so I went ahead and added the debug line to the b2evo advanced config file. Then I posted another entry on the blog (which gets sent immediately), but again it wasn't sent out (same "Error" result in the b2evo sent mail log). Unfortunately, there was no error message on screen after posting the entry.

But at least this time the full content of the post was included in the email (according to the log entries), so that was fixed, thanks.

FYI, here are the headers from the latest attempted email:

Content-Type: multipart/mixed; boundary="b2evo-d22d91de7e4f40b4c897ffa69457512e"
From: "b2evo mailer" <b2evo-noreply@zoka.com>
Return-Path: b2evo-return@zoka.com
MIME-Version: 1.0
Date: Thu, 25 Jul 2013 21:17:51 +0000
X-Mailer: b2evolution 5.0.4-stable - PHP/5.4.14
X-Remote-Addr: 173.228.38.233

For whatever reason, I did not get any error message sent to me at the Return-Path address (which I have set to forward to my main admin address).

Return-Path is for when the receiving mail server can't deliver.

In this case the problem is between PHP and the sending email sever.

$debug=2 will only help you if b2evolution is sending an email right away and not asynchronously. Does it show some (maybe green) messages at the top of the page just after posting. Please post a screenshot of those messages, so we know what b2evolution actually tries to do or not do after you make a post.

Also: "virtual server": are you saying you have a VPS with root access ?

The only green message at the top of the page just after posting is: "Post has been created."
I've attached a screenshot of the top of the page.

We have a VPS, but not with full root access.

In order to see errors, you need this!

If the sending is done asynchronously, you will never see an error message on the screen. So you want: IMMEDIATE sending.

Okay, I just looked at this setting. Sending was already set to Immediate.

Then you really need to find how to see the PHP error log on your VPS. It has to be somewhere.

It's a log file of all the PHP errors and it will include an error for each email that resulted in a red dot.

Okay, I found the error logs. Here's the latest one (script.error_log):

b2evolution error: Inconsistent state! in /usr/home/zoka/www/htdocs/blogs/inc/_core/_misc.funcs.php at line 5254 / REQUEST_URI:  /blogs/blog1.php?disp=msgform&recipient_id=1&redirect_to=http%3A%2F%2Fzoka.com%2Fblogs%2Fblog1.php%2F2011%2Fw12%2F%3Fm%3D2011%26w%3D12%26posts%3D100 / HTTP_REFERER: -
PHP Fatal error:  Out of memory (allocated 34603008) (tried to allocate 1835008 bytes) in /usr/home/zoka/www/htdocs/blogs/inc/items/model/_itemlight.class.php on line 1078
zend_mm_heap corrupted
PHP Fatal error:  Out of memory (allocated 34603008) (tried to allocate 1835008 bytes) in /usr/home/zoka/www/htdocs/blogs/inc/items/model/_itemlight.class.php on line 1078
zend_mm_heap corrupted
PHP Fatal error:  Out of memory (allocated 34603008) (tried to allocate 1835008 bytes) in /usr/home/zoka/www/htdocs/blogs/inc/items/model/_itemlight.class.php on line 1078
zend_mm_heap corrupted
b2evolution error: Inconsistent state! in /usr/home/zoka/www/htdocs/blogs/inc/_core/_misc.funcs.php at line 5254 / REQUEST_URI:  /blogs/blog1.php?disp=msgform&recipient_id=1&redirect_to=http%3A%2F%2Fwww.zoka.com%2Fblogs%2Fblog1.php%3Fdisp%3Darcdir / HTTP_REFERER: -
PHP Fatal error:  Out of memory (allocated 34340864) (tried to allocate 1835008 bytes) in /usr/home/zoka/www/htdocs/blogs/inc/items/model/_itemlight.class.php on line 1078
zend_mm_heap corrupted

And there's the previous error log:

PHP Fatal error:  Out of memory (allocated 34340864) (tried to allocate 1835008 bytes) in /usr/home/zoka/www/htdocs/blogs/inc/items/model/_item.class.php on line 1417
zend_mm_heap corrupted
PHP Fatal error:  Out of memory (allocated 34340864) (tried to allocate 1835008 bytes) in /usr/home/zoka/www/htdocs/blogs/inc/items/model/_item.class.php on line 1417
zend_mm_heap corrupted
b2evolution error: Inconsistent state! in /usr/home/zoka/www/htdocs/blogs/inc/_core/_misc.funcs.php at line 5254 / REQUEST_URI:  /blogs/blog1.php?disp=msgform&recipient_id=1&redirect_to=http%3A%2F%2Fzoka.com%2Fblogs%2Fblog1.php%2F2013%2F07%2F10%2F%3Fm%3D20130710%26posts%3D100 / HTTP_REFERER: -
sendmail: illegal option -- r
sendmail: usage: sendmail [ -t ] [ -fsender ] [ -Fname ] [ -bp ] [ -bs ] [ arg ... ]
sendmail: illegal option -- r
sendmail: usage: sendmail [ -t ] [ -fsender ] [ -Fname ] [ -bp ] [ -bs ] [ arg ... ]
sendmail: illegal option -- r
sendmail: usage: sendmail [ -t ] [ -fsender ] [ -Fname ] [ -bp ] [ -bs ] [ arg ... ]
sendmail: illegal option -- r
sendmail: usage: sendmail [ -t ] [ -fsender ] [ -Fname ] [ -bp ] [ -bs ] [ arg ... ]
sendmail: illegal option -- r
sendmail: usage: sendmail [ -t ] [ -fsender ] [ -Fname ] [ -bp ] [ -bs ] [ arg ... ]
sendmail: illegal option -- r
sendmail: usage: sendmail [ -t ] [ -fsender ] [ -Fname ] [ -bp ] [ -bs ] [ arg ... ]
sendmail: illegal option -- r
sendmail: usage: sendmail [ -t ] [ -fsender ] [ -Fname ] [ -bp ] [ -bs ] [ arg ... ]
sendmail: illegal option -- r
sendmail: usage: sendmail [ -t ] [ -fsender ] [ -Fname ] [ -bp ] [ -bs ] [ arg ... ]
PHP Deprecated:  Function ereg_replace() is deprecated in /usr/local/phpMyAdmin-2.11.10-all-languages-utf-8-only/libraries/check_user_privileges.lib.php on line 34

Ok perfect. It seems on your server sendmail does not accept the -r option. I will look into this as soon as I get back to the office.

It also seems you need to allocate more memory to PHP I your PHP.ini file.

What type of control panel do you use?
Do,you know what exact Linux distribution you use?
How did you access the error log?

Thanks.

I use a very basic control panel -- Control Panel made by Verio (version 9.1).

The home page looks like the above image.

The hosted server uses FreeBSD 6.4-RELEASE-p8.

I accessed the error logs via FTP, in the www/logs/ directory.

@fplanque wrote earlier:

Ok perfect. It seems on your server sendmail does not accept the -r option. I will look into this as soon as I get back to the office.

Have you had a chance to look at this yet? It would be great if we could get this fixed soon.
Thanks.

In /inc/_core/_misc.funcs.php around line 3242 you will find:

	// Set an additional parameter for the return path:
	if( !empty($return_path) )
	{
		$additional_parameters = '-r '.$return_path;
	}
	else
	{
		$additional_parameters = '';
	}

You can change it to

	// Set an additional parameter for the return path:
	if( false )
	{
		$additional_parameters = '-r '.$return_path;
	}
	else
	{
		$additional_parameters = '';
	}

This will disable the '-r' param which is not supported by your server, but it's not a very good solution.

You won't have a return path configured. So you should put the return path address in the "from" field.

A better solution MIGHT be to try this:

	// Set an additional parameter for the return path:
	if( !empty($return_path) )
	{
		$additional_parameters = '-f '.$return_path;
	}
	else
	{
		$additional_parameters = '';
	}

The trick here is '-f' instead of '-r'. Please let me know if this works for you.

I tried the second solution first, but mail still was not sent. However, this time I got the same error message (even though I change the '-r' parameter to '-f'):

sendmail: illegal option -- r
sendmail: usage: sendmail [ -t ] [ -fsender ] [ -Fname ] [ -bp ] [ -bs ] [ arg ... ]

Also, this time the sent mail does not appear in Dashboard > Emails > Sent (not even with a red Error flag).

If I do try the first solution, where is the "from" field for the return path address?

Lastly, I don't have user permission to edit the PHP.ini file. How much additional memory should I request from tech support?

Thanks.

Regarding memory, you want 128M for normal operations or 256M if you are processing large images (resizing, rotating, etc)

Regarding the -f this is very strange. Are you positively sure you changed the file on the server?

The "from" option is at the bottom of the email settings page.

The PHP.ini file is already set to the default of 128 MB. As you can see, my blog is very simple (without any images at all), so I would think that would be enough memory.

As for the '-f' parameter in _misc.funcs.php, I definitely changed it from '-r' (starting from line 3220):

	// Set an additional parameter for the return path:
	if( !empty($return_path) )
	{
		$additional_parameters = '-f '.$return_path;
	}
	else
	{
		$additional_parameters = '';
	}

I already have a valid address for the return path in the email settings, so I will go ahead and try your first solution (disable the '-r' parameter) now.

Okay, that did the trick. Mail is going out normally (I received my copy from the blog), and there are no errors shown in Dashboard > Emails > Sent.

Thanks very much for your help on this.

You should check that the emails you send out contain a valid "Return-Path:" header. Otherwise they will look like spam to many spam blocking robots.

Yes, the email has a valid Return-Path: header (with the address I put in the email settings).

Thanks again.

Note: in versions after 5.0.5, this will be configurable in the configuration files without needed to go into the code.

Excellent.

I'm wondering if this setting was added to the configuration files yet. I just upgraded to version 5.2.2 and I got the same sendmail error until I manually disabled the '-r' parameter in _misc.funcs.php again.

Hello @michaelz,

The sendmail parameters are set in the variable $sendmail_additional_params at the /conf/_advanced.php file. There you can get rid of the "-r" option without touching the core.

Regards!

Thanks again.

I just updated my b2evo installation to version 6.6.1. I tested it with a new blog post and the email problem is back -- email users don't get the message and on the Sent emails tab there's an error for each user for the message.

i tried the earlier fix (editing /inc/_core/_misc.funcs.php to disable the "-r" option with if( false )). but this no longer fixes the problem.

Can this still be changed in the /conf/_advanced.php file? Or is there another way to fix this now?

Thanks.

Okay, false alarm. I had put the fix in the wrong section of _misc.func.php. I corrected this and now email is working normally again.

FYI, editing the sendmail parameters in /conf/_advanced.php did not work; in fact, it made the blog inaccessible.