This PR was merged into the 5.0-dev branch.
Discussion
----------
Parameter type leftovers
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #32179
| License | MIT
| Doc PR | N/A
Commits
-------
34eda04866 Added more parameter type declarations.
* 4.4:
Removed calls to Twig\Environment::loadTemplate().
[Intl] make polyfill classes abstract, fix edge case
[Mime] Trim and remove line breaks from NamedAddress name arg
deprecate support for null locales
[TwigBridge] Mark all classes extending twig as @final
[Mime] Remove NamedAddress
[Messenger] remove patch release BC layer of durable and expiring delay
This PR was merged into the 4.4 branch.
Discussion
----------
[TwigBridge] Mark all classes extending twig as @final
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes-ish
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | refs #33039
| License | MIT
| Doc PR | n/a
Classes defining extensions/nodes/node visitors/token parsers should not be changed. They should be final.
That would also help with Twig 3.0 which introduces type hints (including return types).
Commits
-------
d657459a5f [TwigBridge] Mark all classes extending twig as @final
This PR was merged into the 3.4 branch.
Discussion
----------
Fix inconsistent return points
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #17201 in preparation for #33228
| License | MIT
| Doc PR | N/A
Inconsistent return points in methods prevent adding return types. I thought, I'll give it a try and fix them. After this PR, PhpStorm's inspection still finds 39 issues, but as far as I can tell, they're either false positives or fixture code.
Commits
-------
f5b6ee9de1 Fix inconsistent return points.
* 4.4:
[Mailer] simplified the way TLS/SSL/StartTls work
[VarDumper] Add test dump image
Allow exchange type headers binding
Add types to private and final methods.
[Messenger] InMemoryTransport handle acknowledged and rejected messages
[Intl] Validate region preferred alpha code mapping
Added ErrorHandler::call() method utility to turns any PHP warnings into `\ErrorException`
[Intl] Full alpha3 language support
[Monolog] Added ElasticsearchLogstashHandler
This PR was merged into the 4.4 branch.
Discussion
----------
[Monolog] Added ElasticsearchLogstashHandler
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
This PR was initially [submitted on Monolog](https://github.com/Seldaek/monolog/pull/1334).
It has been refused , but Jordi suggested to add it to the symfony bridge. So here we go :)
---
ATM, there are few options to push log to Elastic Stack in order to play with them:
* install logstash and use a Gelf handler. It works but you have to install logstash and configure it. Not an easy task. More over, it need an extra PHP package
* use the ES handler: It does not play well with context and extra: Kibana is not able to filter on nested object. And this handler is tightly coupled to the ElasticaFormatter formater. More over, it need an extra PHP package
* use something to parse file logs. This is really a bad idea since it involves a parsing... More over a daemon is needed to do that (file beat / logstash / you name it)
This is why I'm introducing a new Handler.
* There is not need to install anything (expect ES, of course)
* It play very well with Kibana, as it uses the Logstash format
* It requires symfony/http-client, but in a modern PHP application (SF 4.3) this dependency is already present
* It slow down a bit the application since it trigger an HTTP request for each logs. But symfony/http-client is non-blocking. If you want to use it in production, I recommend to wrap this handler in a buffer handler or a cross-finger handle to have only one HTTP call.
---
Some performance consideration en a prod env with a buffer handler + this one
* with push to ES: https://blackfire.io/profiles/f94ccf35-9f9d-4df1-bfc5-7fa75a535628/graph
* with push to ES commented: https://blackfire.io/profiles/6b66bc18-6b90-4341-963f-797f7a7a689c/graph
As you can see, as requests are made synchronously, there is no penalty on `AppKernel::Handler()` 😍! But the PHP worker has more work to do, and it's busy much more time (about X2)
I explained everything in the PHP Doc Block
---
This is what you can expect **out of the box**
![image](https://user-images.githubusercontent.com/408368/59916122-9b7b7580-941e-11e9-9a22-f56bc1d1a288.png)
Commits
-------
1587e9a4e2 [Monolog] Added ElasticsearchLogstashHandler
* 4.4:
[ProxyManager] fix closure binding
[VarDumper] fix annotations
trigger a deprecation not a notice
[Console] fixed a PHP notice when there is no function
[Mailer] fixed missing property assignment