Hi there,
I'm having a problem to fill the "Reply-To" and "Bcc" entries under Identities in the way I need to.
Simply said, I'd just like to enter a) more than just one address , and b) to enter them in the format:
Real Name local.part@do.main Real Name local.part@do.main, Real Name local.part@do.main1
Unfortunately both scenarios don't work, as RC is complaining about an invalid address (although the address(es) and their format are perfectly valid).
Entering just two comma-separated addresses (without real names) leads to the same result.
I've managed to solve the problem partially with this quick hack in save_identity.inc:
// Validate e-mail addresses
- foreach (array('email', 'reply-to', 'bcc') as $item) {
- foreach (array('email') as $item) {
(I know that an array with just one item doesn't look very smart, but as a PHP noob and former TP developer this was the easiest way for me to do it without having to deal with syntax problems.)
Now I can at least enter multiple addresses in Reply-To and Bcc this way:
local.part@do.main, local.part@do.main1
But as soon as I add the real names in the format above, all I'm getting after clicking the Save button is:
Real Name, Real Name
Addresses are stripped entirely. Hmmm...
For the moment I'd be happy with a temporary hack that will just disable ANY address validation at these two particular places - but without breaking anything somewehere else. I wasn't able to find a way myself (especially the function rcube_idn_to_ascii is called that often recursively that I got totally lost).
I desperately need this for business purposes. TIA for any help,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On Thu, Apr 12, 2012 at 22:00, Michael Heydekamp listuser@freexp.de wrote:
Hi there,
I'm having a problem to fill the "Reply-To" and "Bcc" entries under Identities in the way I need to.
Simply said, I'd just like to enter a) more than just one address , and b) to enter them in the format:
Real Name local.part@do.main Real Name local.part@do.main, Real Name local.part@do.main1
Unfortunately both scenarios don't work, as RC is complaining about an invalid address (although the address(es) and their format are perfectly valid).
Entering just two comma-separated addresses (without real names) leads to the same result.
That certainly is a bug of Roundcube which should be corrected. I kindly ask you to open a bug ticket at trac.roundcube.net for that.
Best regards, Thomas
Am 18.04.2012 01:13, schrieb Thomas Bruederli:
On Thu, Apr 12, 2012 at 22:00, Michael Heydekamp listuser@freexp.de wrote:
Real Name local.part@do.main Real Name local.part@do.main, Real Name local.part@do.main1
Unfortunately both scenarios don't work, as RC is complaining about an invalid address (although the address(es) and their format are perfectly valid).
Entering just two comma-separated addresses (without real names) leads to the same result.
That certainly is a bug of Roundcube which should be corrected. I kindly ask you to open a bug ticket at trac.roundcube.net for that.
Done, see http://trac.roundcube.net/ticket/1488445.
But that doesn't help me in the short run (and I need help in the short run).
As I said, I've managed to solve the problem partially with this quick hack in save_identity.inc:
// Validate e-mail addresses -foreach (array('email', 'reply-to', 'bcc') as $item) {
+foreach (array('email') as $item) {
This allows me two enter two comma-separated addresses in plain address format (without real names).
But as soon as I add real names in the format...
Real Name local.part@do.main, Real Name local.part@do.main1
...the addresses get lost, and I'm just seeing "Real Name , Real Name".
I'd be happy with any private hack that just skips these two fields from any sort of validation. I have no idea which routine is stripping the adresses in such kind of string.
Any help from anybody?
Regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On Thu, Apr 19, 2012 at 00:52, Michael Heydekamp listuser@freexp.de wrote:
Am 18.04.2012 01:13, schrieb Thomas Bruederli:
On Thu, Apr 12, 2012 at 22:00, Michael Heydekamp listuser@freexp.de wrote:
Real Name local.part@do.main Real Name local.part@do.main, Real Name local.part@do.main1
Unfortunately both scenarios don't work, as RC is complaining about an invalid address (although the address(es) and their format are perfectly valid).
Entering just two comma-separated addresses (without real names) leads to the same result.
That certainly is a bug of Roundcube which should be corrected. I kindly ask you to open a bug ticket at trac.roundcube.net for that.
Done, see http://trac.roundcube.net/ticket/1488445.
But that doesn't help me in the short run (and I need help in the short run).
I think it does. The bug has just been resolved and here you can find a patch which you can apply to your Roundcube installation until the next release is out. http://trac.roundcube.net/changeset/6109
Regards, Thomas
Am 21.04.2012 18:36, schrieb Thomas Bruederli:
On Thu, Apr 19, 2012 at 00:52, Michael Heydekamp listuser@freexp.de wrote:
Done, see http://trac.roundcube.net/ticket/1488445.
But that doesn't help me in the short run (and I need help in the short run).
I think it does. The bug has just been resolved and here you can find a patch which you can apply to your Roundcube installation until the next release is out. http://trac.roundcube.net/changeset/6109
Oh! I really didn't expect such a quick resolution, thanks a lot, Thomas.
But I cant get it to work, unfortunately. All I get is a HTTP 500 error after clicking the Save button.
It wasn't clear to me if I should apply just the differences between changesets 5787 and 6109, or all changes since changeset 4829 (which is the one of 0.7.2). But I tried it both ways, with the same result.
What can/shall I do?
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Michael Heydekamp wrote:
Am 21.04.2012 18:36, schrieb Thomas Bruederli:
On Thu, Apr 19, 2012 at 00:52, Michael Heydekamp listuser@freexp.de wrote:
Done, see http://trac.roundcube.net/ticket/1488445.
But that doesn't help me in the short run (and I need help in the short run).
I think it does. The bug has just been resolved and here you can find a patch which you can apply to your Roundcube installation until the next release is out. http://trac.roundcube.net/changeset/6109
Oh! I really didn't expect such a quick resolution, thanks a lot, Thomas.
But I cant get it to work, unfortunately. All I get is a HTTP 500 error after clicking the Save button.
That appears like a PHP syntax error...
It wasn't clear to me if I should apply just the differences between changesets 5787 and 6109, or all changes since changeset 4829 (which is the one of 0.7.2). But I tried it both ways, with the same result.
We only provide patches against the latest SVN version but that one changeset 6109 should also work against 0.7.2.
What can/shall I do?
Download the patch by clicking the link "Unified Diff" at the bottom of the above mentioned changeset page. Then apply the patch to your 0.7.2 or 0.8 source of Roundcube. Executing the following command from the Roundcube document root folder should do the job:
patch -p3 < changeset_6109.diff
~Thomas
Am 23.04.2012 18:10, schrieb Thomas Bruederli:
Michael Heydekamp wrote:
Am 21.04.2012 18:36, schrieb Thomas Bruederli:
I think it does. The bug has just been resolved and here you can find a patch which you can apply to your Roundcube installation until the next release is out. http://trac.roundcube.net/changeset/6109
Oh! I really didn't expect such a quick resolution, thanks a lot, Thomas.
But I cant get it to work, unfortunately. All I get is a HTTP 500 error after clicking the Save button.
That appears like a PHP syntax error...
Exactly.
It wasn't clear to me if I should apply just the differences between changesets 5787 and 6109, or all changes since changeset 4829 (which is the one of 0.7.2). But I tried it both ways, with the same result.
We only provide patches against the latest SVN version but that one changeset 6109 should also work against 0.7.2.
What can/shall I do?
Download the patch by clicking the link "Unified Diff" at the bottom of the above mentioned changeset page. Then apply the patch to your 0.7.2 or 0.8 source of Roundcube. Executing the following command from the Roundcube document root folder should do the job:
patch -p3 < changeset_6109.diff
The result doesn't work for me. The patch itself has been applied, though:
dedi64:/var/www/webmail3# patch -p3 < changeset_6109.diff (Stripping trailing CRs from patch.) patching file program/steps/settings/save_identity.inc Hunk #1 succeeded at 23 (offset -3 lines). Hunk #2 succeeded at 40 (offset -3 lines). Hunk #3 succeeded at 57 (offset -3 lines). dedi64:/var/www/webmail3#
Result still is (right after clicking the Save button): HTTP 500
Doesn't surprise me, as a manual copy&paste leads to the same code as a patch command (well, if you know how to do copy&paste at least).
Are you probably using functions in this patch which are not available in 0.7.2?
Thanks again for the fix anyway - we'll hopefully get it working here with your help. ;-)
On Mon, Apr 23, 2012 at 23:59, Michael Heydekamp listuser@freexp.de wrote:
Am 23.04.2012 18:10, schrieb Thomas Bruederli:
Michael Heydekamp wrote:
Am 21.04.2012 18:36, schrieb Thomas Bruederli:
I think it does. The bug has just been resolved and here you can find a patch which you can apply to your Roundcube installation until the next release is out. http://trac.roundcube.net/changeset/6109
Oh! I really didn't expect such a quick resolution, thanks a lot, Thomas.
But I cant get it to work, unfortunately. All I get is a HTTP 500 error after clicking the Save button.
That appears like a PHP syntax error...
Exactly.
It wasn't clear to me if I should apply just the differences between changesets 5787 and 6109, or all changes since changeset 4829 (which is the one of 0.7.2). But I tried it both ways, with the same result.
We only provide patches against the latest SVN version but that one changeset 6109 should also work against 0.7.2.
What can/shall I do?
Download the patch by clicking the link "Unified Diff" at the bottom of the above mentioned changeset page. Then apply the patch to your 0.7.2 or 0.8 source of Roundcube. Executing the following command from the Roundcube document root folder should do the job:
patch -p3 < changeset_6109.diff
The result doesn't work for me. The patch itself has been applied, though: [...]
Result still is (right after clicking the Save button): HTTP 500
Are you probably using functions in this patch which are not available in 0.7.2?
Oops, my fault. Please replace
rcube_mime::decode_address_list(...)
with
$IMAP->decode_address_list(...)
for the 0.7 series.
~Thomas
Am 26.04.2012 11:20, schrieb Thomas Bruederli:
On Mon, Apr 23, 2012 at 23:59, Michael Heydekamp listuser@freexp.de wrote:
Result still is (right after clicking the Save button): HTTP 500
Are you probably using functions in this patch which are not available in 0.7.2?
Oops, my fault. Please replace
rcube_mime::decode_address_list(...)
with
$IMAP->decode_address_list(...)
for the 0.7 series.
Done, still HTTP 500.
Both patches (the original one and the manually fixed one) attached. Anything wrong with them?
Help appreciated...
Regards to Switzerland,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Thomas,
I've enabled some logging, and in errors.log, I'm seeing this:
33:52] PHP Warning: in_array() expects parameter 2 to be array, boolean given in /var/www/webmail3/program/steps/settings/save_identity.inc on line 46 33:52] PHP Warning: in_array() expects parameter 2 to be array, boolean given in /var/www/webmail3/program/steps/settings/save_identity.inc on line 46 33:52] PHP Warning: in_array() expects parameter 2 to be array, boolean given in /var/www/webmail3/program/steps/settings/save_identity.inc on line 46 33:52] PHP Warning: in_array() expects parameter 2 to be array, boolean given in /var/www/webmail3/program/steps/settings/save_identity.inc on line 46 33:52] PHP Warning: in_array() expects parameter 2 to be array, boolean given in /var/www/webmail3/program/steps/settings/save_identity.inc on line 46 33:52] PHP Warning: in_array() expects parameter 2 to be array, boolean given in /var/www/webmail3/program/steps/settings/save_identity.inc on line 46 33:52] PHP Fatal error: Call to a member function decode_address_list() on a non-object in /var/www/webmail3/program/steps/settings/save_identity.inc on line 77 38:41] PHP Fatal error: Call to a member function decode_address_list() on a non-object in /var/www/webmail3/program/steps/settings/save_identity.inc on line 61 39:14] PHP Fatal error: Call to a member function decode_address_list() on a non-object in /var/www/webmail3/program/steps/settings/save_identity.inc on line 61
Does that help?
Line 46:
// not included in the POST body.
Hmm, a warning to a comment line??
Line 61:
foreach ($IMAP->decode_address_list(rcube_idn_to_ascii($save_data[$item]), null, false) as $rcpt)
Line 77:
$iid = get_input_value('_iid', RCUBE_INPUT_POST);
Comments welcome,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 26.04.2012 21:50, schrieb Michael Heydekamp:
Am 26.04.2012 11:20, schrieb Thomas Bruederli:
On Mon, Apr 23, 2012 at 23:59, Michael Heydekamp listuser@freexp.de wrote:
Result still is (right after clicking the Save button): HTTP 500
Are you probably using functions in this patch which are not available in 0.7.2?
Oops, my fault. Please replace
rcube_mime::decode_address_list(...)
with
$IMAP->decode_address_list(...)
for the 0.7 series.
Done, still HTTP 500.
Both patches (the original one and the manually fixed one) attached. Anything wrong with them?
Help appreciated...
Regards to Switzerland,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On Fri, Apr 27, 2012 at 00:14, Michael Heydekamp listuser@freexp.de wrote:
Thomas,
I've enabled some logging, and in errors.log, I'm seeing this:
33:52] PHP Warning: in_array() expects parameter 2 to be array, boolean given in /var/www/webmail3/program/steps/settings/save_identity.inc on line 46 [...] 39:14] PHP Fatal error: Call to a member function decode_address_list() on a non-object in /var/www/webmail3/program/steps/settings/save_identity.inc on line 61
Does that help?
Yes, that does. Thanks!
Line 46:
// not included in the POST body.
Hmm, a warning to a comment line??
Do you maybe have APC or eAccelerator cache enabled in your PHP installation? The above error indicates that PHP doesn't read the same version of the file you're actually looking at.
~Thomas
All RC lists were down since noon last Friday...?
With regards to the issues:
Am 28.04.2012 17:35, schrieb Thomas Bruederli:
On Fri, Apr 27, 2012 at 00:14, Michael Heydekamp listuser@freexp.de wrote:
33:52] PHP Warning: in_array() expects parameter 2 to be array, boolean given in /var/www/webmail3/program/steps/settings/save_identity.inc on line 46
[...]
Line 46:
// not included in the POST body.
Hmm, a warning to a comment line??
Do you maybe have APC or eAccelerator cache enabled in your PHP installation?
Not that I would know of and I doubt it. But I'm only the "Co-Admin", being more familiar with the PC stuff since 1984 (MS-DOS 3.0) and also having been a developer of a DOS mail client written in Borland Pascal - my Linux skills are still pretty limited. I'll check with my main admin.
The above error indicates that PHP doesn't read the same version of the file you're actually looking at.
I can't replicate this PHP warning again. I just copied the file "save_identity.inc (patch r6109 against r4829 fixed)" (which I had attached to one of my previous mails) to it's original file name "save_identity.inc", and the only warning upon saving an identity that I got was this one:
[30-Apr-2012 20:32:17] PHP Fatal error: Call to a member function decode_address_list() on a non-object in /var/www/webmail3/program/steps/settings/save_identity.inc on line 61
All other errors/warnings that I posted before were probably results from testing other versions of the same file with different code. Just forget about it.
Regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 2012-04-30 21:36, Michael Heydekamp wrote:
Am 30.04.2012 22:11, schrieb Michael Heydekamp:
All RC lists were down since noon last Friday...?
And are now down again...
Mea culpa, I did something wrong at first and then did half a job repairing it.
Kind regards,
Jeroen van Meeuwen
Am 30.04.2012 22:11, schrieb Michael Heydekamp:
Am 28.04.2012 17:35, schrieb Thomas Bruederli:
Do you maybe have APC or eAccelerator cache enabled in your PHP installation?
Not that I would know of and I doubt it. [...] I'll check with my main admin.
JFTR: No, we don't.
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On Thu, Apr 26, 2012 at 21:50, Michael Heydekamp listuser@freexp.de wrote:
Am 26.04.2012 11:20, schrieb Thomas Bruederli:
On Mon, Apr 23, 2012 at 23:59, Michael Heydekamp listuser@freexp.de wrote:
Result still is (right after clicking the Save button): HTTP 500
Are you probably using functions in this patch which are not available in 0.7.2?
Oops, my fault. Please replace
rcube_mime::decode_address_list(...)
with
$IMAP->decode_address_list(...)
for the 0.7 series.
Done, still HTTP 500.
Both patches (the original one and the manually fixed one) attached. Anything wrong with them?
I again have to apologize for providing a quick but untested patch. $IMAP isn't initialized in settings actions and thus you still get errors. Please find attached a patch against the 0.7 series which is also tested and verified to work :-)
~Thomas
Am 28.04.2012 17:33, schrieb Thomas Bruederli:
On Thu, Apr 26, 2012 at 21:50, Michael Heydekamp listuser@freexp.de wrote:
Both patches (the original one and the manually fixed one) attached. Anything wrong with them?
I again have to apologize for providing a quick but untested patch. $IMAP isn't initialized in settings actions and thus you still get errors. Please find attached a patch against the 0.7 series which is also tested and verified to work :-)
And indeed - it's working now. What a relief!
And no, you don't have to apologize - providing such "private" backports of fixes/patches is not a matter of course. I have to say thanks.
Michael
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
-
Jeroen van Meeuwen (Kolab Systems) -
Michael Heydekamp -
Thomas Bruederli -
Thomas Bruederli