Dev

dev@lists.roundcube.net

1 participants
4313 discussions

CardDAV plugin
by Rosali 27 Oct '12

27 Oct '12

Hi all, I'm coding a CardDAV plugin based on https://github.com/graviox/Roundcube-CardDAV. I'd like to ask all Roundcuber's for test accounts ... - Davical - Radical ... or whatever DAV-Protocol based servers are out there. Send me details for test accounts (url/user/pass) to myroundcube at mail4us dot net. Thanks, Rosali

1 0

Re: [RCD] Plugin Repo
by Thomas Bruederli 25 Oct '12

25 Oct '12

I'm taking this to the dev list again since the conversation became more general and interesting for all. till wrote: > On Thursday, October 25, 2012 at 6:59 PM, Thomas Bruederli wrote: > >> till wrote: >>> >>> On Thursday, October 25, 2012 at 11:00 AM, Thomas Bruederli wrote: >>> >>>> Cor Bosman wrote: >>>>> One thing that i find a little disappointing about this packagist/composer combo is that it really just is a bookmark list. Users have to actually move to github or google to fetch the plugin. >>>> >>>> That's true but on the other hand it encourages people to publish their >>>> stuff on github which clearly has it's advantages. >>> >>> Hey guys – there is a major confusion! ;-) >>> >>> What you do is this: >>> >>> Use the `composer.json` file in roundcubemail (currently available in master only), and add this to repositories: >>> >>> "repositories": [{ >>> "type": "composer", >>> "url": "http://plugins.roundcube.net/" >>> }] >>> >>> Then it require — something like >>> >>> "cor/message_highlighter" >>> >>> ./composer.phar install — and it's installed. >> >> I was now playing around with the composer scripts and tried to figure out >> a proper way how Roundcube plugins can actually be installed using >> composer. Here are some issue I came across: >> >> * one has to add the plugins wished to be installed to the required section >> of the composer.json file from the local Roundcube installation. That means >> one has to alter a file which is actually distributed with Roundcube. A >> possible solution could be to ship Roundcube with a file named >> composer.json.dist which one has to copy to a local copy named >> composer.json which can then be managed through composer. > > The .dist is a good idea. >> >> * Then all the components are installed into the "vendor" directory and not >> to plugins/. I already stitched together some scripts which hook into >> composer's "post-package-install" and "post-package-uninstall" hooks and >> then create or remove a symlink to the installed packaged within the >> plugins directory of Roundcube. They could even add or remove the >> particular entry to the plugins property in config/main.inc.php. > > Another idea would be this: > > We add a `"type": "roundcube-plugin"` and a custom installer to install somewhere else. > > Then all the plugin authors need to do is set this type and require the plugin installer. > > This wouldn't require post-install-cmd for every plugin — just a simple type. Sounds good. What would it take to create such a customer installer? And how would it be shipped? >> * The required PEAR packages are also installed into "vendor" while they're >> actually shipped with Roundcube itself. I suggest to remove them entirely >> from the composer.json file and only handle plugins there. > > I would rather not check them into GIT anymore. > > If you run from a git clone, you would `./composer.phar install` first and get everything installed. That would only work for people who have PHP 5.3 with composer and who have shell access. > > Or you would download a complete release which includes all the dependencies. I guess we still have to provide that for all the users who install Roundcube through FTP on a shared hosting or whatever. > > To create such a release, we would just `composer.phar install` before we zip/tar it up? That's actually a good plan. However, it happens that Roundcube ships with modified PEAR packages which are not yet publicly available. But I guess for such cases we can put these modified libs into a separate repository which is again referenced through the composer.json.dist file. >> >> * If plugins require further components or libraries though their >> composer.json file, they'll also be installed into the local vendor >> directory but Roundcube might fail to load them. Therefore the Roundcube >> core would have to use the autoloading scripts installed by composer. >> That's something I still have to implement and test. > > if (file_exists("vendor/autoload.php")) { > require "vendor/autoload.php"; > } That's what I had in mind, yes. >> The goal was to first evaluate whether composer would be a good base for >> Roundcube's plugin repository. While it seems to be OK for publishing >> plugins, their installation seems to be a bit tricky and limited to systems >> running PHP 5.3 because of composer's requirements and heavy use of namespaces. > > In all honesty — PHP 5.3 has been out for forever. 5.2 EOL'd 2 years ago: > http://www.php.net/archive/2010.php#id2010-12-16-1 > > Even Debian has 5.3 nowadays. ;-)) > > But yeah — this would come with the requirement for 5.3. But I don't think this will be a huge issue, unless we make it one. I guess we had that conversation recently in the list and some people still objected against dropping PHP 5.2 support. ~Thomas

2 3

bug in rc 0.8.x with php 5.4.x
by Benny Pedersen 25 Oct '12

25 Oct '12

date is displayed empty rc 0.7.1 still works with php 5.4.x can others confirm ?

4 5

New look of compose and message screens
by A.L.E.C 24 Oct '12

24 Oct '12

In last few changes I improved message display screen. So, now it looks the same as the preview frame. I think this way the UI looks more clean and unified. I hope you agree with me. This also matches the look of other tasks e.g. addressbook where white color is used for the whole contact information frame/box. Because I was never happy with that how mail compose screen looks like, the idea came to make the same with compose screen. I started to work on this. See attached screenshot. The main reason of this change is a unification, but it will fix some issues on compose screen. E.g. the whole compose box will be scrollable so there will be no problems with too small screen height (even with displayed all headers and options). Opinions? -- Aleksander 'A.L.E.C' Machniak LAN Management System Developer [http://lms.org.pl] Roundcube Webmail Developer [http://roundcube.net] --------------------------------------------------- PGP: 19359DC1 @@ GG: 2275252 @@ WWW: http://alec.pl

16 27

[RFC] Plugin Repo
by till 24 Oct '12

24 Oct '12

Hey, I am working on the plugin repo – would anyone like to test with me? This is what I need: 1) Your repository to a plugin 2) The plugin must contain a composer.json file Example file (bare minimum): { "name": "yourprefix/name-of-the-plugin", "description": "What your plugin does", "license": "identifier" } http://getcomposer.org/doc/04-schema.md#license Please send some examples. :) Till

1 0

Plugin repository - with Composer?
by Thomas Bruederli 22 Oct '12

22 Oct '12

Hello folks Sadly, our attempts to set up a central repository for plugin failed so far. Till once started with the idea to install a PEAR channel and to use PEAR-style package descriptions to define dependencies but that project stuck a while ago. I'd like to ask again for volunteers to help us creating a plugin repository for Roundcube. There's a new star shining on the PHP packaging sky named Composer [1] and I was wondering if some of you already made some experiences with it. It seems like a light-weighted and easy-to-use system to define packages and dependencies including version checks. And there's the Packagist project [2] which exactly does what I have in mind as a plugin repository and which could be forked to tweaked for our needs. So if anybody is willing to create a prototype repository which could serve the Roundcube plugins, you'd make us and the entire community very happy. Any feedback in Composer vs. PEAR or general suggestions for the plugin repository are welcome! Best, Thomas [1] http://getcomposer.org [2] https://packagist.org

4 11

Embed images into message source
by Rosali 22 Oct '12

22 Oct '12

Hi all, If users embed image tags ... <img src="C:\xampp\htdocs\webmail\svn\temp/c98c8314b84edc17eca1dd4b3467f693.png" alt="" /> ... into HTML messages these images will be blocked by Roundcube and most other email clients by default (that's fine due to privacy reasons). I have coded a plugin to embed images into the email source (inspired by sendmail.inc :: rcmail_fix_emoticon_paths). So far, so good. If you take the time to check the plugin, you'll see, that I have the image source in embed_images :: message_outgoing_body :: line 134 ($content). Currently the image is save in Roundcube's temp_dir folder. I'm not happy with this step because basically this step is redundant. I have analized Roundcube's mime class (./program/lib/Mail/mime.php). The method addHTMLImage allows to add content from $content (see third param $isfile). When trying this, the image is correctly created as a message part. The problem I have at this step is, that cid url replacement results in a mess. I have played with: #1 - 4th param content id #2 - replace the image tag by an placeholder and create the tag again by <img src="cid: ... content_id ... @domain part of sender ... no sucess! Image urls results in a mess. Either I'm too dumb or there is a bug anywhere. Any advice is highly appreciated. Regards, Rosali

1 0

Bloquear remitentes
by rperaza＠ipichja.rimed.cu 17 Oct '12

17 Oct '12

¿Es posible bloquear un remitente indeseado teniendo Roundcube como servicio de correo? Porfavor, agradeceré cualquier ayuda. Gracias. Rey. --------------------------------------------------- Ya estamos en Congreso PEDAGOGIA 2013 "Encuentro por la unidad de los educadores". Palacio de Convenciones de La Habana, del 4 al 8 de febrero. Favor de consultar detalles en: www.pedagogiacuba.com Esto es un mensaje de la Red Informática del Ministerio de Educación de la República de Cuba. ---------------------------------------------------

2 1

Update 0.8.2 is out
by Thomas Bruederli 15 Oct '12

15 Oct '12

Dear Roundcube lovers With some delay, I'm happy to announce another release of the Roundcube webmail package. This service update adds some bug fixes and small improvements to the 0.8 stable series. See the trac.roundcube.net/wiki/Changelog page for details. We consider it stable and we recommend to update all existing Roundcube installation with this release. Download it from http://roundcube.net/download Best regards, Thomas

1 0

Not-so-unique filenames in $_FILES
by Robin Elfrink 10 Oct '12

10 Oct '12

Hi all, I got reports from RC users claiming their recipients got the wrong attachments, attachments belonging to other RC users. So I added some logging to plugins/filesystem_attachments/filesystem_attachments.php: <> if (!$args['path']) { $rcmail = rcmail::get_instance(); $temp_dir = $rcmail->config->get('temp_dir'); $tmp_path = tempnam($temp_dir, 'rcmAttmnt'); write_log('sendmail', sprintf('Saving attachtment for %s to %s.', $RCMAIL->user->get_username(), $tmp_path)); ... <> Here are some (anonymized) lines from logs/sendmail (notice the typo, which accidentally makes for easier grep'ing): <> [09-Oct-2012 09:11:29 +0200]: Saving attachtment for <user1> to <path>/temp/rcmAttmntP007sn. [09-Oct-2012 09:18:10 +0200]: Saving attachtment for <user2> to <path>/temp/rcmAttmntP007sn. [09-Oct-2012 09:26:33 +0200]: Saving attachtment for <user3> to <path>/temp/rcmAttmntP007sn. <> With an average of 30 attachments total for all users on this server, those filenames don't look very random to me. So I added some more logging to program/steps/mail/attachments.inc: <> if (!$err) { $attachment = array( 'path' => $filepath, 'size' => $_FILES['_attachments']['size'][$i], 'name' => $_FILES['_attachments']['name'][$i], 'mimetype' => rc_mime_content_type($filepath, $_FILES['_attachments']['name'][$i], $_FILES['_attachments']['type'][$i]), 'group' => $COMPOSE_ID, ); write_log('sendmail', sprintf('Uploaded attachtment for %s in %s.', $RCMAIL->user->get_username(), $filepath)); ... <> Which gives me duplicate filenames as well: <> [09-Oct-2012 09:16:59 +0200]: Uploaded attachtment for <user1> in <path>/tmp/phpH007sn. [09-Oct-2012 09:23:52 +0200]: Uploaded attachtment for <user2> in <path>/tmp/phpH007sn. <> So this is obviously not an RC bug, but a PHP bug. My question is: Has anyone seen this before? I cannot find a related bug on https://bugs.php.net/ Robin

3 8

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