Question Roundcube 1.6.7 is on PHP 8.2 but, Obsidian 18.0.61 is on PHP 8.3 - Why the delay in moving Roundcube on to PHP 8.3?

[learning_curve]

Server operating system version

Ubuntu 22.04.4 LTS

Plesk version and microupdate number

18.0.61 #5

As per the thread title. Anybody using Roundcube on Obsidian (like us) are currently unable to remove PHP 8.2, purely because of the Obsidian / Roundcube dependencies.
Roundcube 1.67 supports PHP 8.3 and Obsidian is now on PHP 8.3, but currently, the Obsidian default setup, is that Roundcube 1.67 will only run on PHP 8.2. In the past, it was possible to change this default setting via this page, which, has been updated since then, but now carries errors in the text sadly. Then, the Obsidian / Roundcube setup was changed (from 18.0.55 from memory) so that ^ page became irrelevant anyway. When asked about the same back then (but with earlier PHP versions) Plesk did advise "...there are reasons why Plesk hasn't done it yet..." So eventually... Yes, the updates did take place (Roundcube moving on to PHP 8.2).
Can Plesk advise provide an ETA or maybe an Obsidian release number, when the same type of update will happen for this version of Roundcube?

 

[Kaspar@Plesk]

Unfortunately there is no ETA on when the PHP version for Roundcube will be updated to version 8.3. It's very much on the to-do list (but so are many other things). Is there any specific reason you want to use PHP 8.3 for RC?

 

[learning_curve]

Unfortunately there is no ETA on when the PHP version for Roundcube will be updated to version 8.3. It's very much on the to-do list (but so are many other things). Is there any specific reason you want to use PHP 8.3 for RC?

Understood. The mains reasons are: It's the only application / package (that we use on servers, where we use Obsidian) that still must use PHP 8.2. So by default, that means as mentioned, that it's therefore impossible to remove PHP 8.2 from said servers. It's not mission critical, so it's not a complaint
It just seems like an oversight, that having spent a lot of time and effort on ensuring that Obsidian runs on PHP 8.3, a main webmail service, gets left behind.

 

[learning_curve]

Understood. The mains reasons are: It's the only application / package (that we use on servers, where we use Obsidian) that still must use PHP 8.2. So by default, that means as mentioned, that it's therefore impossible to remove PHP 8.2 from said servers. It's not mission critical, so it's not a complaint
It just seems like an oversight, that having spent a lot of time and effort on ensuring that Obsidian runs on PHP 8.3, a main webmail service, gets left behind.

Bump (for Plesk Staff)
The original post in this thread was made when running Plesk Obsidian 18.0.61
Since then, we've had the Plesk Obsidian 18.0.62 release (and it's Point releases) and now, we have the Plesk Obsidian 18.0.63 release...
However, Plesk Obsidian supporting Rouncube c/e PHP 8.3 is still conspicuous ny its absence...

Speculative Server World:
End Users: "...Roundcube was upgraded to release 1.6.7 way back in May this year, So... Come on (Plesk) PHP 8.2, your time is up!!"
Plesk: "...The next release... honestly... trust us..."

 

[mitchellvanbijleveld]

I have a custom installation of Roundcube running on PHP8.3 and it works perfectly fine.

 

[Kaspar@Plesk]

Speculative Server World:
End Users: "...Roundcube was upgraded to release 1.6.7 way back in May this year, So... Come on (Plesk) PHP 8.2, your time is up!!"
Plesk: "...The next release... honestly... trust us..."

I am sorry if I gave impression that PHP 8.3 for RC was imminent. I always try to very cautious when it comes to feature/update expectations. Seems I failed here.

There really is no ETA on when we'll switch PHP versions. PHP 8.2 still has active support till the end of this year and security fixes till 2027. So it's still good for while. However, compatibility across all supported OSes is our main concern and focus. CentOS 7 and Ubuntu 18.04 (for which we released ELS) are still on the RC 1.4 branch for example.

 

[learning_curve]

I have a custom installation of Roundcube running on PHP8.3 and it works perfectly fine.

The advice from Plesk (in the previous threads on this subject, in this forum) was to not do this, albeit the technical reasons as to why not, were not detailed back then. Are you able to post exactly how you have invoked this change / upgradge? (i.e. including all of your current OS / Setup / All Steps To Change).
If you did, that may assist others who are caught in the Roundcube / PHP8.2 / Supporting Legacy delays and so may wish to progress independently

 

[mitchellvanbijleveld]

The advice from Plesk (in the previous threads on this subject, in this forum) was to not do this, albeit the technical reasons as to why not, were not detailed back then. Are you able to post exactly how you have invoked this change / upgradge? (i.e. including all of your current OS / Setup / All Steps To Change).
If you did, that may assist others who are caught in the Roundcube / PHP8.2 / Supporting Legacy delays and so may wish to progress independently

I am unsure if you're still interested, but with a custom installation, I meant setting up a subdomain for a specific domain where all my clients can access their webmail. I set the php handler to 8.3 and created a separate database for the user's data. I haven't even installed Roundcube through the Plesk installer since I want extra plugins enabled and settings changed, even after a Plesk upgrade.

If you need more information, please let me know but the default Roundcube installation instructions will make it easy enough.

 

[Kaspar]

[...] I haven't even installed Roundcube through the Plesk installer since I want extra plugins enabled and settings changed, even after a Plesk upgrade. [...]

Just as an FYI in case your interested, any modification you make to the config.inc.php file of the Roundcube version distributed by Plesk are retained, even after updates. I've used a customized configuration including custom plugins for about 6 years now without any issues.