Dev

dev@lists.roundcube.net

1 participants
4315 discussions

Import address book in LDIF format - solved
by AVERTIS - Jan Michlik 08 Jan '13

08 Jan '13

Hello all. Please find attachment and diffs with the possibility of importing an address book in ldif format. You can import books directly from Thunderbird! The file ldiftovcard.php is litte improved. It may be useful to someone. ALEC may be able to throw it into the main branch of the program. Best regards Jan Michlik diff import.inc import.inc~orig 146,154c146,148 < < //convert ldif to vcard - Jasiu < if (end(explode('.', $_FILES['_file']['name'])) == 'ldif'){ < require_once 'ldiftovcard.php'; < $cardsprocessed = string_convert_ldif_to_vcard(file_get_contents($_FILES['_file']['tmp_name']), $vcard_file_string); < $vcards = $vcard_o->import($vcard_file_string); < }else{ < $vcards = $vcard_o->import(file_get_contents($_FILES['_file']['tmp_name'])); < } --- > > $vcards = $vcard_o->import(file_get_contents($_FILES['_file']['tmp_name'])); > diff labels.inc labels.inc~orig 301c301 < $labels['importtext'] = 'Możesz dodać kontakty z istniejącej książki adresowej.<br/>Aktualnie możliwy jest import kontaktów w formacie <a href="http://en.wikipedia.org/wiki/VCard">vCard</a> lub <a href="http://en.wikipedia.org/wiki/LDAP_Data_Interchange_Format">LDIF</a>.'; --- > $labels['importtext'] = 'Możesz dodać kontakty z istniejącej książki adresowej.<br/>Aktualnie możliwy jest import kontaktów w formacie <a href="http://en.wikipedia.org/wiki/VCard">vCard</a>.'; -- Pozdrawiam / Best regards P.H.U. "AVERTIS" Jan Michlik Os. Zamkowe 25b/19 63-500 Ostrzeszów (woj. wielkopolskie) POLAND NIP: 622-189-51-80 tel. 0 602 836 733 biuro(a)avertis.pl www.avertis.pl

2 1

PHP Fatal error: no member function pass() check.php on line 80
by Aleksandar Lazic 08 Jan '13

08 Jan '13

Hi, Today I have done a git pull After that I wanted to check my set-up. I got only Checking PHP version and the following message in the logfile. [06-Jan-2013 17:35:48 Europe/Vienna] PHP Fatal error: Call to a member function pass() on a non-object in rc08rc_git/installer/check.php on line 80 I have tried to add a new ticket into trac but I don't want to allow google to add a cookie to my browser. Best Regards Aleks

4 8

Re: [RCD] Announcing: OpenPGP finally brought to Roundcube
by ReDiculum 07 Jan '13

07 Jan '13

Hi When having Larry skin active, the lock icon is visible, but not on classic skin. Maybe you want to fix this. Additionally when the plugin is active (added to plugins array in main.inc.php), the send button does not react anymore. RC 0.8.4 on Apache 2.2.16 with PHP 5.3.3-7+squeeze14 and Suhosin.

2 1

Difference between "Checking for new messages..." (manually) and "Refreshing..." (automatically)?
by Michael Heydekamp 07 Jan '13

07 Jan '13

When I click on the button "Check for new messages", an AJAX response "Checking for new messages..." is being displayed. Under Settings/User Interface, I have set the option "Refresh (check for new messages, etc.)" to "every 1 minute(s)". When the latter function is initiated autmatically, the AJAX response reads "Refreshing...". Are both functions the same thing? Or does the latter one anything more (because of the "etc." in the description) than a manual click on the "Check for new messages" button? If they are the same thing, then I suggest to use the same AJAX response. If they are not the same - what exactly is the difference? -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany

2 2

Bug 0.9-git: Editing draft message does delete blank (and only blank?) quoted lines
by Michael Heydekamp 07 Jan '13

07 Jan '13

Say we compose a message like this: ---------------------------- This is composed text #1. > This is quoted text #1. This is composed text #2. > This is quoted text #2. > This is quoted text #3. > >> This is quoted text #4. > > This is quoted text #5. > >> This is quoted text #6. This is composed text #3. >> This is quoted text #7. >> >>> This is quoted text #8. >> >> This is quoted text #9. >> >>> This is quoted text #10. ---------------------------- Then we save it as draft and exit the message. Later on, we edit the draft. The message body is now loaded like this: ---------------------------- This is composed text #1. > This is quoted text #1. This is composed text #2. > This is quoted text #2. > This is quoted text #3. > >> This is quoted text #4. > This is quoted text #5. > >> This is quoted text #6. This is composed text #3. >> This is quoted text #7. >> >>> This is quoted text #8. >> This is quoted text #9. >> >>> This is quoted text #10. ---------------------------- Result: The (blank) quoted lines between... >> This is quoted text #4. > This is quoted text #5. ...and... >>> This is quoted text #8. >> This is quoted text #9. ...have been deleted due to some odd reason. Environment and relevant config settings: ----------------------------------------- IE8, Win7/64, "$rcmail_config['line_length'] = 76;", "$rcmail_config['send_format_flowed'] = false;" Things to be noted: ------------------- 1) All quote chars ">" have a trailing white space on all quoted lines (i.e. also on all blank quoted lines) during composing. Even if I delete those trailing blanks on all blank quoted lines during composing, they apparently get re-inserted upon saving the draft (I verified that by saving the draft message to disk and looking at it with a hex editor), so the result is the same when I edit the message again later on. 2) Draft messages are saved as "format=flowed" since Nov 19th 2012, no matter what. This is intentional and should not be re-changed again. Thomas committed this change upon my request here: https://github.com/roundcube/roundcubemail/commit/ac382e114570537e038eca79d… See also: http://trac.roundcube.net/ticket/1488799 I'm not sure if the behaviour described above is connected to this commit, at least in 0.8.4 the behaviour is the same when I load the message which has been saved as draft with 0.9-git. But I assume that this all does have to do with the format=flowed thingy in some way. I may be wrong, of course. Ticket required...? -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany

1 0

Re: [RCD] [Svn] [roundcube/roundcubemail] a5b8ef: Improve charset detection by prioritizing charset according to user language (#1485669)
by Michael Heydekamp 06 Jan '13

06 Jan '13

Is this for incoming or for outgoing messages? -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany Am 06.01.2013 13:11, schrieb GitHub: > Branch: refs/heads/master > Home: https://github.com/roundcube/roundcubemail > Commit: a5b8ef99d4e26bdb00e9b74221f107767a084a6e > > https://github.com/roundcube/roundcubemail/commit/a5b8ef99d4e26bdb00e9b7422… > Author: Aleksander Machniak <alec(a)alec.pl> > Date: 2013-01-06 (Sun, 06 Jan 2013) > > Changed paths: > M CHANGELOG > M program/lib/Roundcube/rcube.php > M program/lib/Roundcube/rcube_charset.php > M tests/Framework/Charset.php > > Log Message: > ----------- > Improve charset detection by prioritizing charset according to user > language (#1485669) > > > > > _______________________________________________ > Roundcube SVN commits mailing list > svn(a)lists.roundcube.net > http://lists.roundcube.net/mailman/listinfo/svn

2 2

Re: [RCD] [Svn] [roundcube/roundcubemail] 4fb36e: Upgrade PEAR:Mail_mime package to latest version
by Michael Heydekamp 05 Jan '13

05 Jan '13

If this commit was meant to fix the wrong encoding of the headers "Mail-Reply-To:" und "Mail-Follow-Up-To:", then I can confirm that it does indeed fix it. :) At least for "Mail-Reply-To:", I couldn't test "Mail-Follow-Up-To:" (when is the latter header BTW created at all?). Thanks and cheers, -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany Am 02.01.2013 19:16, schrieb GitHub: > Branch: refs/heads/master > Home: https://github.com/roundcube/roundcubemail > Commit: 4fb36eb1a83c334a9c9cf20fa8d1caa4c9170150 > > https://github.com/roundcube/roundcubemail/commit/4fb36eb1a83c334a9c9cf20fa… > Author: Thomas Bruederli <thomas(a)roundcube.net> > Date: 2013-01-02 (Wed, 02 Jan 2013) > > Changed paths: > M program/lib/Mail/mime.php > M program/lib/Mail/mimeDecode.php > M program/lib/Mail/mimePart.php > > Log Message: > ----------- > Upgrade PEAR:Mail_mime package to latest version > > > > > _______________________________________________ > Roundcube SVN commits mailing list > svn(a)lists.roundcube.net > http://lists.roundcube.net/mailman/listinfo/svn

1 0

Re: [RCD] [Svn] [roundcube/roundcubemail] 240ad5: Fix #countcontrols issue in IE<=8 when text is very long (#1488890)
by Michael Heydekamp 05 Jan '13

05 Jan '13

Just wanted to confirm that this fix works for me. Thanks! -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany Am 02.01.2013 20:06, schrieb GitHub: > Branch: refs/heads/master > Home: https://github.com/roundcube/roundcubemail > Commit: 240ad59dcded9b33826582fe6b9abd22dd479121 > > https://github.com/roundcube/roundcubemail/commit/240ad59dcded9b33826582fe6… > Author: Aleksander Machniak <alec(a)alec.pl> > Date: 2013-01-02 (Wed, 02 Jan 2013) > > Changed paths: > M CHANGELOG > M skins/classic/iehacks.css > > Log Message: > ----------- > Fix #countcontrols issue in IE<=8 when text is very long (#1488890) > > > > > _______________________________________________ > Roundcube SVN commits mailing list > svn(a)lists.roundcube.net > http://lists.roundcube.net/mailman/listinfo/svn

1 0

Host-based config
by Julian Matz 05 Jan '13

05 Jan '13

Hello! Like with $rcmail_config['include_host_config'], is there a similar method, currently, to load IMAP host-specific configurations. Julian

1 0

How to fix incorrect CT-declaration "text/x-mail" for .eml attachments?
by Michael Heydekamp 04 Jan '13

04 Jan '13

We're working and testing on this issue for days in the meantime, but to no avail. The issue is: Our system is returning "text/x-mail" (rather than "message/rfc822", how it would be expected) when we throw the PHP function 'finfo_open' against a valid e-mail file, which has been saved locally with Roundcube, starting with a line "Return-path:". Therefore and logically Roundcube is declaring ""text/x-mail" when attaching this .eml to an e-mail, which does prevent Roundcube from handling and rendering the attchment as an e-mail. But, ha...! You won't probably believe it, but while typing this and after days of research in the net and just looking at the .eml again, it occurs to me, that we can "solve" the problem by changing "Return-path:" to "Return-Path:" in the first line of the .eml source file. All of a sudden the .eml file is correctly detected as "message/rfc822". Arrgh!? That can't be true, really, so many lost days... Just because of this "-p" vs. "-P"?! The message that we were using for testing has apparently been composed with the Google webmailer (which does for whatever reason not set any of the several MUA headers being around, I can just assume this from other headers such as "X-Google-Sender-Auth:"). Anyway, there are still a number of questions open then: 1) Our system (Debian GNU/Linux 6.0 Squeeze) is using a compiled magic file "/usr/share/magic.mgc" with a file size of 1.830.800 Byte, which apparently supports "Return-Path:", but not "Return-path:". Is there any other magic.mgc around which does also support "Return-path:" and which is compatible with our system? This question arises because I tried to use a magic.mgc which is bundled with the Linux command 'file' 5.11 (while the original 'file' version of Squeeze is 5.04), but we get an error if we try to open it with 'finfo_open()'. Apparently this magic.mgc does also not support "Return-path:" (because it doesn't contain that string), but this experience shows that you can't use any arbitrary magic.mgc found somewhere. 2) I can find a plain (non-compiled) text file "/usr/share/mime/magic" on our system which does apparently support both "Return-Path:" and "Return-path:", but we're getting an error when trying to load it with 'finfo_open'. This is surprising in so far as we can load another plain (also non-compiled) plain text file "/etc/apache2/magic" without a problem (but which does unfortunately also not support "Return-path:", so it doesn't really help as well, unless being edited). Any idea why 'finfo_open' can load some plain text (non-compiled) magic files, but others not...? 3) The biggest of all mysteries: Where do the declaration "text/x-mail" and the description "ASCII mail text" in the case of "Return-path:" come from at all? These strings are not contained in any of the several (compiled or non-compiled) magic files. Any useful hints most appreciated! Ah, and please: Don't advise to add ".eml" to Roundcube's mimetypes.php. We're aware of that, but according to Thomas advice, this is not the right way to go. To check the difference between the result of an .eml with "Return-Path:" and with "Return-path:", just click on the following link (it may not last forever, so don't be too surprised if it should not work years later): http://srv217.dedi64.de/mime_test/mime_test.php PHP test code is attached. Thanks, cheers (and hoping for helpful hints and answers) -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany

7 18

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Dev