-
Notifications
You must be signed in to change notification settings - Fork 715
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add PHP 8.1 compatibility #678
Conversation
Hi @atomiix this looks great! However, I've been working on feature/php8-support to support PHP8.0 already. Could you rebase your PR on this branch (or wait until it is in master)? Reviewing your PR, I see a couple of changes that do not seem to be explained by support for PHP8.1. E.g. the Thanks for your work! |
hey @wisskid, I rebased my PR, it should be good now! I also edited my description to explain why I added the |
@wisskid just a friendly reminder as PHP 8.1 due date is in 2 days 🙃 |
Good news. PHP 8.1 is available ;) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great PR by the way, 2 comments made
|
||
$formatter = null; | ||
$format_compare = '%m'; | ||
if (class_exists('IntlDateFormatter')) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since IntlDateFormatter
isn't included by default and the strftime
deprecation notice is only a notice, wouldn't it be better to keep it as it was? We're adding complexity here, only fixing the deprecation notices on certain environments. I'm hoping PHP9 will include a way to handle this smoothly that is included by default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, I don't think that PHP 9.0 will handle it smoothly, from https://wiki.php.net/rfc/deprecations_php_8_1:
The strftime() and gmstrftime() functions exhibit similar issues as strptime(), in that the formats they support, as well as their behavior, is platform-dependent. Unlike strptime(), these functions are available on Windows, though with a different feature set than on Linux. Musl-based distributions like Alpine do not support timezone-related format specifiers correctly. These functions are also locale-based, and as such may exhibit thread-safety issues.
Once again date() or DateTime::format() provide portable alternatives, and IntlDateFormatter::format() provides a more sophisticated, localization-aware alternative.
The proposal is to deprecate strftime() and gmstrftime() in favor of these alternatives.
So I guess this is the way we'll have to do it in PHP 9.0 and in the meantime, we can have strftime
as a fallback. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me put it in another way: your change will still fail in PHP9, because strftime
will be deleted by then (unless they reverse the decision). So what is the point of making the change in the first place?
Also: I know strftime
is used a LOT in PHP libs, so the deprecation will trigger the need for a suitable alternative to be included in PHP9 by default. If that turns out to be IntlDateFormatter
, we'll switch then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @atomiix , having strftime
as fallback is a good idea. I'm not in favor of having deprecation notices only because it's acceptable. When you're working you don't want to be spamed by useless messages you can avoid.
Adding IntlDateFormatter
as alternative is a good idea, but the real check should be if (extension_loaded('intl')) {
for a better understanding.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also think avoiding any strftime
would be beneficial. The intl extension is quite common nowadays, and Symfony has a polyfill (symfony/polyfill-intl-icu
) which is an easy alternative if the intl extension is missing and provides a way of avoiding deprecation notices even without the extension.
So are we going to merge this branch or.....? |
Maybe, maybe not, that's a hard question 🤔 |
I noticed that |
I think yes, but the whole part needs to be refactored:
|
@j-applese3d you're right! I just added a new modifier |
Not sure it's the right solution as the |
The issue is that IMHO, for |
I like the idea of combining |
@wisskid We'll have to keep in mind that |
I am working on a migration of a project to PHP 8.1 and can confirm that this PR solves all the problems I've been seeing. |
Any news? |
I'm thinking we should separate the fixes for the fatal error on PHP8.1(#671) from the removal of deprecation notices strftime. The former is much more pressing now. |
Can you tell us estimated time, when you can fix it? Is there a lot of problems to run Smarty on php8.1? |
Looks like there is not much missing to get 8.1 support. Is there anything we can do to speed up the merge/release? Maybe creating another PR with all changes except the strftime-issue? |
Yes that would be super. I'd merge that. |
Okay, I've created another pr for only the non-intldate related stuff: #713 |
There are 3 PR on PHP 8.1...Do we expect a merge soon like in coming days? |
Closing this one in favor of #713 |
I will use @strftime as suggested in smarty - smarty-php/smarty#678 - smarty-php/smarty#780 A good solution using date() probably requires lot of testing.
The goal of this PR is to make smarty compatible with PHP 8.1.
The main issue was the use of the function
strftime()
which is deprecated in PHP 8.1. This problem is solve by the use ofIntlDateFormatter
after being sure that theintl
extension is loaded.Other deprecations have been removed too.