This PR was merged into the 4.4 branch.
Discussion
----------
[Messenger] make all stamps final and mark stamp not meant to be sent
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets |
| License | MIT
| Doc PR |
Some newer stamps were already final. This makes all of them final. Also marks all stamps that are not meant to be sent using the new `NonSendableStampInterface`. This makes it easier to see which stamps are actually important and required to persist in a queue for certain functionality, like the `BusNameStamp` for the `RoutableMessageBus`
Commits
-------
013904b081 [Messenger] make all stamps final and mark stamp not meant to be sent
This PR was merged into the 4.3 branch.
Discussion
----------
[Messenger] No need for retry to require SentStamp
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | yes
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets |
| License | MIT
| Doc PR |
Fixes 2) in #32049
@weaverryan the SentStamp in the worker seems totally irrelevant. You always want to send messages back to the transport where they came from for retry. The only relevance I can potentially see is for the SyncTransport. Messages received async from worker might be routed to the SyncTransport. Using the SentStamp would redeliver the messages into the SyncTransport instead of the async. But that doesn't seem to have any use-case. I'm running the worker which handles the messages immediately. So basically there is no difference if they go to the Sync or Async transport from within the worker.
Commits
-------
0034dee641 [Messenger] make retry logic work without SentStamp
This PR was merged into the 5.0-dev branch.
Discussion
----------
[5.0] Add return types in final classes
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes/no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | no
| Tests pass? | no
| Fixed tickets | #31981
| License | MIT
| Doc PR | symfony/symfony-docs#... <!-- required for new features -->
This is the first step for the issue #31981
I have some questions:
- ~I have not added type for methods with `@inheritdoc` annotation, should I?~
- ~Don't we want to type also functions without `@return` annotation? (still in `final` classes)~
- ~If yes is the answer of the previous one, do we also want the `void` return type?~
- ~I have also added the return type in the `DependencyInjection` PhpDumper, but is it also wanted? (if yes, I will clean a bit the code changed)~
- ~Should we update the documentation's code samples when they display `final` classes?~
Todo:
- [x] Adjust the PR, following the answers of the questions
- [x] Add return type also when there is no `@return`, or with `@inheritdoc`
- [x] [src/Symfony/Component/Debug/ErrorHandler.php#L383](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Debug/ErrorHandler.php#L383) `@return` annotation is not correct according to the return, investigate and adjust if needed
- [x] [src/Symfony/Component/HttpKernel/ControllerMetadata/ArgumentMetadataFactory.php#L50](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/ControllerMetadata/ArgumentMetadataFactory.php#L50) `@return` annotation is not correct according to the return, investigate and adjust if needed
- [x] Do a PR on documentation to add return type on code snippets with final classes => unneeded as they were already typed
Commits
-------
ca5ae1989e Replace @return annotation by return type in final classes
This PR was merged into the 4.3 branch.
Discussion
----------
[Mailer] Catch missing scheme in DSN
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
The `Symfony\Component\Mailer\Transport::createTransport()` method parses and validates a passed DSN. I noticed that we never check if the DSN contains a valid scheme, but we always assume that the scheme is present in then parse result. If someone passes a DSN without a scheme to that method, they would almost certainly run into a PHP notice.
This PR makes sure that a scheme is present in the URL and throws a proper exception otherwise.
Commits
-------
3eba36c088 [Mailer] Catch missing scheme in DSN.
This PR was merged into the 4.3 branch.
Discussion
----------
[HttpClient] fixing passing debug info to progress callback
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
NativeHttpClient already has it.
Commits
-------
dc55cf826a [HttpClient] fixing passing debug info to progress callback
This PR was merged into the 3.4 branch.
Discussion
----------
[Filesystem] add test to avoid regressions
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
Commits
-------
0d7d1f81bc add test to avoid regressions
This PR was merged into the 4.3 branch.
Discussion
----------
[DebugBundle] fix register ReflectionCaster::unsetClosureFileInfo caster in var cloner service
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| License | MIT
Non-existent class was checked by `method_exists` in Debug bundle.
This should fix (and correctly register) the caster while loading `DebugExtension` from `DebugBundle`
Commits
-------
860164ee7e [DebugBundle] fix register ReflectionCaster::unsetClosureFileInfo caster in var cloner service
This PR was submitted for the 4.4 branch but it was merged into the 3.4 branch instead (closes#32112).
Discussion
----------
Turkish translation added to Form Component
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
Commits
-------
a030e393c5 Turkish translation added to Form Component
This PR was merged into the 4.3 branch.
Discussion
----------
[Messenger] Remove DispatchAfterCurrentBusStamp when message is put on internal queue
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #32009
| License | MIT
| Doc PR |
This will fix#32009.
Thank you @brpauwels for the report.
I consider it safe to remove the `DispatchAfterCurrentBusStamp` because its meaning disappear after we handled the "current bus".
T0: We add the stamp
T1: We put the envelope on an internal queue in `DispatchAfterCurrentBusMiddleware`
T2: We handle the current bus.
T3: We start processing our internal queue.
At T3 there we are "after current bus", that is why we dont need the stamp any more.
Commits
-------
91f1680b3f [Messenger] Remove DispatchAfterCurrentBusStamp when message is put on internal queue
This PR was merged into the 4.4 branch.
Discussion
----------
[Ldap] Add users extraFields in ldap component
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | yes <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | #28873, #19329 <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | todo when validated, before merge <!-- required for new features -->
As I'm using ldap too in some personal project, It seems that this feature is a really good nice to have IMHO.
Adding the wanted field in the `user_metadata` array transform them as field -> value in the `metadata` field of the user.
Commits
-------
bcfff04797 [Ldap] Add users extra_fields in ldap component
This PR was submitted for the master branch but it was merged into the 4.2 branch instead (closes#32121).
Discussion
----------
Fix link to documentation
| Q | A
| ------------- | ---
| Branch? | 4.4 for features / 3.4, 4.2 or 4.3 for bug fixes <!-- see below -->
| Bug fix? | yes
| New feature? |No, update link to VarExporter doc only
| BC breaks? | no
| Deprecations? | no
| Test pass? | yes
| Fixed tickets | none
| License | MIT
| Doc PR | symfony/symfony-docs
Commits
-------
e0d2c58bc2 Fix link to documentation
This PR was merged into the 4.4 branch.
Discussion
----------
[Ldap] Add exception for mapping ldap errors
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | #28677 <!-- #-prefixed issue number(s), 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):
- 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 the master branch.
-->
Maybe we could add more exception code since the list has a lot of errors, maybe we could add a class that maps the error to the right exeptions. see https://www.php.net/manual/en/function.ldap-errno.php
Commits
-------
1b29cb1a5f [Ldap] Add exception for mapping ldap errors
This PR was merged into the 4.3 branch.
Discussion
----------
[FrameworkBundle] sync `require-dev` and `conflict` constraints
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
The `conflict` section already prevents the Translation component 4.2 to be installed.
Commits
-------
47f9235568 sync `require-dev` and `conflict` constraints
* 4.4:
fix order of items in upgrade file
fix translation domain
tag the FileType service as a form type
don't validate IP addresses from env var placeholders
[Validator] Fix GroupSequenceProvider annotation
[Messenger] fix delay exchange recreation after disconnect
Update ajax security cheat sheet link
Fix AuthenticationException::getToken typehint
* 4.3:
fix translation domain
tag the FileType service as a form type
don't validate IP addresses from env var placeholders
[Validator] Fix GroupSequenceProvider annotation
[Messenger] fix delay exchange recreation after disconnect
Update ajax security cheat sheet link
Fix AuthenticationException::getToken typehint
* 4.2:
fix translation domain
tag the FileType service as a form type
[Validator] Fix GroupSequenceProvider annotation
Update ajax security cheat sheet link
Fix AuthenticationException::getToken typehint
* 3.4:
fix translation domain
tag the FileType service as a form type
[Validator] Fix GroupSequenceProvider annotation
Update ajax security cheat sheet link
Fix AuthenticationException::getToken typehint