Skip to content
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

Update and cleanup 4.2.0 #781

Closed
wants to merge 18 commits into from
Closed

Update and cleanup 4.2.0 #781

wants to merge 18 commits into from

Conversation

ophian
Copy link

@ophian ophian commented Aug 10, 2022

I did not touch the sysplugins/smarty_internal_templatelexer.php and smarty_internal_templateparser.php files.

@ophian
Copy link
Author

ophian commented Aug 10, 2022

another (smaller) PR for PHP 8.2 (which replaces the #775 by Progi1984) will follow when merged (since building on).

Convert to DateTime Interface with intl before PHP 9.
@wisskid
Copy link
Member

wisskid commented Aug 18, 2022

There appear to be a few problems with the unit tests now. Could you look into this?
Don't get me wrong: I'm happy with all the effort you put in, but to keep things manageable I'd prefer focused, minimal PRs with a clear goal and a changelog if possible. Much easier to review, too.
So maybe you could close this one and provide a couple of separate, focused PRs?

@ophian
Copy link
Author

ophian commented Aug 19, 2022

@wisskid
Yes thats the point. Phpunit does not know that I disabled/silenced strftime deprecation "errors" by @ until PHP 9 will arrive in future days and that I did this to avoid using polyfills or other crucial workarounds; strftime will just work fine until then, but we need to avoid the deprecation notices up from PHP 8.1. For phpunit this is an error (w/o value), so the check fails.

This all while the intl extension is a need for the DateTime Interface as the strftime successor per default. And that isn't the case in popular server situations these days.
So I fear I can't do anything against it. Using @ is the simplest solution. Do they (unit checks) stop the merge or are they informational only? Something similar in #775 I assume, which I would not merge, since my followup is slight different as already noted.

@wisskid
Copy link
Member

wisskid commented Aug 19, 2022

Failing unit tests means no merge, I'm afraid. And AFAIK deprecation notices aren't a show stopper. They exist to inform us ahead of time that some functionality will change in the future.
So deprecation notices should not cause unit tests to fail.

@ophian
Copy link
Author

ophian commented Aug 19, 2022

Sorry, I have no further insight in github actions and phpunit tests... But it says: This branch has not conflicts... and Only those with write access to this repository can merge pull requests underneath though.
If you take a look youself, it is the last commit which is the @strftime commit that seems to fail. But none of these tests error messages has a value. You said "So deprecation notices should not cause unit tests to fail" but something obviously does.

@wisskid
Copy link
Member

wisskid commented Aug 19, 2022

Ok, I'll take a look at it soon. Thanks so far.

@ophian
Copy link
Author

ophian commented Aug 31, 2022

Maybe that needs something equal for unit test as in PR #775 ? (Please remember, I have a better (extended) one in line for this)
I personally never play with these "dependencies", so I can't really say. Maybe you can add it to this pull request?

@wisskid
Copy link
Member

wisskid commented Sep 15, 2022

@ophian if you rebase/merge master you can now easily run the unit tests for each supported PHP version locally if you have docker installed.

For now, 1478 unit tests fail with this error:

Undefined property: Smarty::$smarty

/home/runner/work/smarty/smarty/libs/Smarty.class.php:1311
[...]

for smarty class magic __get() method.
@ophian
Copy link
Author

ophian commented Sep 15, 2022

@wisskid Yes, thanks. Fixed.
Its a strange issue, since the normal ternary does not require a defined $smarty property in the Smarty class for magic __get, while usage with Null Coalescing Operator does.

@ophian
Copy link
Author

ophian commented Sep 16, 2022

The here mentioned 3 conflicts with 4.2.1 do only have one related issue with this PR in the libs/plugins/function.html_select_date.php file where I changed the ternary too. Shall I add the new 4.2.1 including my change to this PR or will we do this later?

@ophian
Copy link
Author

ophian commented Sep 29, 2022

@wisskid
So I did. Please run / restart the CI.

@ophian ophian mentioned this pull request Oct 18, 2022
@wisskid
Copy link
Member

wisskid commented Nov 22, 2022

@ophian there is a lot of value in this PR, but it's too big and all over the place. The use of the null coalescing operator makes the code more readable, but it would be great to have a limited PR that does only that (which could easily been done by cherry-picking 159ed4e).

@wisskid wisskid closed this Nov 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants