Thomas Bruederli wrote:

Also it's possible that the trunk is broken and comes up with some nasty errors. If you can fix them you're welcome to submit some patches, otherwise please report them to me. Don't open tickets for errors that were obviously introduced with the changes in r1291.

I see there's no $rcmail_config['javascript_config']. It's a bug? I was using it for keep_alive setting. Can I just add keep_alive to this:

foreach (array('flag_for_deletion') as $js_config_var) $OUTPUT->set_env($js_config_var, $CONFIG[$js_config_var]);

Thomas Bruederli wrote:

A.L.E.C wrote:

...

I see there's no $rcmail_config['javascript_config']. It's a bug? I was using it for keep_alive setting. Can I just add keep_alive to this:

Right, because this is actually nothing that needs to be configured. The client script requires these settings anyway (you rather break it when you change this in config) so I removed that option and hard-coded the list in program/include/main.inc at line 468. Just add whatever config option you need in javascript there.

OK, that's right. But before to set keep_alive I was only changing configuration file. Now I must change program file. Or maybe should I add keep_alive as option for everyone?

till wrote:

...

OK, that's right. But before to set keep_alive I was only changing configuration file. Now I must change program file. Or maybe should I add keep_alive as option for everyone?

The question is - do you need to set it?

yes, I think default value is too small for me

A.L.E.C wrote:

...

I have errors when selecting Trash folder on the list:

[14-Apr-2008 08:30:30] PHP Warning: include_once(rcube.php) [<a href='function.include-once'>function.include-once</a>]: failed to open stream: No such file or directory in /var/www/rc-beta/program/include/iniset.php on line 77

Fixed.

~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/

A.L.E.C wrote:

Another issue. When I click reply to (non-html) message, the body of new message contains "<br />" . Page source fragment:

<textarea name="_message" id="compose-body" cols="80" rows="20"><br />

<br /> <br /> On Tue, 1 Apr 2008 17:44:13 +0200, &quot;Daro&quot; &lt;daro@aaaa.pl&gt; wrote:<br /> &gt; saasfasfasf asfasfasfasf afasfafaff asfasfafasf<br /> &gt; asdasdadsd asdadasd adadasd<br /> &gt; asdadasd asdadasdasd asdadadas<br /> </textarea>

Maybe it's because html editor isn't working at all.

On Apr 12, 2008, at 9:07 AM, Thomas Bruederli wrote:

Hi everybody

I just wanted to let you know that with revision 1291 the trunk
version of RoundCube definitely dropped support for PHP 4. If you have a SVN
checkout running on a PHP 4 installation you better not do an svn up.

That brings up the question of which SVN revision to use for 1.1

When I look for comments in the SVN log commits around the 8th of
this month, I don't see anything specifically mentioning the revision
used for the 1.1 release. By date, it is probably around r1270.

If the 1.1 tarball was created from somewhere around r1270, are there
some miscellaneous fixes not in the 1.1 tarball that are worthwhile ? That is, should users stuck on PHP 4 for the near term use a svn
revision around 1270, or go all the way up to r1290 ?

I am adding the svn command below to get a specific revision here so
if someone browses this in an archive they can get a recent PHP4- specific checkout.

svn update --revision 1270 trunk

Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265

List info: http://lists.roundcube.net/dev/

On Mon, Apr 14, 2008 at 8:02 PM, chasd chasd@silveroaks.com wrote:

On Apr 12, 2008, at 9:07 AM, Thomas Bruederli wrote:

...

Hi everybody

I just wanted to let you know that with revision 1291 the trunk version of RoundCube definitely dropped support for PHP 4. If you have a SVN checkout running on a PHP 4 installation you better not do an svn up.

That brings up the question of which SVN revision to use for 1.1

When I look for comments in the SVN log commits around the 8th of this month, I don't see anything specifically mentioning the revision used for the 1.1 release. By date, it is probably around r1270.

If the 1.1 tarball was created from somewhere around r1270, are there some miscellaneous fixes not in the 1.1 tarball that are worthwhile ? That is, should users stuck on PHP 4 for the near term use a svn revision around 1270, or go all the way up to r1290 ?

I am adding the svn command below to get a specific revision here so if someone browses this in an archive they can get a recent PHP4- specific checkout.

svn update --revision 1270 trunk

Users should be encouraged to update to PHP5 before all. It's not just a marketing vehicle. After 08/08/2008 you will loose *all* support of PHP4.

Till _______________________________________________ List info: http://lists.roundcube.net/dev/

Users should be encouraged to update to PHP5 before all. It's not just a marketing vehicle.

I am not advocating prolonging the use of PHP4. However, it is not a switch that can be flipped without carefully
planning on consequences. For me, it is not only the migration of roundcube, but all of the PHP
code we host, some of which has not been touched in years.

Here, I am in the middle of many migrations, of which PHP4 to PHP5 is
one. I simply need some breathing room for a few weeks to be able to
properly test and manage our migration. I do not want to pull in a svn update that is not compatible with my
_current_ environment, even though I am working to migrate that
environment to PHP5.

You may chid me for waiting so long, yes. However I have not been able to properly convince those that pay me
how important this migration is. I keep getting TODO items added to my list _above_ the PHP version
migration.

We still have machines running Windows NT 3.5.1 on Alpha, if you want
to talk about unsupported ;)

I think it would be a good idea in the future to make a svn commit
specifically labeled with the version number of a release. It was
great to see the original post in this thread so that the demarcation
line between PHP4 and PHP5 is clear. And it was clear on the SVN log.
Not so much with the 0.1.1 release.

Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265

List info: http://lists.roundcube.net/dev/

On Mon, 14 Apr 2008 15:03:24 -0500, chasd chasd@silveroaks.com wrote:

If you do a checkout of that tag, it reports you got revision 1304, which is past the r1291 PHP4 demarcation.

My SVN-foo isn't good enough to know if I should ignore that or not. It sounds to me like I'm getting newer code than the 0.1.1 release, even if I am not.

Do an "svn info" on a working copy checked out from the v0.1.1 tag, and you should see (as I do) that the "Last Changed Rev" is 1259. The "Revision" continues to track the latest revision in the project (if you do an "svn up"), but I think the tag holds the files back at the older revision. I did an "svn up" and saw the "Revision" field change, but none of my files were updated. Here's my output from "svn info":

castrovalva:/var/www/roundcube# svn info Path: . URL: https://svn.roundcube.net/tags/roundcubemail/v0.1.1 Repository Root: https://svn.roundcube.net Repository UUID: 208e9e7b-5314-0410-a742-e7e81cd9613c Revision: 1304 Node Kind: directory Schedule: normal Last Changed Author: thomasb Last Changed Rev: 1259 Last Changed Date: 2008-04-05 09:13:31 -0500 (Sat, 05 Apr 2008)

--Jeff

List info: http://lists.roundcube.net/dev/

On Mon, Apr 14, 2008 at 9:57 PM, chasd chasd@silveroaks.com wrote:

For me, it is not only the migration of roundcube, but all of the PHP code we host, some of which has not been touched in years.

Totally off-topic, but can run both PHPs (4 and 5). :-) E.g. if you do cgi's, it's easier than the module.

Till _______________________________________________ List info: http://lists.roundcube.net/dev/

Eric Stadtherr wrote:

The mce_editable attribute allows the TinyMCE JavaScript to choose which text areas to "decorate" and which to leave alone. This mechanism has changed in v3.0 of TinyMCE, which I've started looking at. If everyone is ok with HTML editing being offline for a little while in the trunk, I'll just upgrade trunk to TinyMCE 3.0 and make sure everything works.

Yes, I know that. I was trying to show that new templates class is eating some attributes. See http://trac.roundcube.net/ticket/1484862