This PR was squashed before being merged into the 3.3-dev branch (closes#19371).
Discussion
----------
[Serializer] Give access to the context to support* methods
| Q | A |
| --- | --- |
| Branch? | master |
| Bug fix? | no (?) |
| New feature? | yes |
| BC breaks? | no |
| Deprecations? | no |
| Tests pass? | yes |
| Fixed tickets | - |
| License | MIT |
| Doc PR | n/a |
This is a current use case to want to access the context form the `supports*` methods. This PR fixes this limitation.
Maybe can it be considered a bug fix?
Commits
-------
6a7a16e517 [Serializer] Give access to the context to support* methods
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Replace container injection by explicit service locators
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #20658
| License | MIT
| Doc PR | https://github.com/symfony/symfony-docs/pull/7458
This adds a new `ServiceLocatorArgument` (`!service_locator`) argument type which takes a list of services, meant to be used as a concrete service locator in order to avoid the remaining needs for injecting the container when it's only a matter of dependency lazy-loading.
Config:
```yaml
App\FooBar: [!service_locator { key1: '@service1', key2: '@service2' }]
```
```xml
<service class="App\FooBar" public="false">
<argument type="service-locator">
<argument type="service" key="key1" id="service1"/>
<argument type="service" key="key2" id="service2"/>
</argument>
</service>
```
```php
new ServiceLocatorArgument(array('key1' => new Reference('service1'), 'key2' => new Reference('service2'));
```
Usage:
```php
$locator->has('key1') // true
$locator->has('service1') // false, the defined key must be used
$locator->get('key1'); // service1 instance
$locator->get('service1'); // exception
$locator->has('not-specified') // false
$locator->get('not-specified'); // exception
```
We have some concrete use cases in the core where this would be useful (see e.g. SecurityBundle's FirewallMap), same in userland/3rd party code (see related RFC).
Commits
-------
e7935c0adb [DI] Replace container injection by explicit service locators
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Serializer] Add the possibility to filter attributes
| 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 | todo |
This new features give the possibility to the end user to select select fields to normalize.
Exemple:
``` php
class Foo
{
public $a = '1';
public $b = '2';
public $c = '3';
}
$normalizer = new \Symfony\Component\Serializer\Normalizer\ObjectNormalizer();
$normalizer->normalize(new Foo(), null, ['attributes' => ['a', 'c']]);
// ['a' => '1', 'c' => '3']
```
Denormalization is also supported. This feature works for any normalizer using the `Symfony\Component\Serializer\Normalizer\AbstractNormalizer` class.
The main use case is to permit to API clients to optimize responses length by dropping unnecessary information like in the following example:
```
http://exemple.com/cars?fields=a,c
{'a' => 1, 'c' => 2}
```
Thanks to this PR, support for this feature will be available out of the box in [API Platform](https://api-platform.com).
Commits
-------
b3826fb0e7 [Serializer] Add the possibility to filter attributes
This PR was submitted for the 3.2 branch but it was merged into the 3.3-dev branch instead (closes#20787).
Discussion
----------
[Workflow] Added an entered event
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #20774 (partially) ; #21433
| License | MIT
| Doc PR | -
Commits
-------
7a562bd81e [Workflow] Added an entered event
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Add prototype services for PSR4-based discovery and registration
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | to be done
Talking with @dunglas, we wondered if this could be a good idea, as a more general approach to folder-based service registration as done in [DunglasActionBundle](https://github.com/dunglas/DunglasActionBundle/blob/master/DependencyInjection/DunglasActionExtension.php).
So here is the implementation.
This allows one to define a set of services as such:
```yaml
services:
App\:
resources: ../src/{Controller,Command} # relative to the current file as usual
autowire: true # or any other attributes really
```
This looks for php files in the "src" folder, derivates PSR-4 class names from them, and uses `class_exists` for final discovery. The resulting services are named after the classes found this way.
The "resource" attribute can be a glob to select only a subset of the classes/files.
This approach has several advantages over [DunglasActionBundle](https://github.com/dunglas/DunglasActionBundle/blob/master/DependencyInjection/DunglasActionExtension.php):
- it is resilient to missing parent classes (see test case)
- it loads classes using the normal code path (the autoloader), thus play well with them (e.g. if one registered a special autoloader).
- it is more predictable, because it uses discovered paths as the only source of ids/classes to register - vs relying on `get_declared_classes`, which would make things context sensitive.
Fits well with current initiatives to me.
Commits
-------
03470b788e [DI] Add "psr4" service attribute for PSR4-based discovery and registration
This PR was squashed before being merged into the 3.3-dev branch (closes#21465).
Discussion
----------
[Debug] Support `@final` on methods
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/21461#discussion_r98401148
| License | MIT
| Doc PR |
This adds support for `@final` on methods:
```php
class Foo {
/**
* @final since version 2.0.
*/
public function bar()
{
}
}
```
ping @nicolas-grekas
Commits
-------
1b0a6b6c45 [Debug] Support on methods
This PR was merged into the 3.3-dev branch.
Discussion
----------
Secure unserialize by restricting allowed classes when using PHP 7
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ---
| License | MIT
| Doc PR | ---
While playing around with Symfony in a PHP 7.1 application I noticed a warning in how EnvParameterResoure uses unserialize. Since PHP 7.0 introduced the options argument which allows to restrict which classes can be unserialized for better security, it might make sense to use it here. As far as I can tell this is no BC break, it only provides an additional safety mechanism.
Commits
-------
b4201810b9 Conditionally add options to unserialize in PHP 7.0+.
This PR was squashed before being merged into the 2.7 branch (closes#21458).
Discussion
----------
[Config] Early return for DirectoryResource
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes
| New feature? | sure?
| BC breaks? | no
| Deprecations? | no
| Tests pass? | no
| Fixed tickets |
| Related PRs | #21440
| License | MIT
| Doc PR | n/a
Alternate PR that implements an early return for `DirectoryResource` to increase the speed on large file sets. We can never return early with `true` without checking all assets within the resource, as the aforementioned referenced PR did; hence this PR takes the counter approach and returns `false` early where appropriate.
_Conversation about possible bug at https://github.com/symfony/symfony/pull/21458#discussion_r98366339._
Commits
-------
d5746ecfd2 fix directory resource considers same timestamp not fresh
96107e21f1 return false early from directory resource
This PR was merged into the 2.7 branch.
Discussion
----------
[DoctrineBridge] make sure that null can be the invalid value
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #21554
| License | MIT
| Doc PR |
Commits
-------
c3702c2d8f make sure that null can be the invalid value
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Config][DI] Add ComposerResource to track the runtime engine + deps
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
So that the container is invalidated whenever a new PHP runtime is used, a PHP-extension is added, or vendors are changed.
Commits
-------
a960c761d1 [Config][DI] Add ComposerResource to track runtime + vendors
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Deprecate (un)setting pre-defined services
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | no
| Fixed tickets | #19192
| License | MIT
| Doc PR | -
This PR is the subset of #19668 that fixes#19192: it deprecates (un)setting pre-defined services.
This opens the path to some optimizations in the dumped container in 4.0.
Commits
-------
fdb2140b81 [DI] Deprecate (un)setting pre-defined services
This PR was merged into the 3.2 branch.
Discussion
----------
[FrameworkBundle] Wire ArrayCache for annotation reader at bootstrap
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #21549
| License | MIT
| Doc PR | -
Related to #21381 which disabled any cache at bootstrap.
Instead, this wires ArrayCache during bootstrapping, then swaps the cache provider for the real one.
Commits
-------
f90f53e915 [FrameworkBundle] Wire ArrayCache for annotation reader at bootstrap
This PR was merged into the 2.8 branch.
Discussion
----------
[WebProfilerBundle] Readd Symfony version status in the toolbar
| Q | A
| ------------- | ---
| Branch? | 2.8
| Bug fix? | yes
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
The Symfony version status (*"This Symfony version will no longer receive security fixes."* and the like) was no longer shown in the toolbar. This was removed in 9d89841e3a , but the commit description isn't that describing. I guess it's not done on purpose.
I think having this information is crucial for this feature to work: A yellow version doesn't mean anything specific, unless I see "This Symfony will only receive security fixes".
/cc @javiereguiluz
Commits
-------
d714c7e Readd Symfony version status in the toolbar
This PR was submitted for the master branch but it was merged into the 2.7 branch instead (closes#21586).
Discussion
----------
spelling fixes
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| 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-->
<!--
- Bug fixes must be submitted against the lowest 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.
- Please fill in this template according to the PR you're about to submit.
- Replace this comment by a description of what your PR is solving.
-->
patch contains some spelling fixes ( just in comments ) as found by a bot ( https://github.com/ka7/misspell_fixer ). Any upcoming License changes (e.g. GPL2 to GPL3+) are hereby granted.
Commits
-------
6ccc479 spelling fixes
This PR was submitted for the 3.1 branch but it was merged into the 3.2 branch instead (closes#21579).
Discussion
----------
[Security] LdapUserProvider should not throw an exception if the UID key does not exist in an LDAP entry
| Q | A
| ------------- | ---
| Branch? | 3.1+
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #21577
| License | MIT
| Doc PR |
This ticket should fix#21577, which was introduced by commit 6641b79d58
LdapUserProvider should not throw an exception if the uid key does not exist in the entry.
Commits
-------
ee4d9a70c1 [Security] LdapUserProvider should not throw an exception if the UID key does not exist in an LDAP entry
This PR was squashed before being merged into the 3.3-dev branch (closes#21194).
Discussion
----------
[Yaml] Add tags support
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/issues/21185
| License | MIT
| Doc PR |
This PR adds custom tags support to the Yaml component.
Symfony tags (`!!binary`, `!str`, etc.) are still managed in the parser to have a lighter diff but we'll be able to convert them later if we want to.
The primary addition of this PR is the `TagInterface`:
```php
interface TagInterface
{
public function construct(mixed $value): mixed;
}
```
It can be used to register custom tags. An example that could be used to convert [the syntax `=iterator`](https://github.com/symfony/symfony/pull/20907#issuecomment-270728216) to a tag:
```php
final class IteratorTag implements TagInterface
{
public function construct(mixed $value): mixed
{
return new IteratorArgument($value);
}
}
$parser = new Parser(['iterator' => new IteratorTag()]);
```
If you think this is too complex, @nicolas-grekas [proposed an alternative](https://github.com/symfony/symfony/issues/21185#issuecomment-271074840) to my proposal externalizing this support by introducing a new class `TaggedValue`.
Commits
-------
4744107 [Yaml] Add tags support
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] ContainerBuilder::compile() can optionally resolve env vars in parameter bag
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | #21420
| License | MIT
| Doc PR | -
Here is a new feature allowing one to do `$container->compile(true)` and get the env vars resolved using the current env.
Commits
-------
a3fd512271 [DI] ContainerBuilder::compile() can optionally resolve env vars in parameter bag
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Implement PSR-11
TODO:
- [x] wait for a stable version of the psr/container package;
- [x] ~~deprecate instanciating ServiceNotFoundException directly, or using any of its methods directly;~~ not relevant anymore
- [x] act on the outcome of https://github.com/php-fig/container/issues/8 (solved in https://github.com/php-fig/container/issues/9) ;
- [x] ~~solve the mandatory NotFoundExceptionInterface on non-existing service
problem (with a flag ?);~~ non-issue, see comments below
- [x] provide meta-package psr/container-implementation if all problems can
be solved.
| Q | A
| ------------- | ---
| Branch? | master
| New feature? | yes
| BC breaks? | not at the moment
| Tests pass? | didn't pass before pushing, or even starting to code, will see Travis
| License | MIT
| Doc PR | TODO
This PR is a first attempt at implementing PSR-11, or at least trying to get closer to it.
Delegate lookup is optional, and thus not implemented for now.
Commits
-------
bde0efd01c Implement PSR-11
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Process] Accept command line arrays and per-run env vars, fixing signaling and escaping
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | #12488, #11972, #10025, #11335, #5759, #5030, #19993, #10486
| License | MIT
| Doc PR | -
I think I found a way to fix this network of issues once for all.
Of all the linked ones, only the last two are still open: the remaining were closed in dead ends.
Instead of trying to make `ProcessUtil::escapeArgument` work correctly on Windows - which is impossible as discussed in #21347 - this PR deprecates it in favor of a more powerful approach.
Depending on the use case:
- when a simple command should be run, `Process` now accepts an array of arguments (the "binary" being the first arg). Making this the responsibility of `Process` (instead of `ProcessBuilder`) gives two benefits:
- escape becomes an internal detail that doesn't leak - thus can't be misused ([see here](https://github.com/symfony/symfony/pull/21347#issuecomment-274051370))
- since we know we're running a single command, we can prefix it automatically by "exec" - thus fixing a long standing issue with signaling
```php
$p = new Process(array('php', '-r', 'echo 123;'));
echo $p->getCommandLine();
// displays on Linux:
// exec 'php' '-r' 'echo 123;'
```
- when a shell expression is required, passing a string is still allowed. To make it easy and look-like sql prepared statements, env vars can be used when running the command. Since the shell is OS-specific (think Windows vs Linux) - this PR assumes no portability, so one should just use each shell's specific syntax.
From the fixtures:
```php
$env = array('FOO' => 'Foo', 'BAR' => 'Bar');
$cmd = '\\' === DIRECTORY_SEPARATOR ? 'echo !FOO! !BAR! !BAZ!' : 'echo $FOO $BAR $BAZ';
$p = new Process($cmd, null, $env);
$p->run(null, array('BAR' => 'baR', 'BAZ' => 'baZ'));
$this->assertSame('Foo baR baZ', rtrim($p->getOutput()));
$this->assertSame($env, $p->getEnv());
```
Commits
-------
330b61fecb [Process] Accept command line arrays and per-run env vars, fixing signaling and escaping
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Refacto / cleanup / minor fixes
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
An almost neutral refacto touching only new things in master - unlocking some next steps.
- renames "autowire method" to "autowire call"
- renames `GetterProxyInterface` to `InheritanceProxyInterface`
- moves some helpers in a new internal `InheritanceProxyHelper`
- some other minor things
Commits
-------
ad5b5b5d93 [DI] Refacto / cleanup / minor fixes
This PR was submitted for the master branch but it was merged into the 3.2 branch instead (closes#21552).
Discussion
----------
[FrameworkBundle] Fix annotations cache folder path
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | n/a
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
The argument at index 2 sets a cache path as it extends the file system adapter by default since e59f0e0fd7, where it did set the version before that. This change now results in annotation cache folders showing up in the project root (because of the overwritten cache root folder).
Because cache.annotations has a parent now, this line is not needed anymore and fixes the problem.
Commits
-------
8e5cfa7 Fix annotations cache folder path
This PR was merged into the 3.2 branch.
Discussion
----------
Ignore missing 'debug.file_link_formatter' service in Debug bundle
| Q | A
| ------------- | ---
| Branch? | 3.2
| 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 new `HtmlDumper` requires the `debug.file_link_formatter` service which isn't available in older versions of the `DebugBundle`
Commits
-------
2201fbe Ignore missing 'debug.file_link_formatter' service in Debug bundle