* 3.2:
Using FQ name for PHP_VERSION_ID
[Form] Fix \IntlDateFormatter timezone parameter usage to bypass PHP bug #66323
Harden the debugging of Twig filters and functions
bumped Symfony version to 3.2.10
updated VERSION for 3.2.9
updated CHANGELOG for 3.2.9
bumped Symfony version to 2.8.22
updated VERSION for 2.8.21
updated CHANGELOG for 2.8.21
bumped Symfony version to 2.7.29
updated VERSION for 2.7.28
update CONTRIBUTORS for 2.7.28
updated CHANGELOG for 2.7.28
* 2.8:
Using FQ name for PHP_VERSION_ID
[Form] Fix \IntlDateFormatter timezone parameter usage to bypass PHP bug #66323
Harden the debugging of Twig filters and functions
bumped Symfony version to 2.8.22
updated VERSION for 2.8.21
updated CHANGELOG for 2.8.21
bumped Symfony version to 2.7.29
updated VERSION for 2.7.28
update CONTRIBUTORS for 2.7.28
updated CHANGELOG for 2.7.28
* 2.7:
Using FQ name for PHP_VERSION_ID
[Form] Fix \IntlDateFormatter timezone parameter usage to bypass PHP bug #66323
Harden the debugging of Twig filters and functions
bumped Symfony version to 2.7.29
updated VERSION for 2.7.28
update CONTRIBUTORS for 2.7.28
updated CHANGELOG for 2.7.28
This PR was merged into the 3.3 branch.
Discussion
----------
[EventDispatcher] Handle laziness internally instead of relying on ClosureProxyArgument
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22970
| License | MIT
| Doc PR | -
If we decide to go this way, we might drop ClosureProxyArgument entirely because we won't need it internally. I'll propose it in another PR for discussion if this one is accepted.
This PR allows "high-order" listeners, as `array(Closure, method)`. Closure is called to get the actual instance when needed only.
How does it look to you? (I'll add tests once confirmed)
Commits
-------
c17a009d66 [EventDispatcher] Handle laziness internally instead of relying on ClosureProxyArgument
This PR was merged into the 3.3 branch.
Discussion
----------
[Routing] Allow GET requests to be redirected. Fixes#23004
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #23004
| License | MIT
| Doc PR | NA
GET requests didn't get the same redirect treatment as HEAD requests. I've also added tests cases for all the different trailing/non-trailing slash situations.
Commits
-------
71d4e366a9 [Routing] Allow GET requests to be redirected. Fixes#23004
This PR was squashed before being merged into the 3.3 branch (closes#22965).
Discussion
----------
[Cache] Ignore missing annotations.php
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes (different in 3.2)
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->
Avoids the following notices if cache is not warmed up (i.e. `cache:clear --no-warmup` > hit the browser).
```
Warning: include(<base-path>/app/cache/<env>/annotations.php): failed to open stream: No such file or directory
Warning: include(): Failed opening '<base-path>/app/cache/<env>/annotations.php' for inclusion (include_path='.:/usr/share/pear:/usr/share/php')
```
Commits
-------
e8f70c75b9 [Cache] Ignore missing annotations.php
This PR was squashed before being merged into the 3.3 branch (closes#22993).
Discussion
----------
[DI] Autowiring exception thrown when inlined service is removed
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | yes
| Deprecations? | yes (on a new & internal method)
| Tests pass? | yes
| Fixed tickets | #22977
| License | MIT
| Doc PR | n/a
We suppress autowiring exceptions if a service is ultimately removed from the container. This fixes a bug where we incorrectly report that a service was NOT removed, when really, it WAS removed. This happens when `ServiceA` is inlined in `ServiceB`... but then `ServiceB` is removed from the container for being unused.
Commits
-------
793b9a001f [DI] Autowiring exception thrown when inlined service is removed
This PR was merged into the 3.3 branch.
Discussion
----------
Better DI type deprecation message
| Q | A
| ------------- | ---
| Branch? | 3,3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22951
| License | MIT
| Doc PR | n/a
This is the most common autowiring deprecation:
```php
public function __construct(UserPasswordEncoder $encoder)
```
You *should* type-hint `UserPasswordEncoderInterface`
Current deprecation message:
> Autowiring services based on the types they implement is deprecated since Symfony 3.3 and won’t be supported in version 4.0. You should rename (or alias) the "security.user_password_encoder.generic" service to "Symfony\Component\Security\Core\Encoder\UserPasswordEncoder" instead.
Updated message:
> Autowiring services based on the types they implement is deprecated since Symfony 3.3 and won't be supported in version 4.0. Try changing the type-hint for argument "$encoder" of method "AppBundle\Service\TestServiceSubscriber::__construct()" to "Symfony\Component\Security\Core\Encoder\UserPasswordEncoderInterface" instead.
This only happens if we detect that there is a service/alias in the container (e.g. `...\UserPasswordEncoderInterface`) for the type-hint (`...\UserPasswordEncoder)`. Otherwise, if there is no correct type-hint in the container, we give the old recommendation (about aliasing).
The only complex case (of giving good directions on *where* to fix things) is with a class that implements `ServiceSubscriberInterface` (where the type-hint is in the `getSusbcribedServices()` method). In that case, the notice is:
> Autowiring services based on the types they implement is deprecated since Symfony 3.3 and won't be supported in version 4.0. Try changing the type-hint for "Symfony\Component\Security\Core\Encoder\UserPasswordEncoder" in "AppBundle\Service\TestServiceSubscriber" to "Symfony\Component\Security\Core\Encoder\UserPasswordEncoderInterface" instead.
Commits
-------
a990d5c558 Improving deprecation message when hitting the "deprecated type" lookup, but an alias is available
This PR was merged into the 3.3 branch.
Discussion
----------
[Config] Allow empty globs
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22950
| License | MIT
| Doc PR | -
This considers globs as valid even if they return no matches when they have a prefix (and when that prefix exists, according to `$ignoreErrors`).
This means there is an edge-case:
`*.abc` with at least one match is OK, but when it has no match, it falls back to regular import, then usually will fil.
But rewriting this to `./*.abc` resolves the ambiguity and turns this into a glob that won't fail if no matches are found.
This should provide the expected behavior in most cases (but ambiguous described one of course).
Commits
-------
c5b9c1a8c8 [Config] Allow empty globs
This PR was merged into the 3.3 branch.
Discussion
----------
[HttpKernel] Support unknown format in LoggerDataCollector
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22952
| License | MIT
| Doc PR | ~
The new expected format for the compiler log is `CompilerPassClass: Message`. However, this is not enforced by the old logging method as seen in schmittjoh/JMSDiExtraBundle#276
This PR adds the ability to read those lines without crashing with `Uncaught Notice: Undefined offset: 1`.
Please note that I have not tested this in an application so testers are welcome to confirm this fix!
Commits
-------
a8dfbb1180 Support unknown compiler log format
This PR was merged into the 3.3 branch.
Discussion
----------
[DI] Don't throw Autowire exception for removed service with private __construct
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | none (was talking to a user)
| License | MIT
| Doc PR | n/a
Suppose you have:
```php
class A
{
private function construct() {}
}
```
This service will fail to be autowired. But, like other autowiring failures, if this service will ultimately be removed from the container, this exception should be ignored. This fixes that. Unless someone is using the `AutowirePass` directly inside a `try/catch`, there is no BC break (the behavior change is that the exception is now stored, instead of being thrown).
This also clarifies (in the test & phpdoc) that `AutowirePass` always throws `AutowiringFailedException`s.
Thanks!
Commits
-------
2d3e44e11e Fixing a bug where an autowiring exception was thrown even when that service was removed
This PR was squashed before being merged into the 3.3 branch (closes#22968).
Discussion
----------
[Profiler] Fix text selection & click on file links on exception pages
| Q | A
| ------------- | ---
| Branch? | 3.3 <!-- see comment below -->
| Bug fix? | yes
| New feature? | no <!-- don't forget updating src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | no <!-- don't forget updating UPGRADE-*.md files -->
| Tests pass? | yes
| Fixed tickets | #22957, #22978 <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | N/A
I don't really know the purpose of this css rule here, but I admit it's quite frustrating not to be able to select something here.
This PR also prevents the following annoying behavior (selecting text collapses/uncollapses traces):
![mai-30-2017 18-26-29](https://cloud.githubusercontent.com/assets/2211145/26593977/3afbc510-4566-11e7-9114-8934ba6126a2.gif)
About the trick used, I think the browser support is safe enough: https://caniuse.com/#search=window.getSelection
EDIT: new commit added which allows to fix#22978
Commits
-------
8618399e42 [Profiler] Fix clicking on links inside toggle
ff6151b15f [Profiler] Fix text selection on exception pages
The specific report was for a service with a private constructor. This also clarifies
that the AutowirePass throws AutowiringFailedException for all situations. And a bug
was fixed in the constructor of AutowiringFailedException
* 3.2:
[Console] ChoiceQuestion must have choices
[Filesystem] improve error handling in lock()
[FrameworkBundle][Console] Fix the override of a command registered by the kernel
* 2.8:
[Console] ChoiceQuestion must have choices
[Filesystem] improve error handling in lock()
[FrameworkBundle][Console] Fix the override of a command registered by the kernel
* 2.7:
[Console] ChoiceQuestion must have choices
[Filesystem] improve error handling in lock()
[FrameworkBundle][Console] Fix the override of a command registered by the kernel
This PR was squashed before being merged into the 2.7 branch (closes#22847).
Discussion
----------
[Console] ChoiceQuestion must have choices
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22842
| License | MIT
| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->
<!--
![image](https://cloud.githubusercontent.com/assets/1047696/26301309/1bfa52ca-3ee1-11e7-883b-f627f16e9d2f.png)
-->
Commits
-------
96e307fd5c [Console] ChoiceQuestion must have choices
* 3.2:
typo
[Console] Fix tests
[Console] Fixed different behaviour of key and value user inputs in multiple choice question
[Cache] Dont use pipelining with RedisCluster
[Yaml] fix colon without space deprecation
[Intl] Fix intl tests for PHP < 5.5.10
This PR was merged into the 3.2 branch.
Discussion
----------
[Cache] Dont use pipelining with RedisCluster
| Q | A
| ------------- | ---
| Branch? | 3.é
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22922
| License | MIT
| Doc PR | -
phpredis doesn't support pipelining with RedisCluster
see https://github.com/phpredis/phpredis/blob/develop/cluster.markdown#pipelining
and multiple operations (MSET/MGET) work but only "per-shard".
We have to fetch keys one by one for now at least.
Commits
-------
eb93ac9 [Cache] Dont use pipelining with RedisCluster
This PR was squashed before being merged into the 2.7 branch (closes#22718).
Discussion
----------
[Console] Fixed different behaviour of key and value user inputs in multiple choice question
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22706
| License | MIT
| Doc PR | -
Fixed a bug when value from multiple choice list could not be selected by user's input
while it could be selected by typing its index in the list.
Commits
-------
2861bd7b01 [Console] Fixed different behaviour of key and value user inputs in multiple choice question
This PR was merged into the 3.3 branch.
Discussion
----------
[FrameworkBundle][Validator] Move the PSR-11 factory to the component
| Q | A
| ------------- | ---
| Branch? | 3.3 <!-- see comment below -->
| Bug fix? | no
| New feature? | no <!-- don't forget updating src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | yes <!-- don't forget updating UPGRADE-*.md files -->
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/22887#issuecomment-303765795 <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | N/A
Instead of the 3 following deprecations:
* The `ConstraintValidatorFactory::$validators` and `$container` properties
have been deprecated and will be removed in 4.0.
* Extending `ConstraintValidatorFactory` is deprecated and won't be supported in 4.0.
* Passing an array of validators or validator aliases as the second argument of
`ConstraintValidatorFactory::__construct()` is deprecated since 3.3 and will
be removed in 4.0. Use the service locator instead.
I'd suggest simply deprecating the FrameworkBundle's class in favor of using a new `ContainerConstraintValidatorFactory`. To me, there is no reason anyone using the validator component without the framework bundle cannot use this PSR-11 compliant implementation, nor I see a reason to make it final.
Commits
-------
68c1917af9 [FrameworkBundle][Validator] Move the PSR-11 factory to the component
This PR was merged into the 3.3 branch.
Discussion
----------
[HttpKernel] Fix kernel.project_dir extensibility
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/22727
| License | MIT
| Doc PR | n/a
Alternative to #22727 that makes use of the existing public api.
Commits
-------
3230fc7e70 Fix kernel.project_dir extensibility
This PR was merged into the 3.2 branch.
Discussion
----------
[Yaml] fix colon without space deprecation
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
A colon after a mapping key that is not followed by a space is valid if the mapping key is quoted.
Commits
-------
57f6941e25 [Yaml] fix colon without space deprecation
* 3.2:
[DI] Avoid private call to Container::has()
Fixing missing abstract attribute in XmlDumper
[Form] Remove DateTimeToStringTransformer $parseUsingPipe option
Fix file perms
Fixed filename in help text for update-data.php
* 2.8:
Fixing missing abstract attribute in XmlDumper
[Form] Remove DateTimeToStringTransformer $parseUsingPipe option
Fix file perms
Fixed filename in help text for update-data.php
* 2.7:
Fixing missing abstract attribute in XmlDumper
[Form] Remove DateTimeToStringTransformer $parseUsingPipe option
Fix file perms
Fixed filename in help text for update-data.php
This PR was merged into the 2.7 branch.
Discussion
----------
Fix missing abstract key in XmlDumper
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | none
| License | MIT
| Doc PR | n/a
Unless I'm missing something, the abstract key was missing in the XmlDumper. I noticed it when using `debug:container some_abstract_service` and was seeing "no" for abstract.
When this merges to 3.3, the `services-abstract.xml` will need to change to this:
```xml
<?xml version="1.0" encoding="utf-8"?>
<container xmlns="http://symfony.com/schema/dic/services" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://symfony.com/schema/dic/serviceshttp://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service id="service_container" class="Symfony\Component\DependencyInjection\ContainerInterface" synthetic="true"/>
<service id="foo" class="Foo" abstract="true"/>
<service id="Psr\Container\ContainerInterface" alias="service_container" public="false"/>
<service id="Symfony\Component\DependencyInjection\ContainerInterface" alias="service_container" public="false"/>
</services>
</container>
```
Commits
-------
40f60ec60d Fixing missing abstract attribute in XmlDumper
This PR was merged into the 3.3 branch.
Discussion
----------
[HttpFoundation] Add Request::HEADER_X_FORWARDED_AWS_ELB const
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes (a missing part of a 3.3 feat.)
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
See https://github.com/symfony/symfony-docs/issues/7045
Commits
-------
9ba12b0d2a [HttpFoundation] Add Request::HEADER_X_FORWARDED_AWS_ELB const
This PR was merged into the 3.3 branch.
Discussion
----------
[HttpKernel] don't call getTrustedHeaderName() if possible
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://travis-ci.org/symfony/symfony/jobs/235008102 (failing tests of #22863)
| License | MIT
| Doc PR |
Commits
-------
6350dab don't call getTrustedHeaderName() if possible
This PR was merged into the 3.3 branch.
Discussion
----------
[ProxyManager] Add FC layer
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | no
| New feature? | no
| BC breaks? | yes - minor
| Deprecations? | yes - made a class final
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
This makes PRoxyDumper compatible with DumperInterface v4.0.
Technically, this is a BC break, but since I really don't expect anyone to extend ProxyDumper, I think we should do it - on 3.3 to close the gap as early as possible.
Commits
-------
4aeb6d8 [ProxyManager] Add FC layer
This PR was merged into the 3.2 branch.
Discussion
----------
[DI] Check for privates before shared services
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/22801#discussion_r117732213, https://github.com/symfony/symfony/pull/22801#discussion_r117732599
| License | MIT
| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->
cc @stof
Commits
-------
4f683a9a5b [DI] Check for privates before shared services
This PR was submitted for the 3.4 branch but it was merged into the 3.3 branch instead (closes#22818).
Discussion
----------
[DependencyInjection] prepare for signature change in 4.0
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
see failing tests in #22785
Commits
-------
c4b6e20 [DI] prepare for signature change in 4.0
This PR was squashed before being merged into the 3.3 branch (closes#22857).
Discussion
----------
[DI] Fix autowire error for inlined services
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22848
| License | MIT
| Doc PR | n/a
The `AutowirePass` defers autowiring exceptions until later so that we don't throw autowiring exceptions for services that are ultimately removed. But, if a service is *inlined*, then it appears to be removed, and so we don't throw the exception. This fixes that.
It's an easy fix - but it's a bit ugly. We're adding a bit more "state" to the passes... simply because there is some information that needs to be shared through the compiler process. There might be a better way of doing this in the future (e.g. storing some metadata on the `Compiler`), but this *does* work well.
Commits
-------
4bcef3d [DI] Fix autowire error for inlined services
This PR was merged into the 3.3 branch.
Discussion
----------
[Process] Fixed escaping arguments on Windows when inheritEnvironmentVariables is set to false
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | no
| Fixed tickets |
| License | MIT
| Doc PR |
I've added a FAILING testcase on Windows. It incorrectly substitutes an argument containing a quotation mark probably assuming it's an env var needed to backup when inheritEnvironmentVariables is set to false.
Commits
-------
26032ef [Process] Fixed incorrectly escaping arguments on Windows when inheritEnvironmentVariables is set to false
This PR was merged into the 3.3 branch.
Discussion
----------
[FrameworkBundle][Translation] fix docblock position
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22822
| License | MIT
| Doc PR |
The `$defaultLocale` argument is present in the `Translator` class of
the FrameworkBundle, but is not part of the Translation component.
Commits
-------
0829964 fix docblock position
This PR was merged into the 3.3 branch.
Discussion
----------
[DI] Remove dead service_container checks
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->
Since #21627
Commits
-------
9a8ea93 [DI] Remove dead service_container checks
This PR was merged into the 3.3 branch.
Discussion
----------
[Security][Serializer][DI] Add new arguments typehints in preparation for 4.0
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/22743#pullrequestreview-38950305
| License | MIT
| Doc PR | N/A
See https://github.com/symfony/symfony/pull/22743#pullrequestreview-38950305 discussion for the motivations.
Commits
-------
b973b30 [Security][Serializer][DI] Add new arguments typehints in preparation for 4.0
This PR was merged into the 3.2 branch.
Discussion
----------
[DI] Added missing deprecation in changelog
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->
See #20113
Commits
-------
b3d58c5 [DI] Added missing deprecation in changelog
This PR was squashed before being merged into the 2.7 branch (closes#22748).
Discussion
----------
[Intl] Fix bin/common.php PHP7 compatibility
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22735
| License | MIT
Created for Symfony 2.7 version which is the oldest maintained impacted branch.
Commits
-------
c2ccf36 [Intl] Fix bin/common.php PHP7 compatibility
* 3.2:
removed unneeded annotation in tests
[Intl][Form] Update tests, TimeZoneTransformer, and DateTimeToLocalizedStringTransformer for the GMT and UTC split in ICU
remove Security deps from the require section
[Intl] Update ICU data to 59.1
* 2.8:
[Intl][Form] Update tests, TimeZoneTransformer, and DateTimeToLocalizedStringTransformer for the GMT and UTC split in ICU
[Intl] Update ICU data to 59.1
* 2.7:
[Intl][Form] Update tests, TimeZoneTransformer, and DateTimeToLocalizedStringTransformer for the GMT and UTC split in ICU
[Intl] Update ICU data to 59.1
This PR was squashed before being merged into the 2.7 branch (closes#22627).
Discussion
----------
[Intl] Update ICU data to 59.1
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
The [GMT timezone has been split from the UTC](http://site.icu-project.org/download/59) timezone [in CLDR](http://cldr.unicode.org/index/downloads/cldr-31) (which ICU is based on).
For example, the code blow:
* before ICU 59.1 would return "GMT" in all cases
* with ICU 59.1 it returns "UTC" for the first three ('z', 'zz', 'zzz')
and "Coordinated Universal Time" for the last two ('zzzz', 'zzzzz').
```php
foreach (['z', 'zz', 'zzz', 'zzzz', 'zzzzz'] as $pattern) {
$formatter = new \IntlDateFormatter('en', IntlDateFormatter::MEDIUM, IntlDateFormatter::SHORT, new \DateTimeZone('UTC'), IntlDateFormatter::GREGORIAN, $pattern);
var_dump($formatter->format(new \DateTime('@0')));
}
```
Similarly Form's `DateTimeToLocalizedStringTransformer` is also affected:
```php
$transformer = new DateTimeToLocalizedStringTransformer('UTC', 'UTC', null, \IntlDateFormatter::FULL);
var_dump($transformer->transform(new \DateTime('2010-02-03 04:05:06 UTC')));
// ICU 58.2: '03.02.2010, 04:05:06 GMT'
// ICU 59.1: '03.02.2010, 04:05:06 Koordinierte Weltzeit'
```
Refer to added and modified test cases for more changes. I split this PR in two commits for easier review. First commit updates ICU data (generated files), the second updates code and test cases to be compatible with updated data.
Commits
-------
5d3d1b25e0 [Intl][Form] Update tests, TimeZoneTransformer, and DateTimeToLocalizedStringTransformer for the GMT and UTC split in ICU
00acb37205 [Intl] Update ICU data to 59.1
The [GMT timezone has been split from the UTC](http://site.icu-project.org/download/59) timezone [in CLDR](http://cldr.unicode.org/index/downloads/cldr-31) (which ICU is based on).
For example, the code blow:
* before ICU 59.1 would return "GMT" in all cases
* with ICU 59.1 it returns "UTC" for the first three ('z', 'zz', 'zzz')
and "Coordinated Universal Time" for the last two ('zzzz', 'zzzzz').
```php
foreach (['z', 'zz', 'zzz', 'zzzz', 'zzzzz'] as $pattern) {
$formatter = new \IntlDateFormatter('en', IntlDateFormatter::MEDIUM, IntlDateFormatter::SHORT, new \DateTimeZone('UTC'), IntlDateFormatter::GREGORIAN, $pattern);
var_dump($formatter->format(new \DateTime('@0')));
}
```
Similarly Form's `DateTimeToLocalizedStringTransformer` is also affected:
```php
$transformer = new DateTimeToLocalizedStringTransformer('UTC', 'UTC', null, \IntlDateFormatter::FULL);
var_dump($transformer->transform(new \DateTime('2010-02-03 04:05:06 UTC')));
// ICU 58.2: '03.02.2010, 04:05:06 GMT'
// ICU 59.1: '03.02.2010, 04:05:06 Koordinierte Weltzeit'
```
Refer to added and modified test cases for more changes. I split this PR in two commits for easier review. First commit updates ICU data (generated files), the second updates code and test cases to be compatible with updated data.
* 3.2:
Fix errors not rethrown even if not handled by console.error listeners
[VarDumper] Fix dumping of non-nested stubs
[Security] Avoid unnecessary route lookup for empty logout path
respect inline level when dumping objects as maps
Test case for not in-lined map-objects
* 2.8:
Fix errors not rethrown even if not handled by console.error listeners
[VarDumper] Fix dumping of non-nested stubs
[Security] Avoid unnecessary route lookup for empty logout path
* 2.7:
Fix errors not rethrown even if not handled by console.error listeners
[VarDumper] Fix dumping of non-nested stubs
[Security] Avoid unnecessary route lookup for empty logout path
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Process] Fix incorrectly calling PHP process when path contains space
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22556
| License | MIT
I have PHP installed at "D:\Program Files\PHP" which contains a space. `PhpExecutableFinder` found it but then `PhpProcess` splitted the path by space. This PR fixes it. I wanted to write a test but I don't know ho to do it properly since it is dependent on the location where PHP is installed and I can't even mock `PhpExecutableFinder` because it is hardcoded dependency and an implementation detail.
Commits
-------
9c08109 Fix incorrectly calling PHP process on Windows when path contains space
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Fixing missing "exclude" functionality from PSR4 loader
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | none
| License | MIT
| Doc PR | TODO
When the PSR4 loader was added in #21289, @nicolas-grekas said this:
> given that glob() is powerful enough to include/exclude dirs, I removed the Test special exclusion (source: https://github.com/symfony/symfony/pull/21289#issuecomment-272821106)
But, I don't believe that's true! [Glob is all about inclusion, not exclusion](https://en.wikipedia.org/wiki/Glob_(programming)#Syntax) - the maximum you can exclude is a single character. Thus, I've marked this as a bug.
My motivation came from upgrading KnpU to the new 3.3 DI stuff. We have many directories (40) in `src/`, and listing them all one-by-one in `resource:` is crazy - the `resource` line would be ~350 characters long and quite unreadable. What I really want to do is include *everything* and then exclude few directories. I tried to do this with `glob`, but it's not possible.
This PR allows for something like this:
```yml
services:
_defaults:
public: false
# ...
AppBundle\:
resource: '../../src/AppBundle/*'
exclude: '../../src/AppBundle/{AppBundle.php,Entity}'
```
This works *beautifully* in practice. And even if I forget to exclude a directory - since the services are private - **they're ultimately removed from the container anyways**. In fact, the *only* reason I need to exclude *anything* is because of the new "service argument resolver", which causes entities to not be properly removed from the compiled container.
Thanks!
Commits
-------
7d07f19459 Allowing prototype/PSR4 service loading ability to exclude, because glob doesn't support this
Security-core no longer directly depends upon polyfill-util since #16382.
This does not change the existing dependancy tree as polyfill-util is
transitivly depended on via polyfill-php56.
This PR was merged into the 3.2 branch.
Discussion
----------
[Yaml] respect inline level when dumping objects as maps
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22392
| License | MIT
| Doc PR |
Commits
-------
3cca48c715 respect inline level when dumping objects as maps
4f5c149798 Test case for not in-lined map-objects
This PR was merged into the 2.7 branch.
Discussion
----------
[Security] Avoid unnecessary route lookup for empty logout path
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes
| New feature? | no
| BC breaks? | no-ish
| Deprecations? | no
| Tests pass? | yes/no
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->
i first included this with #22572 where having `logout: { path: ~ }` makes more sense for disabling logout path matching/generation. But currently it's already allowed and causes an unneeded route lookup and url generation.
Commits
-------
2967807b14 [Security] Avoid unnecessary route lookup for empty logout path
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DX] Making the RegisterControllerArgumentLocatorsPass throw exception on bad types
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | maybe
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | none
| License | MIT
| Doc PR | n/a
Suppose you type-hint a controller arg with a non-existent class:
```php
public function fooAction(FakeClass $foo)
```
Current error:
> Class AppBundle\Controller\FakeClass does not exist
(from `ParamConverterListener`, and only when you hit that route)
New error:
> Cannot determine controller argument for "AppBundle\Controller\BlogController::indexAction()
": the $foo argument is type-hinted with the non-existent class or interface: "AppBundle\Con
troller\FakeClass". Did you forget to add a use statement?
(at build time)
The extra `Did you forget to add a use statement?` only shows up if it appears you likely forgot a `use` statement.
I think this will be a really common error (especially forgetting the `use` statement)... so let's make it a *really* nice error! An alternative would be to enhance the args resolver to throw a clearer exception when no arg can be wired and the type-hint is bad (we would also need to make the `ParamConverterListener` stop throwing the current error... so that the args resolver would have the opportunity to do that. Disadvantage would be that this error would only happen when you hit the route, not at build time.
Cheers!
Commits
-------
22b905226d Making the RegisterControllerArgumentLocatorsPass throw an exception on a bad type-hint
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Security] Fix TraceableAccessDecisionManager / DebugAccessDecisionManager BC layer
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/22657#issuecomment-299728726
| License | MIT
| Doc PR | N/A
Same as #22657 for the renaming of `DebugAccessDecisionManager` into `TraceableAccessDecisionManager`. Indeed, I think we also require to redeclare the old `DebugAccessDecisionManager` for composer `classmap-authoritative` autoloading strategy & classmap dumper.
AppVeyor failures unrelated.
Edit: Re-thinking about it, it's probably not very common to dump the classmap and use the `classmap-authoritative` strategy when using those classes... That's to say: in debug mode/dev env. So it may be the reason why the class wasn't redeclared on contrary of `DefinitionDecorator`.
Commits
-------
5b123b9674 [Security] Fix TraceableAccessDecisionManager / DebugAccessDecisionManager BC layer
This PR was merged into the 3.3-dev branch.
Discussion
----------
Fixing a bug where abstract classes were wired with the prototype loader
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | none
| License | MIT
| Doc PR | n/a
The prototype/PSR-4 loader currently tries to wire abstract classes. The problem is if, for example, you have, for example:
```php
abstract class BaseCommand extends Command
{
}
```
If this is registered as a service, and you have `autoconfigure`, then the console `Application` will try to use this a command.
Was there some reason abstract classes were originally allowed to be registered as services with the PSR4/prototype loader? I don't know if there is a real use-case for registering abstract classes. If you wanted to use that service as a parent service... then you'll probably be configuring it yourself anyways. We could also fix this by changing all tags compiler passes to skip classes that are abstract... *if* there is a use-case for Abstract classes being auto-registered.
Cheers!
Commits
-------
5326bab10a Fixing a bug where abstract classes were wired
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Do not throw autowiring exceptions for a service that will be removed
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no (arguable)
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Hi guys!
tl;dr Do no throw a "Cannot autowire service id foo_bar" if that service (`foo_bar`) is private and is ultimately removed from the container.
I ran into a problem with the new PSR-4 service loader: our existing projects often contains directories with a mixture of services and model classes. In reality, that's not a problem: since the services are private, if any "extra" classes are registered as service, they're removed from the container because they're not referenced. In other words, the system is great: model classes do *not* become services naturally... because nobody tries to inject them as services.
However, if your model classes have constructor args... then things blow up on compilation. This fixes that: it delays autowiring errors until after `RemoveUnusedDefinitionsPass` runs and then does *not* throw those exceptions if the service is gone.
Cheers!
Commits
-------
f4913feaa8 Fixing a bug where services that were eventually removed could cause autowire errors
* 3.2:
[Console] Do not duplicate Helper::strlen() code
[FrameworkBundle] Adding the extension XML
[Form] Minor: Fix comment in ChoiceType
[FrameworkBundle] AbstractConfigCommand: do not try registering bundles twice
fixed CS
fixed CS
[DI] Fix PhpDumper blank lines around namespace
fixed CS
[Workflow] fix use directives
[Workflow] Move twig extension registration to twig bundle
Filesystem: annotate the one network test with a "network" group.
[DependencyInjection] Don't store default deprecation template in every service definition instance
* 2.8:
[Console] Do not duplicate Helper::strlen() code
[FrameworkBundle] Adding the extension XML
[Form] Minor: Fix comment in ChoiceType
[FrameworkBundle] AbstractConfigCommand: do not try registering bundles twice
* 2.7:
[Console] Do not duplicate Helper::strlen() code
[FrameworkBundle] Adding the extension XML
[Form] Minor: Fix comment in ChoiceType
[FrameworkBundle] AbstractConfigCommand: do not try registering bundles twice
This PR was merged into the 2.7 branch.
Discussion
----------
[Console] Do not duplicate Helper::strlen() code
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
Commits
-------
01c2c099a4 [Console] Do not duplicate Helper::strlen() code
This PR was merged into the 3.2 branch.
Discussion
----------
[Workflow] fix use directives
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
Spotted while creating https://github.com/symfony/symfony/pull/22652
Commits
-------
08f4ad2275 [Workflow] fix use directives
* 2.8:
fixed CS
[DI] Fix PhpDumper blank lines around namespace
fixed CS
Filesystem: annotate the one network test with a "network" group.
[DependencyInjection] Don't store default deprecation template in every service definition instance
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Fix Cannot declare class ...\DefinitionDecorator, because the name is already in use
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #21369
| License | MIT
| Doc PR | N/A
The `return` trick doesn't seem to work, and php is still trying to declare the `DefinitionDecorator` class, which causes the "Cannot declare class ...\DefinitionDecorator, because the name is already in use" error because of the `class_alias` previously declared in `ChildDefinition.php`.
This never happens as soon as the `ChildDefinition` class is used first, as the alias will take hand, but their are some situations, like in some unit test cases it can happen apparently, because `DefinitionDecorator` is used first.
Commits
-------
530849e4b5 [DI] Fix Cannot declare class ...\DefinitionDecorator, because the name is already in use
Tests that require network access can be problematic, because they
depend on some external state not under your control. That can lead to
"random" failures when the code in question actually works fine. The
Filesystem component has one such test, and this commit adds it to the
"network" group (for PHPUnit).
Doing so lets the user skip that particular test, by running phpunit
with the --exclude-group flag. We take advantage of this in Gentoo,
where every user has the ability to run the test suite but network
access is forbidden.
* 3.2:
[appveyor] Run the test suite on PHP 7.1
[appveyor][3.x] Run the test suite on PHP 7.1
[EventDispatcher] fix merge of #22541 from 2.8
bumped Symfony version to 3.2.9
updated VERSION for 3.2.8
updated CHANGELOG for 3.2.8
bumped Symfony version to 2.8.21
updated VERSION for 2.8.20
updated CHANGELOG for 2.8.20
bumped Symfony version to 2.7.28
updated VERSION for 2.7.27
update CONTRIBUTORS for 2.7.27
updated CHANGELOG for 2.7.27
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Config] Fix resource tracking with new GlobResource
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Right now, resource tracking is done via tracking of directories mtimes, which means a container is rebuilt each time a file is either removed or added, but not when an existing file is modified.
This looks nice on the surface.
BUT.
Most code editors do create a temporary file when you open your code, thus change the parent dir mtime, thus trigger a container rebuild.
When working with PSR-4 loaders, this means each time you just open a file, most of you will trigger a container rebuild.
This is bad :(
Here is a new GlobResource to fix this issue.
Commits
-------
9190e108c1 [Config] Fix resource tracking with new GlobResource
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Defaults to public=false in all service config files
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
This is what we call "eating your own dog food" :)
Made me realize that we need a tweak to the defaults<>ChildDefinition conflict we have now:
tags should be applied, and there should be *no* conflict when everything is set *explicitly* on the child definition.
Commits
-------
0656284f7f [DI] Defaults to public=false in all service config files
This PR was merged into the 3.2 branch.
Discussion
----------
[EventDispatcher] fix merge of #22541 from 2.8
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
This cleans up a test case that was merged from 2.8 into 3.2 here: 824dc8ba5f
@fabpot due to different implementations I created 2 PR's:
2.8: https://github.com/symfony/symfony/pull/22541
3.2: https://github.com/symfony/symfony/pull/22568
So the 2.8 merge into 3.2 of my change-set introduced some unused variable `$isWrapped` here: 824dc8ba5f (diff-af3c4fbca8bb77957c00087543ae5a4dR113)
This PR just cleans it up and also removes the data provider 😉
Commits
-------
f67eba8 [EventDispatcher] fix merge of #22541 from 2.8
* 3.2:
fixed tests
fixed merge
Fix minor phpdoc mismatches with the code(detected by phan)
[Asset] Starting slash should indicate no basePath wanted
[Security] Fix phpdoc logout listener
[EventDispatcher] fix getting priorities of listeners during dispatch
Add iconv extension to suggested dependencies
Fix minor typo in the main README.md
Allow Upper Case property names in ObjectNormalizer
[EventDispatcher] fix: unwrap listeners for correct info
* 2.8:
Fix minor phpdoc mismatches with the code(detected by phan)
[Asset] Starting slash should indicate no basePath wanted
[Security] Fix phpdoc logout listener
Add iconv extension to suggested dependencies
Fix minor typo in the main README.md
Allow Upper Case property names in ObjectNormalizer
[EventDispatcher] fix: unwrap listeners for correct info
* 2.7:
Fix minor phpdoc mismatches with the code(detected by phan)
[Asset] Starting slash should indicate no basePath wanted
[Security] Fix phpdoc logout listener
Fix minor typo in the main README.md
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Profiler] DataCollector: Remove unused static property
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
Unless I missed something, any usage of this property were removed in https://github.com/symfony/symfony/pull/21638.
Commits
-------
96743e69ad [Profiler] DataCollector: Remove unused static property
Now that inherit_tags has been removed, 3.3 has the same functionality as 3.2: tags
are *never* cascaded from parent to child (but you tags do inherit from defaults
to a service and instanceof to a service).
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Security] json login listener: ensure a json response is sent on bad request
| Q | A
| ------------- | ---
| Branch? | master (3.3)
| Bug fix? | yesish
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
I would have simply recommended to set the proper format when declaring the route:
```yml
# routing.yml
api_login:
path: /login
defaults: { _format: json }
```
but, since https://github.com/symfony/symfony/pull/22477 has been merged, and considering https://github.com/symfony/symfony/pull/22477#issuecomment-295897629:
> my point above regarding checking the content type is so that one could use form_login and json_login in parallel on the same routes and within the same firewall
we may consider setting the request format to json when throwing the `BadRequestHttpException`, so used conjointly with the TwigBundle, the exception is rendered using the `exception.json.twig` template.
ping @lsmith77
(An alternative would be to check the Accept header to set the request format to json if it's the preferred one instead of doing it each time we throw the exception. But Symfony never used such content negotiation AFAIK, and I think it's safe enough to assume someone sending json is expecting json as ouput for exceptions.)
Commits
-------
4427cf9157 [Security] json login listener: ensure a json response is sent on bad request
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Throw useful exception on bad XML argument tags
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22525
| License | MIT
| Doc PR | -
I still think that the feature request in #22525 would make things better.
But at least, let's make thing fail loudly, instead of silently today, with the associated usual wtfs :)
Commits
-------
91828ecd17 [DI] Throw useful exception on bad XML argument tags
This PR was squashed before being merged into the 2.7 branch (closes#22453).
Discussion
----------
Fix minor phpdoc mismatches with the code(detected by phan)
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | none
| License | MIT
| Doc PR | no
Fix minor mismatches between phpdoc and the type of the code itself, detected by etsy/phan (Prevent confusion in the future)
The actual return types of a few functions have changed from int to bool where preg_match or `&` was used.
Fix optional param before required param in src/Symfony/Component/Serializer/Normalizer/AbstractObjectNormalizer.php
The config used and the rest of the output is at https://gist.github.com/TysonAndre/91bed0e16583301f1e6e5cc2a4807081 (Uses some patches to etsy/phan that weren't merged to master yet)
Commits
-------
12f1239565 Fix minor phpdoc mismatches with the code(detected by phan)
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Security] add Request type json check in json_login
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no, unreleased feature
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR | -
follow up to https://github.com/symfony/symfony/pull/22425 to limit the `UsernamePasswordJsonAuthenticationListener` to only requests with appropriate JSON content type.
I am not entirely happy with this implementation but mostly because Symfony out of the box only provides very limited content type negotiation. I guess anyone that wants to tweak the content negotiation will simply need to ensure the Request::$format is set accordingly before the code is triggered.
Commits
-------
045a36b303 add Request type json check in json_login
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Serializer] Add missing normalizer options constants
| Q | A
| ------------- | ---
| Branch? | master (3.3)
| Bug fix? | not really
| New feature? | yesish, but for 3.3 as those options were added on this branch and not released yet
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/22537#discussion_r113719848
| License | MIT
| Doc PR | N/A
As seen in https://github.com/symfony/symfony/pull/22537#discussion_r113719848.
@dunglas : I'm not sure about the exposing the `key_type` option as a constant in `ArrayDenormalizer`/`AbstractObjectNormalizer`, as it looks more or less like a detail of the AbstractObjectNormalizer implementation, but anyway it should be in 3.2 if we add it, so I haven't included it here.
However, I wonder if this option shouldn't directly accept a string too, rather than just a `Symfony\Component\PropertyInfo\Type` instance if we want to consider this option "public"?
Commits
-------
b0c414f2c8 [Serializer] Add missing normalizer options constants
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Serializer] Allow to pass csv encoder options in context
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
CSV contents typically are provided by one or many third-parties, not always allowing you to get control over the provided format. In case you need to import csv files with different formats, either you have to instantiate a decoder yourself/inject it instead of the main serializer instance, either you need another serializer instance with a differently configured csv encoder registered within.
This PR allows to configure any encoder option through the context, so you can keep injecting and using the same serializer instance.
Commits
-------
10a76aac15 [Serializer] Allow to pass csv encoder options in context
This PR was merged into the 2.8 branch.
Discussion
----------
Allow Upper Case property names in ObjectNormalizer
| Q | A
| ------------- | ---
| Branch? | 2.8
| Bug fix? | yes
| New feature? | no
| BC breaks? | yes
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22547
| License | MIT
Same problem that has been fixed here https://github.com/symfony/symfony/pull/22265
and here https://github.com/api-platform/core/pull/1037
ObjectNormalizer returns $id instead of $Id. It is bad naming convention, but is possible
```php
class Entity {
protected $Id;
public function getId()
{
return $this->Id;
}
}
```
Commits
-------
b2b4faa3c0 Allow Upper Case property names in ObjectNormalizer
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Security] Handle bad request format in json auth listener
| Q | A
| ------------- | ---
| Branch? | master (3.3)
| Bug fix? | yesish
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
In https://github.com/symfony/symfony/pull/22034, I wondered myself if we shouldn't throw a dedicated exception to handle bad formatted requests and give more inputs to the client by returning a 400 response with an explicit message.
~~Here is a suggestion, introducing a new `BadRequestFormatException` and using it in `UsernamePasswordJsonAuthenticationListener` whenever there is no custom failure handler set (but someone using its own handler should be able to treat the failure properly too).~~
As discussed with @chalasr , it seems better to directly throw a `BadRequestHttpException` as it's actually out of the whole security process. PR updated.
Commits
-------
93a8cb9cd4 [Security] Handle bad request format in json auth listener
This PR was squashed before being merged into the 3.3-dev branch (closes#22551).
Discussion
----------
[Process] Ecaping of CLI arguments containing slashes on Windows
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22549
| License | MIT
Actually only the first argument - the command needs to be escaped but that would need another condition. I think it should be OK.
Commits
-------
0d073128de [Process] Ecaping of CLI arguments containing slashes on Windows
This PR was merged into the 3.3-dev branch.
Discussion
----------
Not allowing autoconfigure, instanceofConditionals or defaults for ChildDefinition
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes (removing risky behavior)
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | see #22530
| License | MIT
| Doc PR | n/a
This PR *prohibits* using `autoconfigure`, `_instanceof` and `_defaults` for ChildDefinition.
Additionally, I added many "integration" test cases: we need to test and prove all edge cases. These are in the `integration/` directory: the `main.yml` file is parsed and compared to `expected.yml`. Both are in YAML to ease comparing the before/after. We need to check these out and make sure they're right and we're not missing anything else.
This PR removes MANY of the "wtf" cases, but there are still 4 that I know of... and of course they all deal with parent-child stuff :).
A) [MAJOR] [autoconfigure_parent_child_tags](https://github.com/symfony/symfony/pull/22563/files#diff-fd6cf15470c5abd40156e4e7dc4e7f6d) `instanceof` tags from autoconfigure are NEVER applied to the child (you can't set `autoconfigure` directly on a Child, but you still can set it on a parent and inherit it... sneaky). We could throw an Exception I suppose to prevent this `autoconfigure` from cascading from parent to child... but it's tricky due to `instanceof`.
B( [MAJOR] [instanceof_parent_child](https://github.com/symfony/symfony/pull/22563/files#diff-14666e9a25322d44b3c2c583b6814dc2) `instanceof` tags that are applied to the parent, are not applied to the child. Again, you can't set `instanceof` directly on a Child, but you *can* set it on a parent, and have that cascade to the child. Like before, we could maybe throw an exception to prevent this.
C) [MINOR] ([autoconfigure_child_not_applied](https://github.com/symfony/symfony/pull/22563/files#diff-3372a1dcaf3af30d14a7d0a6c8bfa988)) automatic `instanceof` will not be applied to the child when the parent class has a different (non-instanceof-ed) class. If we could throw an exception for (A), then it would cover this too.
D) `_tags` from defaults are never used (unless you have inherit_tags) - fixed in #22530
A, B & C are effectively caused by there being a "sneaky" way to re-enable `autoconfigure` and `instanceof` for ChildDefinition... which opens up wtf cases.
## Wait, why not support `_defaults`, `autoconfigure` and `_instanceof` for child definitions?
1 big reason: reduction of wtf moments where we arbitrarily decide override logic. PLUS, since `_defaults`, `instanceof` and `autoconfigure` *are* applied to parent definitions, in practice (other than tags), this makes no difference: the configuration will still pass from parent down to child.
Also, using parent-child definitions is already an edge case, and this *simply* prevents *just* those services from using the new features.
## Longer reasons why
The reason behind this is that parent-child definitions are a different mechanism for "inheritance"
than `_instanceof` and `_defaults`... creating some edge cases when trying to figure out which settings "win". For example:
```yml
# file1.yml
services:
_defaults:
public: false
ChildService:
parent: parent_service
# file2.yml
services:
_defaults:
public: true
ParentService: ~
```
Is `ChildDefinition` `public: true` (so the parent
overrides the child, even though it only came from _defaults) or `public: false` (where
the child wins... even though it was only set from its _defaults)?
Or, if ParentService is explicitly set to `public: true`, should that override the `public: false` of ChildService (which it got from its `_defaults`)? On one hand, ParentService is being explicitly
set. On the other hand, ChildService is explicitly in a file settings `_defaults` `public: false`
There's no correct answer.
There are also problems with `_instanceof`. The importance goes:
> defaults < instanceof < service definition
But how do parent-child relationships fit into that? If a child has public: false
from an _instanceof, but the parent explicitly sets public: true, which wins? Should
we assume the parent definition wins because it's explicitly set? Or would the
_instanceof win, because that's being explicitly applied to the child definition's
class by an _instanceof that lives in the same file as that class (whereas the parent
definition may live in a different file).
Because of this, @nicolas-grekas and I (we also talked a bit to Fabien) decided that
the complexity was growing too much. The solution is to not allow any of these
new feature to be used by ChildDefinition objects. In other words, when you want some
sort of "inheritance" for your service, you should *either* giving your service a
parent *or* using defaults and instanceof. And instead of silently not applying
defaults and instanceof to child definitions, I think it's better to scream that it's
not supported.
Commits
-------
a943b96d42 Not allowing autoconfigure, instanceofConditionals or defaults for ChildDefinition
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Console][HttpKernel] Avoid reflection-based registration for command public services
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/22410#issuecomment-298158585
| License | MIT
| Doc PR | n/a
By mapping commands ids by their alias in `console.command.ids` (even if the alias is not registered in the container for public services), then skipping reflection if the predictable alias exists as a key of `console.command.ids`.
Please note that the whole command service registration process is far from ideal.
I'm working on changing this for 3.4 in a transparent way regarding end users, leveraging PSR-11 to make the console component DI friendly, allowing to register commands as true private services (no more public aliases) and providing laziness for those.
Commits
-------
6c1b384b75 Avoid reflection-based registration for command public services
This PR was squashed before being merged into the 3.3-dev branch (closes#22564).
Discussion
----------
Fixing problem where _defaults set to null was seen as a service
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
```yml
services:
_defaults:
```
If you leave `_defaults` empty (i.e. null), you got a bad error before. Now it's better :)
Before:
>The definition for "_defaults" has no class. If you intend to inject this service dynamicall
y at runtime, please mark it as synthetic=true. If this is an abstract definition solely use
d by child definitions, please add abstract=true, otherwise specify a class to get rid of th
is error.
After:
> Service "_defaults" key must be an array, "NULL" given in "/path/to/services.yml"
Commits
-------
4b7e148a9b Fixing problem where _defaults set to null was seen as a service
This PR was squashed before being merged into the 2.7 branch (closes#22528).
Discussion
----------
[Asset] Starting slash should indicate no basePath wanted
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes-ish... and no-ish
| New feature? | no
| BC breaks? | yes
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
**Important** View the second commit for an accurate diff. The first commit just renames some strings in a test for clarity.
When we moved `PathPackage` from `Templating` to `Asset`, we actually changed its behavior. Assume that we're deployed under a `/subdir` subdirectory:
**Before** `{{ asset('/main.css') }}` would *not* have the base path prefixed -> `/main.css`
**After** `{{ asset('/main.css') }}` *does* have the base path prefixed -> `/subdir/main.css`
3adff11d72/src/Symfony/Component/Templating/Asset/PathPackage.php (L61-L63)
This PR simply reverses that, to the *previous* behavior. This *is* a BC break... and also arguably a bug fix :). Interestingly, when we changed the behavior the first time (i.e. broke BC), I don't think that anyone noticed. It should only affect users deployed under a subdirectory.
Why do I care? I'm using the new `JsonManifestVersionStrategy` with a library that is outputting paths that *already* include my subdirectory:
```json
{
"build/main.css": "/subdir/build/main.abc123.css"
}
```
So, I do not want Symfony to detect the `/subdir` and apply it a second time.
Commits
-------
3cc096b540 [Asset] Starting slash should indicate no basePath wanted
Also, not allowing arguments or method calls for autoconfigure. This is a safety
mechanism, since we don't have merging logic. It will allow us to add this in the
future if we want to.
The reason is that parent-child definitions are a different mechanism for "inheritance"
than instanceofConditionas and defaults... creating some edge cases when trying to
figure out which settings "win". For example:
Suppose a child and parent definitions are defined in different YAML files. The
child receives public: false from its _defaults, and the parent receives public: true
from its _defaults. Should the final child definition be public: true (so the parent
overrides the child, even though it only came from _defaults) or public: false (where
the child wins... even though it was only set from its _defaults). Or, if the parent
is explicitly set to public: true, should that override the public: false of the
child (which it got from its _defaults)? On one hand, the parent is being explicitly
set. On the other hand, the child is explicitly in a file settings _defaults public
to false. There's no correct answer.
There are also problems with instanceof. The importance goes:
defaults < instanceof < service definition
But how does parent-child relationships fit into that? If a child has public: false
from an _instanceof, but the parent explicitly sets public: true, which wins? Should
we assume the parent definition wins because it's explicitly set? Or would the
_instanceof win, because that's being explicitly applied to the child definition's
class by an _instanceof that lives in the same file as that class (whereas the parent
definition may live in a different file).
Because of this, @nicolas-grekas and I (we also talked a bit to Fabien) decided that
the complexity was growing too much. The solution is to not allow any of these
new feature to be used by ChildDefinition objects. In other words, when you want some
sort of "inheritance" for your service, you should *either* giving your service a
parent *or* using defaults and instanceof. And instead of silently not applying
defaults and instanceof to child definitions, I think it's better to scream that it's
not supported.