starred/cypht
1
0
Fork 0
mirror of https://github.com/cypht-org/cypht.git synced 2026-04-25 04:56:03 +03:00
Code Issues 137 Projects Releases Packages Wiki Activity

[GH-ISSUE #977] What should be the minimum PHP version for Cypht 3.0? PHP 8.1? 8.2? 8.3? #524

New issue
Closed
opened 2026-02-25 21:35:15 +03:00 by kerem · 22 comments
kerem commented 2026-02-25 21:35:15 +03:00
Owner
Copy link

Originally created by @marclaporte on GitHub (Apr 26, 2024).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/977

Originally assigned to: @Shadow243 on GitHub.

Cypht 1.3.x requires PHP 5.4
https://github.com/cypht-org/cypht/blob/release-1.3.0/composer.json

Cypht 1.4.x requires PHP 5.6
https://github.com/cypht-org/cypht/blob/1.4.x/composer.json#L31

As of now, Cypht master requires PHP 7.4
https://github.com/cypht-org/cypht/blob/master/composer.json#L39

Cypht master will branch to Cypht 2.0 soon.

So then master will be the future Cypht 3.0

Related: https://doc.tiki.org/PHP-8

Originally created by @marclaporte on GitHub (Apr 26, 2024). Original GitHub issue: https://github.com/cypht-org/cypht/issues/977 Originally assigned to: @Shadow243 on GitHub. Cypht 1.3.x requires PHP 5.4 https://github.com/cypht-org/cypht/blob/release-1.3.0/composer.json Cypht 1.4.x requires PHP 5.6 https://github.com/cypht-org/cypht/blob/1.4.x/composer.json#L31 As of now, Cypht master requires PHP 7.4 https://github.com/cypht-org/cypht/blob/master/composer.json#L39 Cypht master will branch to Cypht 2.0 soon. So then master will be the future Cypht 3.0 Related: https://doc.tiki.org/PHP-8
kerem closed this issue 2026-02-25 21:35:15 +03:00
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@marclaporte commented on GitHub (May 1, 2024):

Related discussion: https://github.com/cypht-org/cypht/wiki/Lifecycle

<!-- gh-comment-id:2088585660 --> @marclaporte commented on GitHub (May 1, 2024): Related discussion: https://github.com/cypht-org/cypht/wiki/Lifecycle
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@jonocodes commented on GitHub (May 5, 2024):

What is the state of php 8.x?
Has cypht been run in 8 to see if it works or needs updating?

<!-- gh-comment-id:2094809536 --> @jonocodes commented on GitHub (May 5, 2024): What is the state of php 8.x? Has cypht been run in 8 to see if it works or needs updating?
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@marclaporte commented on GitHub (May 5, 2024):

I just officialized that Cypht 1.4.x is now an LTS version so end users don't have to rush to upgrade:
https://github.com/cypht-org/cypht/wiki/Lifecycle

<!-- gh-comment-id:2094969322 --> @marclaporte commented on GitHub (May 5, 2024): I just officialized that Cypht 1.4.x is now an LTS version so end users don't have to rush to upgrade: https://github.com/cypht-org/cypht/wiki/Lifecycle
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@marclaporte commented on GitHub (May 6, 2024):

What is the state of php 8.x?
Has cypht been run in 8 to see if it works or needs updating?

Most (maybe all) active devs use PHP 8.x so they will fix any bugs they encounter. And we have seen such commits. A risk is that they don't also make sure to maintain support for PHP 7.4, which is one more reason to ditch 7.4. Since we now have Cypht LTS, users will have security patches for a while if they prefer waiting before proceeding to a major upgrade.

<!-- gh-comment-id:2096500561 --> @marclaporte commented on GitHub (May 6, 2024): > What is the state of php 8.x? > Has cypht been run in 8 to see if it works or needs updating? Most (maybe all) active devs use PHP 8.x so they will fix any bugs they encounter. And we have seen such commits. A risk is that they don't also make sure to maintain support for PHP 7.4, which is one more reason to ditch 7.4. Since we now have Cypht LTS, users will have security patches for a while if they prefer waiting before proceeding to a major upgrade.
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@marclaporte commented on GitHub (May 6, 2024):

So then master will be the future Cypht 3.0

That was true when I wrote it, but since then, we have improved https://github.com/cypht-org/cypht/wiki/Lifecycle so we'll only do a major revision if the code changes justify it.

So now, a likely scenario is that master becomes 2.1.0 and then 2.2.0 and then 2.3.0. At this point, we'll probably be itching for bigger changes, so then master will become 3.0.

<!-- gh-comment-id:2096514596 --> @marclaporte commented on GitHub (May 6, 2024): > So then master will be the future Cypht 3.0 That was true when I wrote it, but since then, we have improved https://github.com/cypht-org/cypht/wiki/Lifecycle so we'll only do a major revision if the code changes justify it. So now, a likely scenario is that master becomes 2.1.0 and then 2.2.0 and then 2.3.0. At this point, we'll probably be itching for bigger changes, so then master will become 3.0.
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@jonocodes commented on GitHub (May 6, 2024):

I asked because I am specifically looking at some error handling, that I would presume breaks things:
https://php.watch/versions/8.0/PDO-default-errmode

Should I bring this up in another discussion or is there a place for general php 8 discussions?

<!-- gh-comment-id:2096550512 --> @jonocodes commented on GitHub (May 6, 2024): I asked because I am specifically looking at some error handling, that I would presume breaks things: https://php.watch/versions/8.0/PDO-default-errmode Should I bring this up in another discussion or is there a place for general php 8 discussions?
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@marclaporte commented on GitHub (May 6, 2024):

Here is good.

<!-- gh-comment-id:2096604404 --> @marclaporte commented on GitHub (May 6, 2024): Here is good.
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@jonocodes commented on GitHub (May 7, 2024):

ok. Concerning this PDO error modes php.watch/versions/8.0/PDO-default-errmode.

It appears php 7.x defaulted to make them silent, but 8.x is making them throw exceptions. This would have very different behaviors in the way cypht uses them since it is not explicitly setting a mode. So I recommend setting it explicitly.

That being said, I agree with the decision to have it default to throw exceptions. I came upon this when trying to figure out why some database operations were not working while I was developing. cypht seems to capture and hide the actual errors as you can see here:
github.com/cypht-org/cypht@2cf7a0ae88/scripts/create_account.php (L43-L50)

Unless there is another way to expose these errors (perhaps via a debug mode log) you cant see what the issue is, which is needed in order to fix it.

In my testing I was able to turn the above into a single line:

	$auth->create($user, $pass);

I explicitly ask for exceptions to happen when setting up the connection:

self::$dbh[$key]->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

That way the (error) logs are actionable.

<!-- gh-comment-id:2098904257 --> @jonocodes commented on GitHub (May 7, 2024): ok. Concerning this PDO error modes [php.watch/versions/8.0/PDO-default-errmode](https://php.watch/versions/8.0/PDO-default-errmode). It appears php 7.x defaulted to make them silent, but 8.x is making them throw exceptions. This would have very different behaviors in the way cypht uses them since it is not explicitly setting a mode. So I recommend setting it explicitly. That being said, I agree with the decision to have it default to throw exceptions. I came upon this when trying to figure out why some database operations were not working while I was developing. cypht seems to capture and hide the actual errors as you can see here: https://github.com/cypht-org/cypht/blob/2cf7a0ae88215e9ebc10935a0910290cec17fc5d/scripts/create_account.php#L43-L50 Unless there is another way to expose these errors (perhaps via a debug mode log) you cant see what the issue is, which is needed in order to fix it. In my testing I was able to turn the above into a single line: ```php $auth->create($user, $pass); ``` I explicitly ask for exceptions to happen when setting up the connection: ```php self::$dbh[$key]->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); ``` That way the (error) logs are actionable.
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@jonocodes commented on GitHub (May 7, 2024):

A seperate issue I am running into that may be php 8 related, though I am not sure. The INSTALL file says to run
php scripts/config_gen.php

when I do this I get:

[jono@dobro:~/src/cypht]$ php scripts/config_gen.php 

WARNING: No PHP Redis support found, Redis caching or sessions will not work


WARNING: No PHP Memcached support found, Memcached caching or sessions will not work


WARNING: No PHP gnupg support found, The PGP module set will not work if enabled

scanning module "core ...
scanning module contacts ...

Fatal error: Uncaught Error: Call to undefined function setup_base_page() in /home/jono/src/cypht/modules/contacts/setup.php:10
Stack trace:
#0 /home/jono/src/cypht/scripts/config_gen.php(193): require()
#1 /home/jono/src/cypht/scripts/config_gen.php(99): get_module_assignments(Array)
#2 /home/jono/src/cypht/scripts/config_gen.php(31): build_config()
#3 {main}
  thrown in /home/jono/src/cypht/modules/contacts/setup.php on line 10

[jono@dobro:~/src/cypht]$ php -v
PHP 8.2.17 (cli) (built: Mar 12 2024 14:26:30) (NTS)

My concern is the error. The warnings are also an issue, but I dont want to overload this conversation with that part.

<!-- gh-comment-id:2098908838 --> @jonocodes commented on GitHub (May 7, 2024): A seperate issue I am running into that may be php 8 related, though I am not sure. The INSTALL file says to run `php scripts/config_gen.php` when I do this I get: ``` [jono@dobro:~/src/cypht]$ php scripts/config_gen.php WARNING: No PHP Redis support found, Redis caching or sessions will not work WARNING: No PHP Memcached support found, Memcached caching or sessions will not work WARNING: No PHP gnupg support found, The PGP module set will not work if enabled scanning module "core ... scanning module contacts ... Fatal error: Uncaught Error: Call to undefined function setup_base_page() in /home/jono/src/cypht/modules/contacts/setup.php:10 Stack trace: #0 /home/jono/src/cypht/scripts/config_gen.php(193): require() #1 /home/jono/src/cypht/scripts/config_gen.php(99): get_module_assignments(Array) #2 /home/jono/src/cypht/scripts/config_gen.php(31): build_config() #3 {main} thrown in /home/jono/src/cypht/modules/contacts/setup.php on line 10 [jono@dobro:~/src/cypht]$ php -v PHP 8.2.17 (cli) (built: Mar 12 2024 14:26:30) (NTS) ``` My concern is the error. The warnings are also an issue, but I dont want to overload this conversation with that part.
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@marclaporte commented on GitHub (May 7, 2024):

@Shadow243 Please advise

<!-- gh-comment-id:2098930237 --> @marclaporte commented on GitHub (May 7, 2024): @Shadow243 Please advise
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@Shadow243 commented on GitHub (May 9, 2024):

Fatal error: Uncaught Error: Call to undefined function setup_base_page() in /home/jono/src/cypht/modules/contacts/setup.php:10
Stack trace:
#0 /home/jono/src/cypht/scripts/config_gen.php(193): require()
#1 /home/jono/src/cypht/scripts/config_gen.php(99): get_module_assignments(Array)
#2 /home/jono/src/cypht/scripts/config_gen.php(31): build_config()
#3 {main}
thrown in /home/jono/src/cypht/modules/contacts/setup.php on line 10

[jono@dobro:~/src/cypht]$ php -v
PHP 8.2.17 (cli) (built: Mar 12 2024 14:26:30) (NTS)


My concern is the error. The warnings are also an issue, but I dont want to overload this conversation with that part.

@jonocodes, did you add some configurations? I am not able to reproduce this issue. The only scenario where this is possible is when we comment out:

require_once APP_PATH.'modules/core/functions.php';

from modules/core/setup.php, which we are scanning successfully the first time. If not, then we should also import require_once APP_PATH.'modules/core/functions.php'; in scripts/config_gen.php; Can we have your specifications (environment in which you are encountering this) ?

Nevertheless, I have some issues with php 7.4 and 8.0.

sudo php80 scripts/config_gen.php                                                                                                                            ─╯

Warning: preg_match(): Allocation of JIT memory failed, PCRE JIT will be disabled. This is likely caused by security restrictions. Either grant PHP permission to allocate executable memory, or set pcre.jit=0 in /Users/shadow243/software/www/TIKI/cypht/vendor/symfony/dotenv/Dotenv.php on line 425

There is no error from 8.1

<!-- gh-comment-id:2103331522 --> @Shadow243 commented on GitHub (May 9, 2024): > Fatal error: Uncaught Error: Call to undefined function setup_base_page() in /home/jono/src/cypht/modules/contacts/setup.php:10 > Stack trace: > #0 /home/jono/src/cypht/scripts/config_gen.php(193): require() > #1 /home/jono/src/cypht/scripts/config_gen.php(99): get_module_assignments(Array) > #2 /home/jono/src/cypht/scripts/config_gen.php(31): build_config() > #3 {main} > thrown in /home/jono/src/cypht/modules/contacts/setup.php on line 10 > > [jono@dobro:~/src/cypht]$ php -v > PHP 8.2.17 (cli) (built: Mar 12 2024 14:26:30) (NTS) > ``` > > My concern is the error. The warnings are also an issue, but I dont want to overload this conversation with that part. @jonocodes, did you add some configurations? I am not able to reproduce this issue. The only scenario where this is possible is when we comment out: ``` require_once APP_PATH.'modules/core/functions.php'; ``` from `modules/core/setup.php`, which we are scanning successfully the first time. If not, then we should also import `require_once APP_PATH.'modules/core/functions.php';` in `scripts/config_gen.php`; Can we have your specifications (environment in which you are encountering this) ? Nevertheless, I have some issues with php 7.4 and 8.0. ``` sudo php80 scripts/config_gen.php ─╯ Warning: preg_match(): Allocation of JIT memory failed, PCRE JIT will be disabled. This is likely caused by security restrictions. Either grant PHP permission to allocate executable memory, or set pcre.jit=0 in /Users/shadow243/software/www/TIKI/cypht/vendor/symfony/dotenv/Dotenv.php on line 425 ``` There is no error from 8.1
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@jonocodes commented on GitHub (May 9, 2024):

@Shadow243

require_once APP_PATH.'modules/core/functions.php';

from modules/core/setup.php, which we are scanning successfully the first time. If not, then we should also import require_once APP_PATH.'modules/core/functions.php'; in scripts/config_gen.php

Adding require_once APP_PATH.'modules/core/functions.php'; to scripts/config_gen.php fixed it for me. Thanks.

When you say "we are scanning successfully the first time", what does that mean? What is doing the scanning?

<!-- gh-comment-id:2103569864 --> @jonocodes commented on GitHub (May 9, 2024): @Shadow243 > ``` > require_once APP_PATH.'modules/core/functions.php'; > ``` > from `modules/core/setup.php`, which we are scanning successfully the first time. If not, then we should also import `require_once APP_PATH.'modules/core/functions.php';` in `scripts/config_gen.php` Adding `require_once APP_PATH.'modules/core/functions.php';` to `scripts/config_gen.php` fixed it for me. Thanks. When you say "we are scanning successfully the first time", what does that mean? What is doing the scanning?
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@kroky commented on GitHub (May 10, 2024):

If we support PHP7.4 and PHP8 without proper error catching of PDO exceptions, I suggest we stay with explicit SILENT behavior as it used to be AND create a new PR for master/2.0.x (could be backported to 1.4 as well) where we turn on the exception error mode and add code to handle it correctly.

<!-- gh-comment-id:2104672932 --> @kroky commented on GitHub (May 10, 2024): If we support PHP7.4 and PHP8 without proper error catching of PDO exceptions, I suggest we stay with explicit SILENT behavior as it used to be AND create a new PR for master/2.0.x (could be backported to 1.4 as well) where we turn on the exception error mode and add code to handle it correctly.
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@jonocodes commented on GitHub (May 10, 2024):

@kroky
Sounds good. I moved the error handling discussion to a new ticket https://github.com/cypht-org/cypht/issues/1017

<!-- gh-comment-id:2104726536 --> @jonocodes commented on GitHub (May 10, 2024): @kroky Sounds good. I moved the error handling discussion to a new ticket https://github.com/cypht-org/cypht/issues/1017
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@Shadow243 commented on GitHub (May 24, 2024):

as planed here: [https://avan.tech/item106800](PHPunit upgrade), we will either set 8.1 for phpunit 10 nor 8.2 for phpunit 11

<!-- gh-comment-id:2129417125 --> @Shadow243 commented on GitHub (May 24, 2024): as planed here: [https://avan.tech/item106800](PHPunit upgrade), we will either set 8.1 for phpunit 10 nor 8.2 for phpunit 11
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@marclaporte commented on GitHub (May 24, 2024):

Interesting: https://phpunit.de/supported-versions.html

As of now, none of the Tiki versions require PHP 8.2+ (but some support it)
https://doc.tiki.org/Requirements#PHP_

Cypht running in Tiki is more important than PHPUnit 11. We could bump Tiki requirements to PHP 8.2 for Tiki 28 or Tiki29, but that is a community discussion. So as of now, I think the best is for Cypht to align with PHP requirements of Tiki. Tiki 27.x LTS requires PHP 8.1 so let's go to PHPUnit 10.

<!-- gh-comment-id:2129487886 --> @marclaporte commented on GitHub (May 24, 2024): Interesting: https://phpunit.de/supported-versions.html As of now, none of the Tiki versions require PHP 8.2+ (but some support it) https://doc.tiki.org/Requirements#PHP_ Cypht running in Tiki is more important than PHPUnit 11. We could bump Tiki requirements to PHP 8.2 for Tiki 28 or Tiki29, but that is a community discussion. So as of now, I think the best is for Cypht to align with PHP requirements of Tiki. Tiki 27.x LTS requires PHP 8.1 so let's go to PHPUnit 10.
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@marclaporte commented on GitHub (May 24, 2024):

Thank you @Shadow243 for https://github.com/cypht-org/cypht/pull/1044

<!-- gh-comment-id:2130389281 --> @marclaporte commented on GitHub (May 24, 2024): Thank you @Shadow243 for https://github.com/cypht-org/cypht/pull/1044
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@marclaporte commented on GitHub (May 24, 2024):

I see https://github.com/cypht-org/cypht/pull/1044/ already bumps requirement to PHP 8.1, closing this as done.

<!-- gh-comment-id:2130405349 --> @marclaporte commented on GitHub (May 24, 2024): I see https://github.com/cypht-org/cypht/pull/1044/ already bumps requirement to PHP 8.1, closing this as done.
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@marclaporte commented on GitHub (May 24, 2024):

I updated https://github.com/cypht-org/cypht/wiki/Lifecycle accordingly.

<!-- gh-comment-id:2130412285 --> @marclaporte commented on GitHub (May 24, 2024): I updated https://github.com/cypht-org/cypht/wiki/Lifecycle accordingly.
kerem commented 2026-02-25 21:35:15 +03:00
Author
Owner
Copy link

@TheDigitalOrchard commented on GitHub (May 25, 2024):

PHP 8.x has already been stable for 3 years, and I've noticed many libraries now defaulting to a minimum version of PHP 8.x. PHP 7.x has already passed its EOL.

While it would be a "nice" thing to continue to support PHP 7.x with Cypht, I think the best option is to keep Version 2.x around for that purpose and Version 3.x sets a minimum version of PHP 8.1.

Just my take.

<!-- gh-comment-id:2130762056 --> @TheDigitalOrchard commented on GitHub (May 25, 2024): PHP 8.x has already been stable for 3 years, and I've noticed many libraries now defaulting to a minimum version of PHP 8.x. PHP 7.x has already passed its EOL. While it would be a "nice" thing to continue to support PHP 7.x with Cypht, I think the best option is to keep Version 2.x around for that purpose and Version 3.x sets a minimum version of PHP 8.1. Just my take.
kerem commented 2026-02-25 21:35:16 +03:00
Author
Owner
Copy link

@Shadow243 commented on GitHub (May 25, 2024):

PHP 8.x has already been stable for 3 years, and I've noticed many libraries now defaulting to a minimum version of PHP 8.x. PHP 7.x has already passed its EOL.

While it would be a "nice" thing to continue to support PHP 7.x with Cypht, I think the best option is to keep Version 2.x around for that purpose and Version 3.x sets a minimum version of PHP 8.1.

Just my take.

We are not able to upgrade phpunit to 10 with php 7.4 bcz the minimum php version for phpunit 10 is 8.1

<!-- gh-comment-id:2130857526 --> @Shadow243 commented on GitHub (May 25, 2024): > PHP 8.x has already been stable for 3 years, and I've noticed many libraries now defaulting to a minimum version of PHP 8.x. PHP 7.x has already passed its EOL. > > > > While it would be a "nice" thing to continue to support PHP 7.x with Cypht, I think the best option is to keep Version 2.x around for that purpose and Version 3.x sets a minimum version of PHP 8.1. > > > > Just my take. We are not able to upgrade phpunit to 10 with php 7.4 bcz the minimum php version for phpunit 10 is 8.1
kerem commented 2026-02-25 21:35:16 +03:00
Author
Owner
Copy link

@marclaporte commented on GitHub (May 25, 2024):

While it would be a "nice" thing to continue to support PHP 7.x with Cypht, I think the best option is to keep Version 2.x around for that purpose and Version 3.x sets a minimum version of PHP 8.1.

Yes, and that is what we are doing. Plus Cypht 1.4.x with support for PHP 5.6+. I added the supported PHP versions here:
https://github.com/cypht-org/cypht/wiki/Lifecycle

<!-- gh-comment-id:2131111036 --> @marclaporte commented on GitHub (May 25, 2024): > While it would be a "nice" thing to continue to support PHP 7.x with Cypht, I think the best option is to keep Version 2.x around for that purpose and Version 3.x sets a minimum version of PHP 8.1. Yes, and that is what we are doing. Plus Cypht 1.4.x with support for PHP 5.6+. I added the supported PHP versions here: https://github.com/cypht-org/cypht/wiki/Lifecycle
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
2.x
mta-sts-implementation
feat-compose-backspace-delete-recipients
release-2.5.1
add-tls3-support
1.4.x
enforce-coverage
release-2.4.2
strip_dns_prefetch_tags
fix_nightly_build
pr-title-validation-update
review-sent-email
revert-1339-fixed-tags-display
revert-1061-rem-cram-md5
sys-messages-revamp
revert-685-fixed-str-pos-warning-when-no-to
revert-590-empty-settings
release-1.3.0
revert-471-draft-add-warning
revert-454-feature/server-list-by-uniqid
php7.4-support
release-1.2.0
remove-mobile-media-queries
release-1.1.0
release-1.0.0
v2.7.0
v2.6.0
v2.5.1
v2.5.0
v1.4.7
v2.4.2
v2.4.1
v1.4.6
v1.4.5
v2.4.0
v2.3.0
v2.2.0
v1.4.4
v2.1.0
v2.0.1
v1.4.3
v2.0.0
v1.4.2
v1.4.1
v1.4.0
v1.3.0
v1.3.0-rc3
v1.3.0-rc2
v1.3.0-rc1
v1.1.0
v1.1.0-rc4
v1.1.0-rc3
v1.1.0-rc2
v1.1.0-rc1
v1.0.0
v1.0.0-rc8
v1.0.0-rc7
v1.0.0-rc6
v1.0.0-rc5
v1.0.0-rc4
v1.0.0-rc3
v1.0.0-rc2
v1.0.0-rc1
Labels
Clear labels   
2fa

   
I18N

   
PGP

   
Security

   
Security

   
account

   
advanced_search

   
advanced_search

   
announcement

   
api_login

   
authentication

   
awaiting feedback

   
blocker

   
bug

   
bug

   
bug

   
calendar

   
config

   
contacts

   
core

   
core

   
devops

   
docker

   
docs

   
duplicate

   
dynamic_login

   
enhancement

   
epic

   
feature

   
feeds

   
framework

   
github

   
github

   
gmail_contacts

   
good first issue

   
help wanted

   
history

   
history

   
imap

   
imap_folders

   
inline_message

   
installation

   
keyboard_shortcuts

   
keyboard_shortcuts

   
ldap_contacts

   
mobile

   
need-ssh-access

   
new module set

   
nux

   
pop3

   
profiles

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
refactor

   
release

   
research

   
saved_searches

   
smtp

   
strategic

   
tags

   
tests

   
themes

   
website

   
wordpress
No labels
2fa
I18N
PGP
Security
Security
account
advanced_search
advanced_search
announcement
api_login
authentication
awaiting feedback
blocker
bug
bug
bug
calendar
config
contacts
core
core
devops
docker
docs
duplicate
dynamic_login
enhancement
epic
feature
feeds
framework
github
github
gmail_contacts
good first issue
help wanted
history
history
imap
imap_folders
inline_message
installation
keyboard_shortcuts
keyboard_shortcuts
ldap_contacts
mobile
need-ssh-access
new module set
nux
pop3
profiles
pull-request
question
refactor
release
research
saved_searches
smtp
strategic
tags
tests
themes
website
wordpress
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/cypht#524
No description provided.