Dev October 2012

dev@lists.roundcube.net

24 participants
21 discussions

Release 0.8 (stable) with new skin is out
by Thomas Bruederli 27 Nov '12

27 Nov '12

Hello folks, We're proud to finally announce the release of version 0.8 with the brand new skin, codename "Larry", becoming the new default UI for Roundcube. After two preview releases and a lot of fine-tuning, the new design by http://bueroflint.com has now grown up. But to all the nostalgics out there: don't worry! The old skin still remains part of the package and will be maintained for at least one more major release. Beside the new UI, this version also contains more bugfixes and mprovements (see ) as well as some code refactorings. Another major change since the last stable release is the updated license which is now GPL v3+ with exceptions for skin & plugins. Read more about that on http://roundcube.net/license After lots of testing and collecting your feedback, this version is considered stable and we recommend to update all productive installations of Roundcube. Get the new version from http://roundcube.net/download Finally, some important notes for sysadmins to deploy the new Roundcube: * The new skin brings an entirely new look to the webmail application. Please carefully plan a roll-out of the new version and prepare your users accordingly. * We're getting a lot of support requests from users who are under the impression that Roundcube is a public service such as Gmail or Hotmail. Unfortunately we cannot help these people and thus we'd like to encourage everybody to do some branding on your Roundcube installation. You can replace the logo by config (option 'skin_logo') and even more important: the new release now has an option named 'support_url' where everyone should fill in an URL to instructions how to get help for that specific installation of Roundcube. And last but not least: our recent partnership with the Kolab Groupware project is finally showing some results. The Kolab team just published a preview release of their all-new Kolab 3.0 groupware suite including Roundcube as the new web client. Enriched with nice new plugins, Roundcube gives easy access to all relevant groupware functions. Read more about Kolab at http://kolab.org/blog/grote/2012/08/07/alpha-kolab-3.0-and-roundcube-0.8-re… That's definitely worth celebrating, cheers! Thomas

11 48

keep-alive changes
by A.L.E.C 12 Nov '12

12 Nov '12

Digging into session issues I've found this keep-alive thing a little bit overcomplicated and unclear. The keep-alive setting handles two things: session keeping and new-mail checking. Some plugins also bind to keep-alive to do some recurring actions (e.g. to display calendar alarms, etc.). I think we should split these functionalities. So keep-alive action should be used only for session keeping. In such case we need to execute keep-alive action only after some inactivity time (e.g. session_lifetime - 1min [or 5%]). It means timer should be resetted on every reequest. Also it means we don't need a separate config option, because the interval would be calculated from session_lifetime. For session_lifetime=0 there would be no keep-alive requests. Another thing is recurring check for new-mail. This would work as is, but... see below. Last but not least. We should provide some "global" recurring action which would work across all tasks so, plugins could bind to it. One "global" action to minimize session race-conditions when few plugins will create their own recurring requests on the same time. In mail task we could "bind" our check-recent action to this global action. In my opinion this would be a much clearer solution and would give as some additional possibilities: - possibility to disable recurring checks (for new mail etc.) at all, - better overall performance because keep-alive out of mail task will be executed less frequently I think also, we could rename keep_alive option description ("Check for new messages on") into something like "Update system state (check for new mail, etc.) on", and move it to User Interface section, so we could use it as our global action interval. ps. I'm not sure we should change draft auto-save interval in any way to fit into this. For simplicity would be nice to use the same global action and its interval. -- 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

3 8

adding topline to template_container hook
by Sébastien BLAISOT 11 Nov '12

11 Nov '12

Hi folks, Larry skin introduced topline (the line on top of screen showing About and support link on the left and username and logout link on the right). I want to make a plugin to add/change some information on that line without making a new skin. (first need is to add last login information) template_container hook seems to be just fine for that but unfortunately, this container doesn't exist in that call. Could it be possible to add that container to this hook ? Actually, I'm playing with template_object_username to change this part of the topline because it is not called anywhere else in larry skin, but I think this can broke other plugins or skins. regards, -- Sébastien BLAISOT

3 6

package.xml
by Cor Bosman 29 Oct '12

29 Oct '12

hey all, just wondering how people are creating the package.xml. Is there a method to auto-create it from source dir? Cor

3 2

PDO-based DB layer
by A.L.E.C 28 Oct '12

28 Oct '12

I've finished the new DB layer for Roundcube based on PHP PDO. It uses less memory (1.2 MB less) and should be faster than our old solution. The main differences: uses PDO modules, no prepared statements. Please, get 'pdo' branch and give it a try, so we could use this in 0.9. -- 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

4 5

CAUTION: MDB2 update breaks roundcube
by Reindl Harald 28 Oct '12

28 Oct '12

https://pear.php.net/bugs/bug.php?id=19677 -Status: Feedback +Status: Bogus The version of Roundcube does matter. The 0.8.2 release was improperly using the isError() method. There are two $this->db_handle->isError() calls in ./program/include/rcube_mdb2.php. That has been removed in master. Please open a ticket with Roundcube to get them to change the calls to MDB2::isError().

1 0

ServerError with php 5.4.8 rc 0.8.2
by Aleksandar Lazic 27 Oct '12

27 Oct '12

Hi, today I had some Server Errors. PHP: 5.4.8 Server API: FPM/FastCGI Build: './configure' '--prefix=/home/phpapps/installed/php5.4' '--enable-fpm' '--with-fpm-user=phpapps' '--with-fpm-group=phpapps' '--with-openssl' '--with-zlib' '--with-gd' '--enable-exif' '--with-jpeg-dir' '--with-png-dir' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with-pdo-mysql=mysqlnd' '--with-iconv-dir' '--enable-mbstring' '--enable-intl' '--with-mcrypt' '--with-imap' '--with-imap-ssl' '--with-kerberos' '--with-pspell' '--enable-ftp' '--with-freetype-dir' '--enable-zip' '--with-bz2' '--with-curl' '--enable-soap' '--with-tidy' xdebug trace http://download.none.at/php-5.4.8_rc-0.8.2_02.txt What could this be? Best regards Aleks

4 9

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Dev October 2012