php-imap is deprecated

[rikvdh]

php-imap is now officially deprecated: https://www.php.net/manual/en/intro.imap.php

Warning: This extension is DEPRECATED and UNBUNDLED as of PHP 8.4.0.

What will this mean for the future of this library? Will we adapt to something else?

[Slamdunk]

I have no idea. Personally I use PHP from docker, with extensions compiled and loaded by https://github.com/mlocati/docker-php-extension-installer which doesn't care if it's bundled or not, and it works fine in 8.4 too

[rikvdh]

@Slamdunk it is now also deprecated, not only unbundled. If something is broken/defective/bugged it will never be fixed. Also future compatibility with php8.5+ is not guaranteed.

Also, features like XOAUTH2 will never be integrated. I've made a PR for it with php-imap a while back which started the discussion on the future of this extension.

[Slamdunk]

I already know, thank you.

I'll think about a solution if and when a problem arises.

[LeoZandvliet]

@Slamdunk
I looked up the RFC responsible for this deprecation: https://wiki.php.net/rfc/unbundle_imap_pspell_oci8
Which also mentions a possible solution:

The library that provides the functionality in this extension, c-client, is no longer updated. The last release from 2007 is no longer available on the original distributor's (University of Washington) website, but there is an unofficial GitHub repository that hasn't been updated for 5 years either (https://github.com/uw-imap/imap).

You can't also use this any more with G Suite due to authentication changes (uw-imap/imap#4).

There are several user-land packages that are still maintained, and provide superior functionality:

https://packagist.org/packages/zetacomponents/mail
https://packagist.org/packages/webklex/php-imap

The code repositories
https://github.com/zetacomponents/Mail
https://github.com/Webklex/php-imap

The last one has by far the most installs and has way more recent updates.

[8ctopus]

For those looking for a solution also check #586

[LeoZandvliet]

@8ctopus Thanks for your reply. So actually, if php-imap is installed as required by composer, this issue is actually a non-issue and can be closed?

[rikvdh]

Well, this is not related to this issue. Of course there is a way through pecl to keep installing the imap extension. But it still does not get any updates, bugfixes nor security fixes. It should be abandoned and not trusted upon for new implementations.

[8ctopus]

@LeoZandvliet It's fixable = you can use it in php 8.4/8.5 but the main issue that the extension has not been updated remains.

[philippejadin]

Longer term "solution" would be to make an adapter that would use another pure php package under the hood.
But this is a large project...

[arokettu]

I believe this package can act as a polyfill or a near-polyfill:
https://github.com/javanile/php-imap2

[fain182]

A possible answer to "what will this mean for the future of this library": the API could survive unchanged by polyfilling the imap_* functions instead of rewriting against another protocol implementation. I wrote such a polyfill, fain182/ext-imap-polyfill (I'm the author), built on webklex/php-imap, and checked it against this codebase: ddeboer/imap calls 36 distinct imap_* functions, and 35 of them are implemented. The missing one is imap_get_quotaroot, used only inside Connection::getQuota().

The polyfill replicates the real extension's behavior closely (its integration suite runs the same tests against both the polyfill and genuine ext-imap, and it reproduces error-path return values and stdClass shapes), but I haven't run this library's test suite on top of it yet. If there's interest, that seems like the right experiment: if the suite passes, ddeboer/imap works on PHP 8.4+ today with a single composer require and no code changes.

[8ctopus]

@fain182 That's great a solution, thank you.