…dev, tech problems and solutions.
When testing deprecations with PHPUnit greater than 9.5.10 you might encounter this error:
Failed asserting that exception of type "PHPUnit\Framework\Error\Deprecated" is thrown.
The code in the test is as follows:
$this->expectDeprecation();
and the code that should be tested is like this:
\trigger_error('foo', \E_USER_DEPRECATED);
The psr/log package used to have not only the Interface for PSR-3 Logger, but also actual implementations of the interface like the TestLogger.
The TestLogger could be used as mock for any PSR-3 Logger in your test cases.
However from v3 the TestLogger was removed, so that the psr/log package would focus solely on the Interface.
If you used the TestLogger in your project and you or some of your dependencies upgraded psr/log to >= v3 you most likely saw this error:
Class "Psr\Log\Test\TestLogger" not found
When using bin/console make:entity on Mysql and then later you switch your application to Postgres and you have a table called user, which you most likely have when using security component of Symfony.
Then you will receive an error because user is a reserved word in Postgres!
An exception occurred while executing 'INSERT INTO user (id, email, roles, password, is_verified) VALUES (?, ?, ?, ?, ?)' with params [3, "dev@dev.de", "[]", "your-encrypted-password", 0]:
SQLSTATE[42601]: Syntax error: 7 ERROR: syntax error at or near "user"
LINE 1: INSERT INTO user (id, email, roles, password, is_verified) V...
You might encounter this deprecation message after your upgrade to symfony 5.1 in your symfony project:
Since symfony/dotenv 5.1: Passing a boolean to the constructor of “Symfony\Component\Dotenv\Dotenv” is deprecated, use “Dotenv::usePutenv()
To fix this, go to config/bootstrap.php and remove the false from the Dotenv constructor:(new Dotenv(false))->loadEnv(dirname(DIR).'/.env');
to(new Dotenv())->loadEnv(dirname(DIR).'/.env');
See: https://github.com/symfony/symfony/issues/37195
Actually the file config/bootstrap.php has been removed from symfony 5.1 and was replaced in public/index.php.
But since the project was updated from an symfony 4 version the bootrap file is still present.
So another option would be to remove the boostrap file and update the project entirely to symfony 5.1 recipe.
This is not trivial though as you can see in this corresponfing PullRequest.
Disclaimer: No legal advice, just a little experience report.
If you sell digital things (services, digital goods etc.) to EU countries, you might have to calculate the VAT at the rate of the customer’s country (and even pay it there afterwards).
The latter is even the more inconvenient part, but at least the first part can be done quite easily with good old PHP.
So i updated a symfony app the other day to version 5.1.6 and suddenly the static code analyzer psalm ran appearently in an hangup loop and never terminated.
After some investigation it showed that symfony added a .preload.php file to the src directory to enable the new PHP7.4 preloading feature.
Unfortunatly psalm parsed this file and followed all includes.
This took it so long that i took it for an endless loop.
There is some discussion in symfony github issues about this and the conclusion was to replace src/.preload.php with config/preload.php which happens now in a recipe.
Continue reading “Psalm Static Analyzer fails with Symfony’s builtin preloading file”Symfony’s deprecation warnings while running tests is a great service to keep track with upcoming changes in newer symfony versions.
However these warnings can break your CI/CD pipeline and sometimes you cant fix all deprecation warnings immediatly.
To disable them you can set the ENV var SYMFONY_DEPRECATIONS_HELPER=disabled
and the warnings will not be displayed anymore and CI/CD will pass again.
Update from comments:
SYMFONY_DEPRECATIONS_HELPER=weak
When working with APIs you sometimes cant use the live API in the tests.
Because you dont own the API, dont want to spam, cant create entities for testing or various other reasons.
Then you need to mock the API and deliever responses from fixtures.
Though there is this term of “Don’t mock what you don’t own” we will mock the API because we dont own it. :)
https://github.com/julienfalque/http-mock is a nice library which helps a lot when mocking an API.
And when your client is using Guzzle there is also a Guzzle handler for HttpMock that makes integration easy.
How does this work?
Continue reading “mocking APIs with Guzzle”
One very cool feature of the Symfony Workflow Component is the ability to export workflows via graphviz.
Did you know you can also directly render those as PDF files?
Continue reading “Symfony Workflow Component: Dump workflows as PDF”
Angular for frontend with symfony delivering the data have become quite a common setup.
When working with this constellation you will sooner or later come across the i18n topic. Most likely you would want to share translations between front- and backend. So that you could keep translations in one single location while using it for frontend templates as well as server-side error messages etc.
One approach would be to store translations in the symfony yml or xml files and deliver those to the frontend via an api endpoint.
Given that front- and backend-code run on the same server, there is an even simpler solution.
Continue reading “Symfony and Angular: shared translations”