When I'm sending a plain text message (8bit-chars intentionally unchanged, as this might probably play a role, although unlikely in this particular case)...
xxxäxxxx xxxxx xxx xxxxx xxxäxxxxx xxxxxx xxxxx xxxxxx xxxxxxxxxx xxxxxxxxxx. xxxx xxxxx xxxxx xxxx xx xx.xx. xxxxxx xxxxxxxxxxxx, xxxx xx xxx xxxx xxxxxxxxxx xxxx xxx xxxxxxxx xxßxx, xxxxx xxx xxxxxx xxx xxxx xxx xxxxxx xxxxx xxxx xx xxxxxxx xxxxxx "xxx xxx xxx xxxxxxx".
... and forward this mail (inline) to somebody else afterwards, then it looks nicely and exactly as above in the editor. But once being sent, is does look like this in the Sent folder:
xxxäxxxx xxxxx xxx xxxxx xxxäxxxxx xxxxxx xxxxx xxxxxx xxxxxxxxxx xxxxxxxxxx. xxxx xxxxx xxxxx xxxx xx xx.xx. xxxxxx xxxxxxxxxxxx, xxxx xx xxx xxxx xxxxxxxxxx xxxx xxx xxxxxxxx xxßxx, xxxxx xxx xxxxxx xxx xxxx xxx xxxxxx xxxxx xxxx xx xxxxxxx xxxxxx "xxx xxx xxx xxxxxxx".
Have a look at lines #2 and #3... This way it has been sent, and this way the recipient will see it. We call this a "Kammtext" (or "Kammzitat", if being a quote). Outlook Express was pretty famous for that, once a while ago...
But why does Roundcube add an LF at the end of line #2 at all?
· IE8, Win7/64, "$rcmail_config['line_length'] = 76;" · "$rcmail_config['send_format_flowed'] = false;" · Plugin 'sendcharset' installed and activated, current setting "ISO-8859-1"
Hint: The last character of line #2 of the original mail is exactly at pos. #76...
But that's very well within the range of the config setting "$rcmail_config['line_length']", so no reason to do a line wrap there, right? And if there should be a reason, why doesn't it apply to the original mail then?
Ticket required?
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Ok, we're coming closer...
The message quoted below sounds ridiculous, as both texts do look exacly the same. The reason apparently is that I copied the first paragraph from the original mail being in the Sent folder, where the lines were wrapped already after pos. #76 (so each line had an LF at the end).
But upon typing, everything is flowed in the editor and therefore there are no LFs at all. So here's how the first x'ed paragraph in the quoted mail below should look like when you type it (and are using the settings described further below):
xxxäxxxx xxxxx xxx xxxxx xxxäxxxxx xxxxxx xxxxx xxxxxx xxxxxxxxxx xxxxxxxxxx. xxxx xxxxx xxxxx xxxx xx xx.xx. xxxxxx xxxxxxxxxxxx, xxxx xx xxx xxxx xxxxxxxxxx xxxx xxx xxxxxxxx xxßxx, xxxxx xxx xxxxxx xxx xxxx xxx xxxxxx xxxxx xxxx xx xxxxxxx xxxxxx "xxx xxx xxx xxxxxxx".
Now there should be no additional line wrap before pos. #76 anymore.
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 15.01.2013 00:59, Michael Heydekamp wrote:
When I'm sending a plain text message (8bit-chars intentionally unchanged, as this might probably play a role, although unlikely in this particular case)...
xxxäxxxx xxxxx xxx xxxxx xxxäxxxxx xxxxxx xxxxx xxxxxx xxxxxxxxxx xxxxxxxxxx. xxxx xxxxx xxxxx xxxx xx xx.xx. xxxxxx xxxxxxxxxxxx, xxxx xx xxx xxxx xxxxxxxxxx xxxx xxx xxxxxxxx xxßxx, xxxxx xxx xxxxxx xxx xxxx xxx xxxxxx xxxxx xxxx xx xxxxxxx xxxxxx "xxx xxx xxx xxxxxxx".
... and forward this mail (inline) to somebody else afterwards, then it looks nicely and exactly as above in the editor. But once being sent, is does look like this in the Sent folder:
xxxäxxxx xxxxx xxx xxxxx xxxäxxxxx xxxxxx xxxxx xxxxxx xxxxxxxxxx xxxxxxxxxx. xxxx xxxxx xxxxx xxxx xx xx.xx. xxxxxx xxxxxxxxxxxx, xxxx xx xxx xxxx xxxxxxxxxx xxxx xxx xxxxxxxx xxßxx, xxxxx xxx xxxxxx xxx xxxx xxx xxxxxx xxxxx xxxx xx xxxxxxx xxxxxx "xxx xxx xxx xxxxxxx".
Have a look at lines #2 and #3... This way it has been sent, and this way the recipient will see it. We call this a "Kammtext" (or "Kammzitat", if being a quote). Outlook Express was pretty famous for that, once a while ago...
But why does Roundcube add an LF at the end of line #2 at all?
Environment and relevant config settings:
· IE8, Win7/64, "$rcmail_config['line_length'] = 76;" · "$rcmail_config['send_format_flowed'] = false;" · Plugin 'sendcharset' installed and activated, current setting "ISO-8859-1"
Hint: The last character of line #2 of the original mail is exactly at pos. #76...
But that's very well within the range of the config setting "$rcmail_config['line_length']", so no reason to do a line wrap there, right? And if there should be a reason, why doesn't it apply to the original mail then?
Ticket required?
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany _______________________________________________ Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
On Tue, 15 Jan 2013 01:13:25 +0100, Michael Heydekamp listuser@freexp.de wrote:
xxxäxxxx xxxxx xxx xxxxx xxxäxxxxx xxxxxx xxxxx xxxxxx xxxxxxxxxx xxxxxxxxxx. xxxx xxxxx xxxxx xxxx xx xx.xx. xxxxxx xxxxxxxxxxxx, xxxx xx xxx xxxx xxxxxxxxxx xxxx xxx xxxxxxxx xxßxx, xxxxx xxx xxxxxx xxx xxxx xxx xxxxxx xxxxx xxxx xx xxxxxxx xxxxxx "xxx xxx xxx xxxxxxx".
FWIW, I forwarded that to myself on RC 0.5 and didn't see any wrapping of that xxx.
Am 15.01.2013 18:12, schrieb Kaz Kylheku:
On Tue, 15 Jan 2013 01:13:25 +0100, Michael Heydekamp listuser@freexp.de wrote:
xxxäxxxx xxxxx xxx xxxxx xxxäxxxxx xxxxxx xxxxx xxxxxx xxxxxxxxxx xxxxxxxxxx. xxxx xxxxx xxxxx xxxx xx xx.xx. xxxxxx xxxxxxxxxxxx, xxxx xx xxx xxxx xxxxxxxxxx xxxx xxx xxxxxxxx xxßxx, xxxxx xxx xxxxxx xxx xxxx xxx xxxxxx xxxxx xxxx xx xxxxxxx xxxxxx "xxx xxx xxx xxxxxxx".
FWIW, I forwarded that to myself on RC 0.5 and didn't see any wrapping of that xxx.
Thanks for your input, but since RC 0.5, we're just a few generations ahead in the RC development. ;)
My report was related to RC 0.9, of course.
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On Tue, Jan 15, 2013 at 1:13 AM, Michael Heydekamp listuser@freexp.de wrote:
Ok, we're coming closer...
The message quoted below sounds ridiculous, as both texts do look exacly the same. The reason apparently is that I copied the first paragraph from the original mail being in the Sent folder, where the lines were wrapped already after pos. #76 (so each line had an LF at the end).
So it wasn't a forward problem but rather copy & paste?
But upon typing, everything is flowed in the editor and therefore there are no LFs at all. So here's how the first x'ed paragraph in the quoted mail below should look like when you type it (and are using the settings described further below):
You're writing about "the editor". Did you use the HTML editor or plaintext mail composition?
However, I generally fail to understand and reproduce your problem. Could you describe exactly what you did step by step?
Regards, Thomas
Am 18.01.2013 20:29, schrieb Thomas Bruederli:
However, I generally fail to understand and reproduce your problem. Could you describe exactly what you did step by step?
I definitely will, but not tonight anymore. ;)
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 18.01.2013 20:29, schrieb Thomas Bruederli:
On Tue, Jan 15, 2013 at 1:13 AM, Michael Heydekamp listuser@freexp.de wrote:
The message quoted below sounds ridiculous, as both texts do look exacly the same. The reason apparently is that I copied the first paragraph from the original mail being in the Sent folder, where the lines were wrapped already after pos. #76 (so each line had an LF at the end).
So it wasn't a forward problem but rather copy & paste?
No. But see below.
But upon typing, everything is flowed in the editor and therefore there are no LFs at all. So here's how the first x'ed paragraph in the quoted mail below should look like when you type it (and are using the settings described further below):
You're writing about "the editor". Did you use the HTML editor or plaintext mail composition?
In my initial post of this thread, I wrote:
When I'm sending a plain text message [...]
However, I generally fail to understand and reproduce your problem. Could you describe exactly what you did step by step?
Sure. But first I'd like to suggest - no, I request - to make 'send_format_flowed' and 'line_length' user-configurable. To demonstrate the issue in this post, I had to change 'send_format_flowed' to true, which no normal user would be able to, as he hasn't access to main.inc.php.
Ok, here we go (required config settings 'send_format_flowed=false', 'line_length=76'):
xxxäxxxx xxxxx xxx xxxxx xxxäxxxxx xxxxxx xxxxx xxxxxx xxxxxxxxxx xxxxxxxxxx. xxxx xxxxx xxxxx xxxx xx xx.xx. xxxxxx xxxxxxxxxxxx, xxxx xx xxx xxxx xxxxxxxxxx xxxx xxx xxxxxxxx xxßxx, xxxxx xxx xxxxxx xxx xxxx xxx xxxxxx xxxxx xxxx xx xxxxxxx xxxxxx "xxx xxx xxx xxxxxxx".
xxxäxxxx xxxxx xxx xxxxx xxxäxxxxx xxxxxx xxxxx xxxxxx xxxxxxxxxx xxxxxxxxxx. xxxx xxxxx xxxxx xxxx xx xx.xx. xxxxxx xxxxxxxxxxxx, xxxx xx xxx xxxx xxxxxxxxxx xxxx xxx xxxxxxxx xxßxx, xxxxx xxx xxxxxx xxx xxxx xxx xxxxxx xxxxx xxxx xx xxxxxxx xxxxxx "xxx xxx xxx xxxxxxx".
Note that line #2 has exactly 76 characters! So all correct.
Step #3 - we forward the message sent in step #2 inline to somebody else. It will be loaded into the editor this way:
xxxäxxxx xxxxx xxx xxxxx xxxäxxxxx xxxxxx xxxxx xxxxxx xxxxxxxxxx xxxxxxxxxx. xxxx xxxxx xxxxx xxxx xx xx.xx. xxxxxx xxxxxxxxxxxx, xxxx xx xxx xxxx xxxxxxxxxx xxxx xxx xxxxxxxx xxßxx, xxxxx xxx xxxxxx xxx xxxx xxx xxxxxx xxxxx xxxx xx xxxxxxx xxxxxx "xxx xxx xxx xxxxxxx".
So still all correct - at least it looks so.
Step #4 - we send the forwarded message, but now it will be re-wrapped like this:
xxxäxxxx xxxxx xxx xxxxx xxxäxxxxx xxxxxx xxxxx xxxxxx xxxxxxxxxx xxxxxxxxxx. xxxx xxxxx xxxxx xxxx xx xx.xx. xxxxxx xxxxxxxxxxxx, xxxx xx xxx xxxx xxxxxxxxxx xxxx xxx xxxxxxxx xxßxx, xxxxx xxx xxxxxx xxx xxxx xxx xxxxxx xxxxx xxxx xx xxxxxxx xxxxxx "xxx xxx xxx xxxxxxx".
Look at lines #2 and #3. Now reproducable?
I believe this might be a simple counting problem: In step #2, RC is counting characters only and inserts an LF after pos. 76. In step #4, RC counts the already existing LF (which does not exist in step #2) as a character. This needs to be fixed, if my assumption should be correct. LFs shall not be counted as characters.
Reply highly appreciated.
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 01/19/2013 07:00 PM, Michael Heydekamp wrote:
I believe this might be a simple counting problem: In step #2, RC is counting characters only and inserts an LF after pos. 76. In step #4, RC counts the already existing LF (which does not exist in step #2) as a character. This needs to be fixed, if my assumption should be correct. LFs shall not be counted as characters.
Fixed in d8270b66ccca4aef0db76bade89a398b1d33abe9.
Am 18.03.2013 19:54, schrieb A.L.E.C:
On 01/19/2013 07:00 PM, Michael Heydekamp wrote:
I believe this might be a simple counting problem: In step #2, RC is counting characters only and inserts an LF after pos. 76. In step #4, RC counts the already existing LF (which does not exist in step #2) as a character. This needs to be fixed, if my assumption should be correct. LFs shall not be counted as characters.
Fixed in d8270b66ccca4aef0db76bade89a398b1d33abe9.
Hmm, thanks, but the fix doesn't look correct to me.
The test scenario that I posted doesn't now wrap the lines as before in step #2. Before the fix, the test paragraph was wrapped like this in step #2 (without the quote chars, the first line being just a help line to count the chars):
1234567890123456789012345678901234567890123456789012345678901234567890123456 xxxäxxxx xxxxx xxx xxxxx xxxäxxxxx xxxxxx xxxxx xxxxxx xxxxxxxxxx xxxxxxxxxx. xxxx xxxxx xxxxx xxxx xx xx.xx. xxxxxx xxxxxxxxxxxx, xxxx xx xxx xxxx xxxxxxxxxx xxxx xxx xxxxxxxx xxßxx, xxxxx xxx xxxxxx xxx xxxx xxx xxxxxx xxxxx xxxx xx xxxxxxx xxxxxx "xxx xxx xxx xxxxxxx".
That was correct. Now it's wrapped like this in step #2:
1234567890123456789012345678901234567890123456789012345678901234567890123456 xxxäxxxx xxxxx xxx xxxxx xxxäxxxxx xxxxxx xxxxx xxxxxx xxxxxxxxxx xxxxxxxxxx. xxxx xxxxx xxxxx xxxx xx xx.xx. xxxxxx xxxxxxxxxxxx, xxxx xx xxx xxxx xxxxxxxxxx xxxx xxx xxxxxxxx xxßxx, xxxxx xxx xxxxxx xxx xxxx xxx xxxxxx xxxxx xxxx xx xxxxxxx xxxxxx "xxx xxx xxx xxxxxxx".
That's not correct, the "real" first line is one character too long.
So something has been "fixed" in step #2, although there was nothing to fix, because everything was correct already (but isn't now correct anymore). The correct fix should take place in step #4 (forwarding a message).
Please see test scenario again.
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 03/19/2013 12:35 AM, Michael Heydekamp wrote:
So something has been "fixed" in step #2, although there was nothing to fix, because everything was correct already (but isn't now correct anymore). The correct fix should take place in step #4 (forwarding a message).
Please see test scenario again.
I went through the steps again and I'm unable to reproduce the issue. Before the fix there was an issue in step #4. What branch are you using? Do you have line_length still set to 76?
Am 19.03.2013 09:23, schrieb A.L.E.C:
On 03/19/2013 12:35 AM, Michael Heydekamp wrote:
So something has been "fixed" in step #2, although there was nothing to fix, because everything was correct already (but isn't now correct anymore). The correct fix should take place in step #4 (forwarding a message).
Please see test scenario again.
I went through the steps again
With which version?
and I'm unable to reproduce the issue. Before the fix there was an issue in step #4.
Right. But your fix changed the behaviour of line wrapping even in step #2 already, so if you are testing my scenario with a version that has this fix, you will of course see totally different results.
What branch are you using?
1.0-git (see UA-header).
Do you have line_length still set to 76?
I do, yes.
But after your fix, the line will be wrapped upon sending after pos. 77 rather than 76.
Let's see and count (I'm preceding the next line with a quote char just to prevent any wrapping of this "count line"):
34567890123456789012345678901234567890123456789012345678901234567890123456
x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x
The line above is 77 chars long. So Roundcube should wrap the last "x" to the next line upon sending, right? So it did at least before your fix. But so it didn't anymore after your fix.
I'm now going to send the message, I'm keen to see how it will be wrapped afterwards. For documentation purposes, I'm attaching a screenshot before sending.
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 19.03.2013 20:08, schrieb Michael Heydekamp:
Let's see and count (I'm preceding the next line with a quote char just to prevent any wrapping of this "count line"):
34567890123456789012345678901234567890123456789012345678901234567890123456
x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x
The line above is 77 chars long. So Roundcube should wrap the last "x" to the next line upon sending, right? So it did at least before your fix. But so it didn't anymore after your fix.
I'm now going to send the message, I'm keen to see how it will be wrapped afterwards. For documentation purposes, I'm attaching a screenshot before sending.
Uh, much to my surprise, this worked!
Now we take the original test again:
34567890123456789012345678901234567890123456789012345678901234567890123456
xxxäxxxx xxxxx xxx xxxxx xxxäxxxxx xxxxxx xxxxx xxxxxx xxxxxxxxxx xxxxxxxxxx. xxxx xxxxx xxxxx xxxx xx xx.xx. xxxxxx xxxxxxxxxxxx, xxxx xx xxx xxxx xxxxxxxxxx xxxx xxx xxxxxxxx xxßxx, xxxxx xxx xxxxxx xxx xxxx xxx xxxxxx xxxxx xxxx xx xxxxxxx xxxxxx "xxx xxx xxx xxxxxxx".
The first line should be wrapped after pos. 65 (as the next word including the dot at the end would exceed pos. 76).
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 19.03.2013 20:22, schrieb Michael Heydekamp:
Now we take the original test again:
34567890123456789012345678901234567890123456789012345678901234567890123456
xxxäxxxx xxxxx xxx xxxxx xxxäxxxxx xxxxxx xxxxx xxxxxx xxxxxxxxxx xxxxxxxxxx. xxxx xxxxx xxxxx xxxx xx xx.xx. xxxxxx xxxxxxxxxxxx, xxxx xx xxx xxxx xxxxxxxxxx xxxx xxx xxxxxxxx xxßxx, xxxxx xxx xxxxxx xxx xxxx xxx xxxxxx xxxxx xxxx xx xxxxxxx xxxxxx "xxx xxx xxx xxxxxxx".
The first line should be wrapped after pos. 65 (as the next word including the dot at the end would exceed pos. 76).
It worked again. Now I have to find out why and under wich circumstances it didn't work yesterday. :-/
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 19.03.2013 20:26, schrieb Michael Heydekamp:
It worked again. Now I have to find out why and under wich circumstances it didn't work yesterday. :-/
Stay tuned.
@alec:
After some more local tests, I must admit that even I can't reproduce the issue anymore that I encountered last night after your fix. But I swear that I had the issue, the messages are still existent here.
Furthermore I can confirm that the fix itself now seems to work as it should. Thanks again.
But strange, how can that happen...?
We are currently doing a git-pull with a cron job every night. My tests have apparently taken place at approx. the same time while the cron job was running (which I wasn't aware of). So some files may have been updated already, others not (although there were only two files affected). Or I should have done a fresh login before testing anything (which I didn't).
May this be the reason...?
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
I decided to take the plunge today and upgrade to RC 8.5.... I used the upgrade script (./bin/installto.sh <TARGET-FOLDER>) and everything went well with no errors. I also had the script update the mysql database. I can login without problems and all of my contacts and settings stayed in tact. I have a problem with the "larry skin" index page being all scrambled at the top of the inbox window where the icons are. I can see the folder and message view. I can also use the settings and address book views without a problem. I can't compose and send a message from the "larry view" I had to switch to the default skin to send this email.
Below is a snip of what is showing up in the logs/error log. Any ideas?
[21-Mar-2013 19:31:01] PHP Warning: strtotime() [<a href='function.strtotime'>function.strtotime</a>]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /var/www/roundcube/program/include/rcube_session.php on line 135 [21-Mar-2013 19:31:01] PHP Warning: array_search() expects parameter 2 to be array, null given in /var/www/roundcube/plugins/markasjunk2/markasjunk2.php on line 35 [21-Mar-2013 19:31:01] PHP Warning: date() [<a href='function.date'>function.date</a>]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /var/www/roundcube/program/include/main.inc on line 1932 [21-Mar-2013 19:31:01 -0700]: PHP Error: Deprecated hook name. address_sources -> addressbooks_list in /var/www/roundcube/program/include/rcube_plugin_api.php on line 221 (GET /webmail/?_task=mail&_action=keep-alive&_remote=1&_unlock=0&_=1363919460793) [21-Mar-2013 19:31:01] PHP Warning: date() [<a href='function.date'>function.date</a>]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /var/www/roundcube/program/include/main.inc on line 1932 [21-Mar-2013 19:31:01 -0700]: PHP Error: Deprecated hook name. get_address_book -> addressbook_get in /var/www/roundcube/program/include/rcube_plugin_api.php on line 221 (GET /webmail/?_task=mail&_action=keep-alive&_remote=1&_unlock=0&_=1363919460793) [21-Mar-2013 19:31:01] PHP Warning: date() [<a href='function.date'>function.date</a>]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /var/www/roundcube/program/include/main.inc on line 1932 [21-Mar-2013 19:31:01 -0700]: PHP Error: Deprecated hook name. user_preferences -> preferences_list in /var/www/roundcube/program/include/rcube_plugin_api.php on line 221 (GET /webmail/?_task=mail&_action=keep-alive&_remote=1&_unlock=0&_=1363919460793) [21-Mar-2013 19:31:01] PHP Warning: date() [<a href='function.date'>function.date</a>]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /var/www/roundcube/program/include/main.inc on line 1932 [21-Mar-2013 19:31:01 -0700]: PHP Error: Deprecated hook name. save_preferences -> preferences_save in /var/www/roundcube/program/include/rcube_plugin_api.php on line 221 (GET /webmail/?_task=mail&_action=keep-alive&_remote=1&_unlock=0&_=1363919460793) [21-Mar-2013 19:31:01] PHP Warning: date() [<a href='function.date'>function.date</a>]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /var/www/roundcube/program/include/main.inc on line 1932 [21-Mar-2013 19:31:01 -0700]: PHP Error: Deprecated hook name. save_contact -> contact_update in /var/www/roundcube/program/include/rcube_plugin_api.php on line 221 (GET /webmail/?_task=mail&_action=keep-alive&_remote=1&_unlock=0&_=1363919460793) [21-Mar-2013 19:31:01] PHP Warning: date() [<a href='function.date'>function.date</a>]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /var/www/roundcube/program/include/main.inc on line 1932 [21-Mar-2013 19:31:01 -0700]: PHP Error: Deprecated hook name. create_contact -> contact_create in /var/www/roundcube/program/include/rcube_plugin_api.php on line 221 (GET /webmail/?_task=mail&_action=keep-alive&_remote=1&_unlock=0&_=1363919460793) [21-Mar-2013 19:31:01] PHP Warning: date() [<a href='function.date'>function.date</a>]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /var/www/roundcube/program/include/rcube_mdb2.php on line 606
Thanks,
Javid
On 03/22/2013 03:37 AM, Javid Freeman wrote:
[21-Mar-2013 19:31:01] PHP Warning: strtotime() [<a href='function.strtotime'>function.strtotime</a>]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead
date.timezone setting in php.ini (or .htaccess file) is set to invalid value.
in /var/www/roundcube/program/include/rcube_session.php on line 135 [21-Mar-2013 19:31:01] PHP Warning: array_search() expects parameter 2 to be array, null given in /var/www/roundcube/plugins/markasjunk2/markasjunk2.php on line 35
I think you didn't upgraded (external) plugins. Disable them to make sure it's not Roundcube core issue.
[21-Mar-2013 19:31:01 -0700]: PHP Error: Deprecated hook name. address_sources -> addressbooks_list in
This is from some old plugin too.
ps. please do not create new subject by replying to an existing thread.