* 4.4:
Add missing symfony/mime to require-dev
[Validator] Added the missing Mongolian translations
[ErrorHandler] Never throw on warnings triggered by assert() and set assert.exception=1 in Debug::enable()
refactor(Process): fromShellCommandLine
[Mailer] Do not ping the SMTP server before sending every message
This PR was merged into the 3.4 branch.
Discussion
----------
[Validator] Added the missing Mongolian translations
https://github.com/symfony/symfony/issues/30175
Added the missing translations for the Mongolian ("mn") locale.
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | Fix#30175
| License | MIT
| Doc PR |
Commits
-------
365f4d76bd [Validator] Added the missing Mongolian translations
This PR was merged into the 4.4 branch.
Discussion
----------
[Process] throw when PhpProcess::fromShellCommandLine() is used
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#35637
| License | MIT
| Doc PR | None
Close#35638
Final PR (rebased and tests added)
Commits
-------
7f6d71c2a3 refactor(Process): fromShellCommandLine
This PR was merged into the 4.4 branch.
Discussion
----------
[ErrorHandler] Never throw on warnings triggered by assert() and set assert.exception=1 in Debug::enable()
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Because we don't use `assert()`, this is something we completely overlooked, but warnings triggered should not throw as there is already a dedicated exception mode when using `assert()`.
This turns this exception mode to 1 in debug mode and logs the assert() warnings in prod.
Commits
-------
f18ef6ca08 [ErrorHandler] Never throw on warnings triggered by assert() and set assert.exception=1 in Debug::enable()
This PR was squashed before being merged into the 4.4 branch (closes#35633).
Discussion
----------
[Mailer] Do not ping the SMTP server before sending every message
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#35515
| License | MIT
This pull request changes the SMTP transport to only ping the server if the last message was sent more than a specified number of seconds ago (instead of pinging the server before every message). By default, it will ping the server if 100 or more seconds since the last message have passed.
This should make sending emails with the SMTP transport more robust with many emails, as SMTP servers will often drop the connection if too many non-mail commands are sent (like pinging the server with NOOP commands).
Commits
-------
28178108d3 [Mailer] Do not ping the SMTP server before sending every message
* 4.4:
[FrameworkBundle] fix "samesite" in XSD
[Console] Consider STDIN interactive
Update UserPasswordEncoderCommand.php
[HttpFoundation][FrameworkBundle] fix support for samesite in session cookies
[DoctrineBridge] Fixed submitting ids with query limit or offset
* 3.4:
[FrameworkBundle] fix "samesite" in XSD
Update UserPasswordEncoderCommand.php
[HttpFoundation][FrameworkBundle] fix support for samesite in session cookies
[DoctrineBridge] Fixed submitting ids with query limit or offset
This PR was submitted for the master branch but it was merged into the 4.4 branch instead.
Discussion
----------
[Console] Consider STDIN interactive
| Q | A
| ------------- | ---
| Branch? |4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#30726, supersedes #30796
| License | MIT
| Doc PR | -
As demonstrated with `yes | bin/console foo` in #30726, original assumption made in #1699 was wrong. Then, #8452 was merged which solved bug #8079 -> this was a use case when application hangs with `--no-interaction` flag - nobody probably realized that application can be in "non-interactive" mode, without using this flag and not hang. Then, there was #14102 which was poor man's fix for problem caused by this. So already plenty issues this behaviour causes. Looks like a mess to me. Application should be considered non-interactive only when explicitly specified so (--no-interactive flag), otherwise it doesn't hang.
### What this change means?
It only changes one case: When doing `echo foo | bin/console bar`, `yes | bin/console bar`, `bin/console bar < foo`, etc. Redirecting stdout is not affected, as application in that case was considered interactive before too. With stdin, this opens possibility to control symfony/console based application by default via stdin, including via `proc_open`.
Additionally, not only it allows to control the input for questions, it also makes the question and answers to display on screen. So before, user had no idea what questions are happening and what answers (defaults) are being used.
### About a BC break
I'm not really aware of a valid use case this can break. Can you help find any?
1. Since symfony/console components were NOT interactive with stdin before, stdin couldn't be used to control them - so there this change breaks nothing, because it didn't make sense to pass stdin there instead of specifying -n flag.
1. If application uses internal logic where it relies on STDIN disregarding `Output::isInteractive` flag, this doesn't change anything for these either - they will keep using STDIN disregarding result of this flag.
1. What if application uses internal logic for stdin AND console components like QuestionHelper? To me, that doesn't make much sense, because with previous behaviour, such questions would result always into defaults. It might make sense in case application supports both modes - either stdin, or user supplied input and just use default answers with stdin. But I cannot figure out example of such use - what would be the case where application allows user to control something via stdin, but at the same time forbids them to set certain aspects (answers to questions given)?
1. What about `SHELL_INTERACTIVE` env variable? Only way to utilize it was to force enable interactive mode, but since it will be interactive now by default, it will do nothing and no behaviour changes.
1. Preventing stdin control was much bigger potential BC break. Despite that, it was disallowed in minor Symfony version. And as far as I can see, I saw no backlash.
Finally, this targets Symfony 5.0 to be extra sure anyways, so I think it's ok, but feel free to suggest documenting this in upgrade guide or changelog. I would even target 4.4, but chose 5.0 as it's easier to push through there.
Commits
-------
ef157d5b3f [Console] Consider STDIN interactive
This PR was merged into the 3.4 branch.
Discussion
----------
[HttpFoundation][FrameworkBundle] fix support for samesite in session cookies
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#35520
| License | MIT
| Doc PR | -
This PR cherry-picks #28168 on 3.4, with a rationale given by @ConneXNL in https://github.com/symfony/symfony/issues/35520#issuecomment-582296847:
> I hope I am wrong but I see the impact of not making any changes to Symfony 3.4 will have a tons of sites break if we cannot set the cookie's samesite setting (in the framework session and remember me) before Chrome pushes this update.
>
> Very soon all existing cookies are no longer going to work with cross-domains if you do not specify 'None' for the cookie_samesite. All external APIs that use cookies and are running SF 3.4 will break and devs will have no quick solution to fix their auth process.
>
> If you are using PHP 7.4, yes you can most likely use ini_set to workaround this issue.
>
> However, ini_set('cookie_samesite') does not work in PHP Version <= 7.2.
I am not even sure PHP 7.3 supports the value 'None' as php.watch/articles/PHP-Samesite-cookies says it has support for 'Lax' and 'Scrict'.
>
> This effectively means SF 3.4 on PHP 7.2 (or PHP 7.3) is no longer supported for cross domain APIs with cookies. People would have to either update PHP to 7.4 (if they even can?) or go to Symfony 4 (with a dead live site is going to be a complete disaster).
>
> Since the impact of the change that chrome is about to roll out is so fundamentally changing our way to set cookies, I consider configuring samesite configuration in the framework an absolute requirement, not a feature, especially since SF 3.4 is still supported.
>
> What am i missing?
>
> Note: SF3 HTTPFoundation already supports the new cookie settings, it's just the framework that doesn't support it.
Our BC policy embeds the promise that one should be able to keep the same app on a newest infrastructure (eg that's why supporting a PHP version is a bug fix). I think we can consider this for browsers here also. WDYT?
Commits
-------
f46e6cb8a0 [HttpFoundation][FrameworkBundle] fix support for samesite in session cookies
This PR was merged into the 3.4 branch.
Discussion
----------
[DoctrineBridge] Fixed submitting ids with query limit or offset
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | Fix https://github.com/symfony/symfony/pull/34900#discussion_r375246113 <!-- prefix each issue number with "Fix #", if any -->
| License | MIT
| Doc PR | ~ <!-- required for new features -->
<!--
Replace this notice by a short README for your feature/bugfix. This will help people
understand your PR and can be used as a start for the documentation.
Additionally (see https://symfony.com/roadmap):
- Always add tests and ensure they pass.
- Never break backward compatibility (see https://symfony.com/bc).
- Bug fixes must be submitted against the lowest maintained branch where they apply
(lowest branches are regularly merged to upper ones so they get the fixes too.)
- Features and deprecations must be submitted against branch master.
-->
Commits
-------
9bb194098f [DoctrineBridge] Fixed submitting ids with query limit or offset
This PR was submitted for the master branch but it was merged into the 3.4 branch instead (closes#35628).
Discussion
----------
[Security] Improve info UserPasswordEncoderCommand
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| License | MIT
| Doc PR | n/a
`php bin/console security:encode-password [password] App\Entity\User`
will result in
`No encoder has been configured for account "AppEntityUser". `
If a full class path is used, it either has to be passed in as a string or has to be escaped by double slashes.
Commits
-------
3604bb7018 Update UserPasswordEncoderCommand.php
This PR was squashed before being merged into the 5.0 branch (closes#35616).
Discussion
----------
[Workflow] Make method signature compatible with 4.4
| Q | A
| ------------- | ---
| Branch? | 5.0 <!-- see below -->
| Bug fix? | yes
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | Fix#35615 <!-- prefix each issue number with "Fix #", if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!-- required for new features -->
<!--
Replace this notice by a short README for your feature/bugfix. This will help people
understand your PR and can be used as a start for the documentation.
Additionally (see https://symfony.com/roadmap):
- Always add tests and ensure they pass.
- Never break backward compatibility (see https://symfony.com/bc).
- Bug fixes must be submitted against the lowest maintained branch where they apply
(lowest branches are regularly merged to upper ones so they get the fixes too.)
- Features and deprecations must be submitted against branch master.
-->
A method signature changed in a non-backwards-compatible way in 5.0.0 - and in only one class. This commit fixes that - and has been tested.
For full details see ticket #35615.
Commits
-------
474be9613b [Workflow] Make method signature compatible with 4.4
This PR was merged into the 3.4 branch.
Discussion
----------
[Security] Replace 403 with 401 in `onAuthenticationFailure` method
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | N/A
| License | MIT
| Doc PR | N/A
This comment in `onAuthenticationFailure` was misleading since a 401 status code should probably be returned instead of a 403.
Commits
-------
73bc793be2 Replace 403 with 401 in onAuthenticationFailure method
This PR was submitted for the master branch but it was merged into the 4.4 branch instead.
Discussion
----------
[PhpUnitBridge] fix getting the vendor/ dir for tests
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Commits
-------
341dd5dd1d [PhpUnitBridge] fix getting the vendor/ dir for tests
This PR was merged into the 4.4 branch.
Discussion
----------
[PHPunit bridge] Provide current file as file path
I failed to apply perfectly this comment:
https://github.com/symfony/symfony/pull/33820#discussion_r338746158
It should fix one failing test in the bridge.
| Q | A
| ------------- | ---
| Branch? |4.4
| Bug fix? | not for the end user
| New feature? | no
| Deprecations? | no
| Tickets | n/a
| License | MIT
| Doc PR | n/a
<!--
Replace this notice by a short README for your feature/bugfix. This will help people
understand your PR and can be used as a start for the documentation.
Additionally (see https://symfony.com/roadmap):
- Always add tests and ensure they pass.
- Never break backward compatibility (see https://symfony.com/bc).
- Bug fixes must be submitted against the lowest maintained branch where they apply
(lowest branches are regularly merged to upper ones so they get the fixes too.)
- Features and deprecations must be submitted against branch master.
-->
Commits
-------
d5302cb5d2 Provide current file as file path