I propose to extract all form themes exceptform_div_layout.html.twig and form_table_layout.html.twig into the symfony/ux repository or a dedicated one (symfony/form-theme, symfony/ui ?) and split each themes into individual packages
symfony/ux-theme-bootstrap
symfony/ux-theme-tailwind
symfony/ux-theme-foundation
etc ...
Here is an exaustive list of benefits that this could bring:
Require only the desire form theme (composer req symfony/ux-theme-bootstrap)
Recipes from Flex (autoconfiguring twig.form_themes or webpack.config.js, update packages.json etc ...)
Custom FormType (SwitchType for Bootstrap)
Simplify maintenance (split tests which are a mess, see #49775)
I recently create a bundle which provide a form theme for Flowbite and when came time to set up tests, I digged into Symfony internal to understand how form theme testing is done.
And ho boy! What a mess 😱!
A lot of code is duplicate internaly across all theme testing classes.
It's not possible for external packages to benefits from thoses classes because they are internal and located in the Tests folder
I had to duplicate a lot of code portions in my turn
For example, take a look to the setUp method of all thoses classes:
This setUp part can be definitely improve! The same goes for all render* methods.
Example
I propose to introduce a new abstract class Symfony\Component\Form\Test\FormLayoutTestCase which will extend from Symfony\Component\Form\Test\FormIntegrationTestCase:
For a project i need to run 2 container for the same project with different environment.
But even if the .env is different in both container. The $_ENV in symfony is the same when it come from symfony console .
All work as except in http.
How to reproduce
declare 2 service of the same symfony app in the docker-compose with different volume
first
volumes:
- ./:/var/www/html:rw,cached
second
volumes:
- ./:/var/www/html:rw,cached
- ./.env.1:/var/www/html/.env:rw,cached
- ./.var_site:/var/www/html/var
This make a different .env in each container and a different var folder for both.
When i look the file in the container the .env file is not the same
But when dump $_ENV in symfony by entering the application by console i still get the first one in both container.
If you run in http all work as except.
With the depreciation of ExtraBundle on object security, I can't have several attributes
Example in my use I check that the user has the right role and also the right company
#[Security('is_granted("ROLE_TECHNICIEN"), message: "Vous devez etre un tech")] #[Security('client.getSociete() == societeService.getSociete()', message: "Ce client qui n'est pas dans votre societe.")]
The main problem is that it cannot be multiple compared to the old one.
The workaround and to have a generic message.
Why not allow this attribute multiple times?
Because IpUtils::checkIp4 and checkIp6 generate the same cache key, an IpV4 address is getting reported as invalid when it is first checked via the checkIp6 method and then with the checkIp4 method again (same applies for v6 getting checked by v4 method).
This problem does not occur when the user uses the generic IpUtils::checkIp method. This is because it only checks v4 and v6 with their respective methods.
If someone can confirm that I did not make a mistake and this is a real bug, I will submit a PR ASAP. Please confirm which branch the PR should be based from.
Once a Symfony console app gets custom completion it's no longer possible to use default file system completions for redirects. Note that this does not duplicate #43607 because completion for redirects should never be processed by Symfony.
Since #46279, we add the "container.exclude" to auto-discovered classes that are excluded by manual config, but we forgot to add it to classes excluded by those attributes.
Monolog 3.2 has made the Logger class final (see Seldaek/monolog@3cba75e ). This might lead to deprecation notices when initializing the Symfony logger
How to reproduce
Manually add Monolog ^3.2 to your composer dependencies
Initialize the Symfony logger in your code, e.g. a CLI command. When the logger is initalized for the first time (with a clean cache), you will get an error message that looks like this:
User Deprecated: The "Monolog\Logger" class is considered final. It may change without further notice as of its next major version You should not extend it from "Symfony\Bridge\Monolog\Logger". {"exception":"[object] (ErrorException(code: 0): User Deprecated: The "Monolog\Logger" class is considered final. It may change without further notice as of its next major version. You should not extend it from "Symfony\Bridge\Monolog\Logger". at /var/www/vendor/symfony/error-handler/DebugClassLoader.php:330)"} []
Possible Solution
A short-term fix would be to restrict the possible versions of Monolog to any version below 3.2 in the composer.json file of monolog-bridge
The long-term fix would be to change Symfony\Bridge\Monolog\Logger as a facade for a Monolog\Logger instance, possibly wrapping a logger and implementing the Psr\Log\LoggerInterface and Monolog\ResettableInterface for backwards compatibility.
The dd() helper is really useful for us developers
However, every time i am debugging a json api call, or when i do a view-source: or curl
I have to replace my dd() with var_dump() + die(), because the output starts with a bunch of static javascript.
Example
A simple solution to this is begin the output with a html comment like this:
<!-- var_dump($data) -->
This way the dumped data is always in a developer friendly version at the top of the file.
Screenshot of the "issue" that im trying to solve :)
This is a follow up of #41771, which already reported the problem. The solution offered there was to use an alternative runtime template but I think the Symfony one should work out of the box with PHARs.
Bundling a standard Symfony app into a PHAR using the default runtime component results in:
PHP Warning: Constant already defined in /home/imper/projects/phartest/build/app.phar on line 16
PHP Fatal error: Uncaught TypeError: Invalid return value: callable object expected, "int" returned from "./build/app.phar". in phar:///home/imper/projects/phartest/build/app.phar/vendor/autoload_runtime.php:12
Stack trace:
#0 phar:///home/imper/projects/phartest/build/app.phar/bin/console(10): require_once()
#1 /home/imper/projects/phartest/build/app.phar(14): require('...')
#2 {main}
thrown in phar:///home/imper/projects/phartest/build/app.phar/vendor/autoload_runtime.php on line 12
The TL:DR; from this config is: nothing really fancy, include somehow the Symfony files that cannot be inferred by Composer.
And then, run:
$ box compile
$ ./bin/console.phar
Possible Solution
The solution suggested in #41771 is in my opinion not satisfactory. Indeed:
this requires a number of non-trivial steps in order to make it work
creating a new runtime template which actually no longer really fits the runtime component. As a consequence you do end up with something working for the PHAR, but outside the PHAR, you console script is no longer working with the runtime context. So you might as well just ditch the runtime component there IMO, it is simpler to fallback to the old console script.
I have checked the script and the issue is that somehow:
ends up with $app = 1, but I just don't get why, it requires the file correctly and the return value should be the callable (even when doing step by step debugging, you end up doing the right path). It's as if the callable was suddenly magically mapped to 1 in the context of the PHAR.
Since last symfony/messenger update, facing MySql error when starting consuming messenger queues.
In DoctrineReceiver.php line 63:
An exception occurred while executing 'DELETE FROM messenger_messages WHERE delivered_at = ?' with params ["9999-12-31"]:
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'messenger_messages' doesn't exist
In AbstractMySQLDriver.php line 61:
An exception occurred while executing 'DELETE FROM messenger_messages WHERE delivered_at = ?' with params ["9999-12-31"]:
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'messenger_messages' doesn't exist
In Exception.php line 18: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'messenger_messages' doesn't exist
In PDOStatement.php line 117: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'messenger_messages' doesn't exist
According the documentation, the table messenger_messages is automatically created when the transport is used. In my case, I use this transport only for failure messages.
This bug
How to reproduce
Configure a doctrine transport only for failure messages and a other one (redis, amqp..) for success ones. Start consuming your messages with supervisor.
Possible Solution
In the Symfony\Component\Messenger\Transport\Doctrine\Connection class, for each operation on doctrine table, check this table is created : check table messenger_messages;
php bin/console translation:extract --force en --clean
php bin/console translation:extract --force uk --clean
All content of these files translated at crowdin. When i pull translations from the crowdin the header+intl-icu.uk.xlf with UK locale updated and all OK:
label.login
Увійти
But header+intl-icu.en.xlf file with EN locale just modified but source and target was the same like before:
If I remove this check for the defaultLocale locale all my translations from the crowdin start to work fine. And I don't know what to do next. Looks like it is a native behavior of the crowdin-translation-provider. But for me, it looks like a bug.
Thanks for any support or kick in direction of what to do with it. I am stuck.
https://github.com/scrapy/cssselect (the python code that was ported to create the CssSelector component) has added support for them in their 1.1.0 release.
