This PR was merged into the 5.3-dev branch.
Discussion
----------
[Runtime] a new component to decouple applications from global state
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | https://github.com/symfony/symfony-docs/pull/15081
Follow up of #36652, see discussion there.
What if we could decouple the bootstrapping logic of our apps from any global state?
This PR makes it possible via a new proposed `symfony/runtime` component.
The immediate benefit this provides is easier maintenance of Symfony apps: code that is currently shipped by recipes will be able to move to `vendor/`. Read the previous sentence twice, this is big :)
Check the following PR to see how far this goes: https://github.com/symfony/recipes/pull/787
The longer-term benefit is being able to run the exact same app under several runtimes: PHP-FPM, CLI, but also PHP-PM and similar. Thanks to the proposed interface, this benefit could span to any PHP apps; not only to apps using the Symfony HttpKernel/HttpFoundation components. This part could be moved to `symfony/contracts` in the future.
Performance-wise, I measured no significant difference with the current way of running apps.
RuntimeInterface
----------------
The core of this component is the `RuntimeInterface` which describes a high-order
runtime logic.
It is designed to be totally generic and able to run any application outside of
the global state in 6 steps:
1. the main entry point returns a callable that wraps the application;
2. this callable is passed to `RuntimeInterface::getResolver()`, which returns a
`ResolverInterface`; this resolver returns an array with the (potentially
decorated) callable at index 0, and all its resolved arguments at index 1;
3. the callable is invoked with its arguments; it returns an object that
represents the application;
4. that object is passed to `RuntimeInterface::getRunner()`, which returns a
`RunnerInterface`: an instance that knows how to "run" the object;
5. that instance is `run()` and returns the exit status code as `int`;
6. the PHP engine is exited with this status code.
This process is extremely flexible as it allows implementations of
`RuntimeInterface` to hook into any critical steps.
Autoloading
-----------
This package registers itself as a Composer plugin to generate a
`vendor/autoload_runtime.php` file. This file shall be required instead of the
usual `vendor/autoload.php` in front-controllers that leverage this component
and return a callable.
Before requiring the `vendor/autoload_runtime.php` file, set the
`$_SERVER['APP_RUNTIME']` variable to a class that implements `RuntimeInterface`
and that should be used to run the returned callable.
Alternatively, the class of the runtime can be defined in the `extra.runtime.class`
entry of the `composer.json` file.
A `SymfonyRuntime` is used by default. It knows the conventions to run
Symfony and native PHP applications.
Examples
--------
This `public/index.php` is a "Hello World" that handles a "name" query parameter:
```php
<?php
require_once dirname(__DIR__).'/vendor/autoload_runtime.php';
return function (array $request, array $context): void {
// $request holds keys "query", "body", "files" and "session",
// which map to $_GET, $_POST, $_FILES and &$_SESSION respectively
// $context maps to $_SERVER
$name = $request['query']['name'] ?? 'World';
$time = $context['REQUEST_TIME'];
echo sprintf('Hello %s, the current Unix timestamp is %s.', $name, $time);
};
```
This `bin/console.php` is a single-command "Hello World" application
(run `composer require symfony/console` before launching it):
```php
<?php
use Symfony\Component\Console\Command\Command;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;
require_once dirname(__DIR__).'/vendor/autoload_runtime.php';
return function (Command $command) {
$command->addArgument('name', null, 'Who should I greet?', 'World');
return $command->setCode(function (InputInterface $input, OutputInterface $output) {
$name = $input->getArgument('name');
$output->writeln(sprintf('Hello <comment>%s</>', $name));
});
};
```
The `SymfonyRuntime` can resolve and handle many types related to the
`symfony/http-foundation` and `symfony/console` components.
Check its source code for more information.
Commits
-------
61b32ab2a3 [Runtime] a new component to decouple applications from global state
This PR was merged into the 5.3-dev branch.
Discussion
----------
Don't use sprintf in trigger_deprecation() calls
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Old habits die hard :)
Commits
-------
9ba8f0567d Don't use sprintf in trigger_deprecation() calls
This PR was merged into the 5.3-dev branch.
Discussion
----------
[HttpKernel] Deprecate returning a `ContainerBuilder` from `KernelInterface::registerContainerConfiguration()`
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | no
| Deprecations? | yes
| Tickets | -
| License | MIT
| Doc PR | -
This behavior was introduced in 38aef98694 (diff-7753dd9020accbf6eb7c3dbb86a992340ce9dff4a0258458d7bbdd0a3d396939R261)
But this is never used nor tested AFAIK, and the interface doesn't document it.
Commits
-------
4449b553a8 [HttpKernel] Deprecate returning a `ContainerBuilder` from `KernelInterface::registerContainerConfiguration()`
This PR was squashed before being merged into the 5.3-dev branch.
Discussion
----------
[DependencyInjection] Add support an integer return for default_index_method
| Q | A
| ------------- | ---
| Branch? | 5.x for features
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | #40319
| License | MIT
| Doc PR | TODO
Commits
-------
f0922c70d6 [DependencyInjection] Add support an integer return for default_index_method
This PR was merged into the 5.3-dev branch.
Discussion
----------
[PropertyAccess] use bitwise flags to configure when the property accessor should throw
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | no
| Deprecations? | yes
| Tickets | Fix#31126
| License | MIT
| Doc PR |
Commits
-------
a50cfcb49d use bitwise flags to configure when the property accessor should throw
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Cache] boost perf by wrapping keys validity checks with `assert()`
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
PSR-6 has one perf hog: checking the validity of keys.
But in practice, an invalid key should never happen in production: encoding/cleanup is a must-have, and it's a step that should be identified *during dev*.
That's why I think we're safe wrapping these checks with `assert()`.
On an `ArrayAdapter`, this doubles the throughput of the pool when getting items.
I didn't use `assert()` in constructors when not on the hot path.
This PR also makes some callable properties static, as they should be from the beginning.
Commits
-------
8f03a1f555 [Cache] boost perf by wrapping keys validity checks with `assert()`
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Console] Avoid unneeded preg_replace_callback
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| License | MIT
Motivations for this change:
* Avoid an unneded preg call, explode+implode is faster
* The previous regex created to suboptimal expressions,
due to the pipe that caused empty to be matched.
That means an input like `foo:bar`
was translated into `foo[^:]*[^:]*:bar[^:]*[^:]*`
instead of simply `foo[^:]*:bar[^:]*`
Commits
-------
daaa760fd2 Avoid unneeded preg_replace_callback in console application
Motivations for this change:
* Avoid an unneded preg call, explode+implode is faster
* The previous regex created to suboptimal expressions,
due to the pipe that caused empty to be matched.
That means an input like `foo:bar`
was translated into `foo[^:]*[^:]*:bar[^:]*[^:]*`
instead of simply `foo[^:]*:bar[^:]*`
* 5.2:
[WebLink] Removed unused property
Fix method name compare in ResolveControllerNameSubscriber
add uz security validator and form validator file
uzb translation
* 4.4:
[WebLink] Removed unused property
Fix method name compare in ResolveControllerNameSubscriber
add uz security validator and form validator file
uzb translation
This PR was merged into the 4.4 branch.
Discussion
----------
[WebLink] Removed unused property
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | N/A
| License | MIT
| Doc PR | N/A
In `Link::withHref()`, a property `templated` is written, that is never declared or access anywhere else. I assume that this is dead code.
Commits
-------
848972e830 [WebLink] Removed unused property
This PR was merged into the 4.4 branch.
Discussion
----------
[FrameworkBundle] [4.4]: Fix method name compare in ResolveControllerNameSubscriber
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| License | MIT
| Doc PR | <!-- required for new features -->
The left side to `strtolower` was not actually lowercased, so it would be always `false`.
The bug was introduced in 6c109c71a9 (https://github.com/symfony/symfony/pull/31938)
<!--
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/releases):
- Always add tests and ensure they pass.
- Never break backward compatibility (see https://symfony.com/bc).
- Bug fixes must be submitted against the lowest maintained branch where they apply
(lowest branches are regularly merged to upper ones so they get the fixes too.)
- Features and deprecations must be submitted against branch 5.x.
- Changelog entry should follow https://symfony.com/doc/current/contributing/code/conventions.html#writing-a-changelog-entry
-->
Commits
-------
69431a3db3 Fix method name compare in ResolveControllerNameSubscriber
This PR was merged into the 4.4 branch.
Discussion
----------
add 2 translations file uzb lang
| Q | A
| ------------- | ---
| Branch? | 5.x for features / 4.4 or 5.2 for bug fixes <!-- see below -->
| Bug fix? | no
| New feature? | yes <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | Fix #... <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!-- required for new features -->
<!--
Replace this notice by a short README for your feature/bugfix. This will help people
understand your PR and can be used as a start for the documentation.
Additionally (see https://symfony.com/releases):
- Always add tests and ensure they pass.
- Never break backward compatibility (see https://symfony.com/bc).
- Bug fixes must be submitted against the lowest maintained branch where they apply
(lowest branches are regularly merged to upper ones so they get the fixes too.)
- Features and deprecations must be submitted against branch 5.x.
- Changelog entry should follow https://symfony.com/doc/current/contributing/code/conventions.html#writing-a-changelog-entry
-->
Commits
-------
73392924bf add uz security validator and form validator file
This PR was submitted for the 5.x branch but it was merged into the 4.4 branch instead.
Discussion
----------
add uz validators file
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | Fix #... <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!-- required for new features -->
<!--
Replace this notice by a short README for your feature/bugfix. This will help people
understand your PR and can be used as a start for the documentation.
Additionally (see https://symfony.com/releases):
- Always add tests and ensure they pass.
- Never break backward compatibility (see https://symfony.com/bc).
- Bug fixes must be submitted against the lowest maintained branch where they apply
(lowest branches are regularly merged to upper ones so they get the fixes too.)
- Features and deprecations must be submitted against branch 5.x.
- Changelog entry should follow https://symfony.com/doc/current/contributing/code/conventions.html#writing-a-changelog-entry
-->
add uz validators file
Commits
-------
df4679c163 uzb translation
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Security] Decouple passwords from UserInterface
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | yes
| Tickets | #23081, helps with #39308
| License | MIT
| Doc PR | todo
This PR addresses a long-standing issue of the Security component: UserInterface is coupled to passwords.
It does it by moving the `getPassword()` method from `UserInterface` to a `PasswordAuthenticatedUserInterface`, and the `getSalt()` method to a `LegacyPasswordAuthenticatedUserInterface`.
Steps:
- In 5.3, we add the new interface and, at places where password-based authentication happens, trigger deprecation notices when a `UserInterface` object does not implement the new interface(s). The UserInterface is kept as-is until 6.0.
- In 6.0, we can remove the methods from `UserInterface` as well as support for using password authentication with user objects not implementing the new interface(s).
As a side-effect, some password-related interfaces (`UserPasswordHasherInterface` and `PasswordUpgraderInterface`) must change their signatures to type-hint against the new interface.
That is done in a BC way, which is to make the concerned methods virtual until 6.0, with deprecation notices triggered from callers and concrete implementations.
Benefits:
In 6.0, applications that use password-less authentication (e.g. login links) won't need to write no-op `getPassword()` and `getSalt()` in order to fulfil the `UserInterface` contract.
For applications that do use password-based authentication, they will need to opt-in explicitly by implementing the relevant interface(s).
This build on great discussions with @wouterj and @nicolas-grekas, and it is part of the overall rework of the Security component.
Commits
-------
2764225a38 [Security] Decouple passwords from UserInterface
This PR was squashed before being merged into the 5.3-dev branch.
Discussion
----------
[Notifier] [OvhCloud] Add "sender"
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | symfony/symfony-docs#... <!-- required for new features --> (I'm waiting to see if the feature is accepted )
Add "sender" option to the DSN that allows configuring the sender of the message.
OVHCloud manages two cases for sending sms according to the [doc](https://docs.ovh.com/fr/sms/envoyer_des_sms_avec_lapi_ovh_en_php/):
> The senderForResponse parameter will allow the use of a short number, which allows you to send SMS directly without having to create an alphanumeric sender (for example: your name).
> Short numbers also allow you to receive responses from the recipients of your SMS, which can be useful for a satisfaction survey, a voting application, a game, etc.
This PR introduces the management of these 2 cases with a new option `sender`:
* if `sender` is set, we use it
* if `sender` is not set, we use `senderForResponse` to get a short number (current behavior)
I took the logic implementedin the old official SDK : 52d279e112/src/Message.php (L161)
Commits
-------
c5a9b252ab [Notifier] [OvhCloud] Add "sender"
This PR was merged into the 5.3-dev branch.
Discussion
----------
[DependencyInjection] Implement psr/container 1.1
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | N/A
| License | MIT
| Doc PR | N/A
The `psr/container` interfaces have been updated with type declarations. The lack of those is what kept us from adding property type declarations to the `get()` and `has()` methods of our own `ContainerInterface`.
A small BC break is that we have never prevented calling code from passing `null` as the service ID. Even without strict types, this will cause a `TypeError` after my changes. I already had to update `AutowirePass` because of that.
On the other hand, it was neither documented that we allow `null` here nor did the container do anything useful (`has(null)` always resulted in `false` and `get(null)` always returned `null`).
Commits
-------
d9095aa892 [DependencyInjection] Implement psr/container 1.1
This PR was merged into the 4.4 branch.
Discussion
----------
[TwigBridge] Render email once
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#39718
| License | MIT
| Doc PR | -
When `\Symfony\Component\Mailer\Mailer` send an email via the Bus (async) it dispatches an `MessageEvent`, then the consumer call the `\Symfony\Component\Mailer\Transport\AbstractTransport::send` method which also dispatches an `MessageEvent`.
This event is listened by `\Symfony\Bridge\Twig\Mime\BodyRenderer::render` which rendered twice an email.
I'm not sure why the event is send twice, and if we could safely remove one of them (or maybe deprecating the `MessageEvent`, in favor of `SendMessageEvent` + `AsyncMessageEvent`)
This PR store a flag in the Message to avoid rendering it twice.
Commits
-------
186ea59180 Render email once
* 5.2:
Backport psr/container 1.1/2.0 compatibility
Update notifier_transports.php
Dont lock tables or start transactions
Bump Symfony version to 5.2.5
Update VERSION for 5.2.4
Update CHANGELOG for 5.2.4
Bump Symfony version to 4.4.21
Update VERSION for 4.4.20
Update CONTRIBUTORS for 4.4.20
Update CHANGELOG for 4.4.20
* 4.4:
Backport psr/container 1.1/2.0 compatibility
Bump Symfony version to 4.4.21
Update VERSION for 4.4.20
Update CONTRIBUTORS for 4.4.20
Update CHANGELOG for 4.4.20
This PR was merged into the 4.4 branch.
Discussion
----------
[DependencyInjection][Security] Backport psr/container 1.1/2.0 compatibility
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix https://github.com/symfony/symfony/pull/40384/files#r588494278
| License | MIT
| Doc PR | N/A
This PR backports a fix that I had to apply to the 5.x branch in order to make it compatible with the `psr/container` 1.1 interfaces.
It also updates various composer.json files:
* Security Core only consumes a PSR `ContainerInterface` without providing its own implementation. I should be compatible with version 2 of the PSR package already.
* ~~DependencyInjection breaks on PHP 7.2 and 7.3 if `psr/container` 1.1.0 is installed. A version 1.1.1 has already been release that fixes the issue. I've added a conflict rule to document the incompatibility.~~
Commits
-------
7f8242ef58 Backport psr/container 1.1/2.0 compatibility
