cypht
cypht copied to clipboard
cypht-org
What should be the minimum PHP version for Cypht 3.0? PHP 8.1? 8.2? 8.3?
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
What is the state of php 8.x? Has cypht been run in 8 to see if it works or needs updating?
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
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.
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.
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?
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: 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:
$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.
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.
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
@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 importrequire_once APP_PATH.'modules/core/functions.php';inscripts/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?
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.
@kroky Sounds good. I moved the error handling discussion to a new ticket https://github.com/cypht-org/cypht/issues/1017
as planed here: [https://avan.tech/item106800](PHPunit upgrade), we will either set 8.1 for phpunit 10 nor 8.2 for phpunit 11
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.
I see https://github.com/cypht-org/cypht/pull/1044/ already bumps requirement to PHP 8.1, closing this as done.
I updated https://github.com/cypht-org/cypht/wiki/Lifecycle accordingly.
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.
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
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