Dev

dev@lists.roundcube.net

1 participants
4298 discussions

Date parsing glitch
by Eric Stadtherr 24 Oct '08

24 Oct '08

Hey all, I ran into a problem in the way RoundCube handles mail messages with "Date:" headers that aren't 100% compliant with RFC 2822's date format. The header in question is: Date: Tue, 21 Oct 2008 00:13:54 0600 Notice that the time zone offset specifier is missing the "+/-" prefix. Thunderbird seems to drop the zone offset in this case and assume it's a local date. RoundCube, on the other hand, passes it into PHP's handy "strtotime" function which interprets 0600 as the year. This leads at the very least to display problems (in the message list and the message display), and worst case to invalid dates in the database if caching is enabled. I'd like to make RoundCube a little more tolerant, so I was wondering what everyone else thought about possible solutions. The options I'm considering are: 1. Parse the date using a fixed format string (e.g. "D, d M Y H:i:s O") and one of PHP's other date functions. This would prevent misinterpretation but might be even less tolerant. 2. Analyze the string before passing to strtotime() to identify and work around known issues (of which there would be exactly one at this point). This is a single special case kind of solution, but strtotime might be reliable enough that this is the only case we'll hit. 3. Find a 3rd party RFC2822-compliant PHP date parser library. What do you all think? -- *Eric Stadtherr* estadtherr(a)gmail.com <mailto:estadtherr@gmail.com> _______________________________________________ List info: http://lists.roundcube.net/dev/

3 3

on translator logic and .po files
by Dennis P. Nikolaenko 19 Oct '08

19 Oct '08

Hello, It has been suggested to use .po files for translation. This may be a viable path, but it may introduce unneeded complexity. My real concern is about semantic changes in translatable strings. For example, if en_US 'foo' has "Do bar" as a string and then later changed to "Do baz", all other translations are left unchanged, because the online translator does not detect the change in meaning. To combat this, an original en_US string may be added as a comment after the translated string. Examle. in en_US: $labels['changecolor']='Change color'; in en_GB: $labels['changecolor']='Change colour';//Change color After 'Change color' is changed to 'Change text color', translator should offer to revise the translation in all locale files because the comment in the locale file does not match the current en_US string. -- Dennis _______________________________________________ List info: http://lists.roundcube.net/dev/

2 1

ru_RU update
by Dennis P. Nikolaenko 19 Oct '08

19 Oct '08

Hello, I have updated the Russian translation. There are some refinements. -- Dennis --- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/yW/JEtR4sh6/ru_RU.patch Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< --- _______________________________________________ List info: http://lists.roundcube.net/dev/

1 0

Handling invalid address book entries
by Ziba Scott 19 Oct '08

19 Oct '08

When editing contacts, some invalid characters are not stripped or handled in some way. They make it all the way to the sql statement before things trip up. (Using a prepare statement thankfully prevents injecting a second statement. More details in: http://trac.roundcube.net/ticket/1485504) I can work on a patch, but I'd appreciate some guidance first: Should the backend explicitly validate the input against a regular expression? What is valid/invalid? How should the interface report bad characters and/or failed contact saves to the user? Thanks, Ziba Webmaster Team University of Michigan _______________________________________________ List info: http://lists.roundcube.net/dev/

7 24

Updated Finnish translation
by Veljo Velling 18 Oct '08

18 Oct '08

Hello, filled in the blanks in Finnish/Suomi labels.inc and messages.inc Please find them in attachment. T: Veljo Velling - W - --- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/1N/OmS1pV1I/rc-finland-labels-me.zip Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< --- _______________________________________________ List info: http://lists.roundcube.net/dev/

1 0

Missing entry from Russian messages.inc
by Hans Christian Saustrup 18 Oct '08

18 Oct '08

Just found another one - I'm not attaching a whole new file, since it's only a single entry: foldermoving - Moving folder... - Перемещение папки... Cheers, HC -- Hans Christian Saustrup _______________________________________________ List info: http://lists.roundcube.net/dev/

2 1

Missing entry from Russian labels.inc
by Hans Christian Saustrup 18 Oct '08

18 Oct '08

Hi there! One entry was missing from the Russian labels.inc fil: skipdeleted - Do not show deleted messages - Не показывать удаленные сообщения Cheers, HC -- Hans Christian Saustrup _______________________________________________ List info: http://lists.roundcube.net/dev/

1 0

How to solve TinyMCE spellcheck encoding issue
by Jonathan Batista de Araujo Neto 18 Oct '08

18 Oct '08

Hello guys, When I tried to to do a spellcheck in HTML, I got a enconding problem if it has international chars, like á ç ã and so. After some search I had to change the file: program/js/tiny_mce/plugins/spellchecker/classes/GoogleSpell.php And then remove the utf8_encode line from the function getSuggestions(). That's probably because the encoding is already done or incompatible. I tried Firefox 3 and IE7 on Windows Vista. Hope it helps someone. Jonathan Araújo Administrador de Infra-estrutura de TI Gerência de TI - INDG S.A. -------------------------------------------------------------------------------- Este documento pode incluir informação confidencial e de propriedade restrita do Instituto de Desenvolvimento Gerencial-INDG e apenas pode ser lido por aquele(s) a quem sido endereçado. Se você recebeu esta mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer opiniões ou informações contidas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com as do Instituto de Desenvolvimento Gerencial-INDG. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito do Instituto de Desenvolvimento Gerencial-INDG. This document may include proprietary and confidential information of Instituto de Desenvolvimento Gerencial-INDG, and may only be read by those persons to whom it is addressed. If you have received this e-mail message in error, please notify us immediately. Any views or opinions expressed in this e-mail are those of the sender and do not necessarily coincide with those of the Instituto de Desenvolvimento Gerencial - INDG. This document may not be reproduced, copied, distributed, published, modified or furnished to third parties, without the prior written consent of Instituto de Desenvolvimento Gerencial-INDG. -------------------------------------------------------------------------------- _______________________________________________ List info: http://lists.roundcube.net/dev/

1 0

structural change proposal and LDAP issues
by Daniel Mealha Cabrita 18 Oct '08

18 Oct '08

hi there, There are some changes I find appropriate to do regarding the classes, which are stored in the include directory. The motivation is to improve the modularization _and_ to avoid flooding the include directory with dozens of small files. I've got features which use LDAP (yet structurally extensible to additional mechanisms) and I need a more basic and standard LDAP class for that. 1. - I'm currently splitting the rcube_ldap class in two: 1.1 One specific to the addressbook feature (with the very same behavior as before), with inheritance from the classe described in 1.2. 1.2 - Another one being a superclass, for generic ldap access. >From what I could understand on the philosophy of the classes used in RC, although we may have several classes in the same file, only one is supposed to be externally accessible (and it seems that the filename itself is used to determine which one). Once we start modularizing things (like allowing a different mechanism for external addressbooks, instead of only LDAP as currently it is), if we follow this logic we may end with too many files. 2. Now about what I am proposing. I'll give an example which, hopefully, will clarify what I have in mind: 2.1 - To create a new rcube_ldap.php file with a generic LDAP class only (yes, addressbook code would have to the moved to another place, or we could call the former rcube_ldap_generic.php to simplify the transition). 2.2 - A rcube_XYZ.php file providing a specific feature (addressbook, user identity etc). In that same file there are additional classes providing services according the mechanism chosen (LDAP etc). This file would have the XYZ-specific code when dealing with LDAP (through the generic LDAP class) and any other mechanism which could be added in the future. It _seems_ to me that the current philosophy expects the item 2.2 to be broken in two or more pieces, from what I see no practical benefit (and it would add lots of files once we start to support extra mechanisms). If my understanding is incorrect on this, please someone tell me so. Comments? Suggestions? -- Daniel Mealha Cabrita Divisao de Suporte Tecnico AINFO / Reitoria / UTFPR http://www.utfpr.edu.br _______________________________________________ List info: http://lists.roundcube.net/dev/

1 0

Disclaimer in html and text implemented
by Jonathan Batista de Araujo Neto 17 Oct '08

17 Oct '08

Dears, I have using roundcube 0.2 beta in production environment and works fine. I did a couple of small changes to customize for our needs, I'd like to share. Here's one. I used $rcmail_config['generic_message_footerl'] = 'disclaimer.html'; as a disclaimer but the problem is that the text only mails were with html codes. So, I modified the config to: $rcmail_config['generic_message_footer_html'] = 'disclaimer.html'; $rcmail_config['generic_message_footer_txt'] = 'disclaimer.txt'; Then I changed the file: program/steps/mail/sendmail.inc I removed the original line as: if (!$savedraft && !empty($CONFIG['generic_message_footer']) && ($footer = file_get_contents(realpath($CONFIG['generic_message_footer'])))) $message_body .= "\r\n" . rcube_charset_convert($footer, 'UTF-8', $message_charset); And added it right below: if ($isHtml) { # MOD START if (!$savedraft && !empty($CONFIG['generic_message_footer_html']) && ($footer = file_get_contents(realpath($CONFIG['generic_message_footer_html'])))) $message_body .= "\r\n" . rcube_charset_convert($footer, 'UTF-8', $message_charset); # MOD END $MAIL_MIME->setHTMLBody($message_body); // add a plain text version of the e-mail as an alternative part. $h2t = new html2text($message_body); $plainTextPart = wordwrap($h2t->get_text(), 998, "\r\n", true); if (!strlen($plainTextPart)) { // empty message body breaks attachment handling in drafts $plainTextPart = "\r\n"; } $MAIL_MIME->setTXTBody(html_entity_decode($plainTextPart, ENT_COMPAT, 'utf-8')); // look for "emoticon" images from TinyMCE and copy into message as attachments rcmail_attach_emoticons($MAIL_MIME); } else { # MOD START if (!$savedraft && !empty($CONFIG['generic_message_footer_txt']) && ($footer = file_get_contents(realpath($CONFIG['generic_message_footer_txt'])))) $message_body .= "\r\n" . rcube_charset_convert($footer, 'UTF-8', $message_charset); # MOD END Hope it helps someone. Maybe it would be usefull to be included in next release. Thanks in advnce. Jonathan Araújo Administrador de Infra-estrutura de TI Gerência de TI - INDG S.A. -------------------------------------------------------------------------------- Este documento pode incluir informação confidencial e de propriedade restrita do Instituto de Desenvolvimento Gerencial-INDG e apenas pode ser lido por aquele(s) a quem sido endereçado. Se você recebeu esta mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer opiniões ou informações contidas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com as do Instituto de Desenvolvimento Gerencial-INDG. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito do Instituto de Desenvolvimento Gerencial-INDG. This document may include proprietary and confidential information of Instituto de Desenvolvimento Gerencial-INDG, and may only be read by those persons to whom it is addressed. If you have received this e-mail message in error, please notify us immediately. Any views or opinions expressed in this e-mail are those of the sender and do not necessarily coincide with those of the Instituto de Desenvolvimento Gerencial - INDG. This document may not be reproduced, copied, distributed, published, modified or furnished to third parties, without the prior written consent of Instituto de Desenvolvimento Gerencial-INDG. -------------------------------------------------------------------------------- _______________________________________________ List info: http://lists.roundcube.net/dev/

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Dev