symfony

symfony

Member Since 11 years ago

The Internet

Experience Points
0
follower
Lessons Completed
0
follow
Best Reply Awards
205
repos
Jun
23
9 hours ago
Activity icon
issue

fox34 issue symfony/symfony

fox34
fox34

[TwigBridge] Allow specification of translation key in addition to content string in Twig templates

Description The current Symfony Best Practices for Internationalisation recommend using translation keys instead of content strings, which has unquestionable advantages. However, using only translation keys when creating new templates is currently rather non-verbose and slow, since the website content must then be added as translation in a second step and cannot be seen (as context) inside the template.

This is why I propose a new attribute/parameter to the existing Twig tags/filters/functions (t/trans) for optionally specifying a translation key next to the (initial) target value. Template writers can then easily provide an initial value and context for the default locale, while keeping the benefits of translation keys, such as changing the text of the default locale later (inside the translation files) without having to update all other locales.

I have implemented a working example for the {% trans %}-tag using the following syntax:

{% trans as 'translation.key' %}Proposed initial content string{% endtrans %}

I did not create a pull request yet, since the functionality is not complete nor fully tested or documented and I wanted to request comments first.

Example

  • Input demo.html.twig:
{% trans_default_domain 'demo' %}

Current behaviour, using translation keys: non-verbose and slow to create:
{% trans %}test.message.as.key.without.default.text{% endtrans %}

Current behaviour, using content strings: verbosity in templates and fast creation, but several disadvantages:
{% trans %}Test message without explicit id, but with default text{% endtrans %}

Proposed new behaviour: Explicit translation key with content string:
{% trans as 'test.message.with.key.and.text' %}Test message with explicit id and default text{% endtrans %}
  • Resulting demo.en.xlf after running php bin/console translation:update --force --domain=demo en (when using my sample implementation):
[...]
<trans-unit id="g7UN0Df" resname="test.message.as.key.without.default.text">
  <source>test.message.as.key.without.default.text</source>
  <target>__test.message.as.key.without.default.text</target>
</trans-unit>
<trans-unit id="d5CC0j2" resname="Test message without explicit id, but with default text">
  <source>Test message without explicit id, but with default text</source>
  <target>__Test message without explicit id, but with default text</target>
</trans-unit>
<trans-unit id="SCGnBjM" resname="test.message.with.key.and.text">
  <source>test.message.with.key.and.text</source>
  <target>__Test message with explicit id and default text</target>
</trans-unit>
[...]

Exporting the translation unit correctly to XLIFF with the translation key as resname, the content string as unprefixed <source> and as prefixed (if not default locale) or unprefixed (if default locale) <target> would, however, require further modification and can be subject of another feature request (similar issue: #33041). The optimal resulting XLIFF files would, in my opinion, look like this:

  • Optimal demo.en.xlf (note the <source> and the unprefixed <target>):
[...]
<trans-unit id="SCGnBjM" resname="test.message.with.key.and.text">
  <source>Test message with explicit id and default text</source>
  <target>Test message with explicit id and default text</target>
</trans-unit>
[...]
  • Optimal demo.fr.xlf (note the prefixed <target>):
[...]
<trans-unit id="SCGnBjM" resname="test.message.with.key.and.text">
  <source>Test message with explicit id and default text</source>
  <target>__Test message with explicit id and default text</target>
</trans-unit>
[...]
Activity icon
issue

JoshuaBehrens issue comment symfony/symfony

JoshuaBehrens
JoshuaBehrens

RateLimiterFactory is not extendable by others

Description We want to use an own policy in the RateLimiter in the Framework configuration, but the allowed policy are hard-coded and the class is not extendable

Example

Maybe replace it with a Factory pattern like in the Mailer component. Registering each policy with a tag

JoshuaBehrens
JoshuaBehrens

Just stumbled upon this issue. Looking at the implementations, I am really missing one from our toolset: no-dos rate limiter. We use it to stop ourselves from spamming other systems when their response times drop or their response headers tell us to stop soon. So whenever we would use the Symfony implementation this would be something we'd like to patch in there.

In case this is already possible and I didn't deep-dived deep enough to get it yet, I know where the door is 😅

Activity icon
issue

shyim issue comment symfony/symfony

shyim
shyim

RateLimiterFactory is not extendable by others

Description We want to use an own policy in the RateLimiter in the Framework configuration, but the allowed policy are hard-coded and the class is not extendable

Example

Maybe replace it with a Factory pattern like in the Mailer component. Registering each policy with a tag

shyim
shyim

Sure I can make a pull request with the interface if that's the way :)

Activity icon
issue

wouterj issue comment symfony/symfony

wouterj
wouterj

RateLimiterFactory is not extendable by others

Description We want to use an own policy in the RateLimiter in the Framework configuration, but the allowed policy are hard-coded and the class is not extendable

Example

Maybe replace it with a Factory pattern like in the Mailer component. Registering each policy with a tag

wouterj
wouterj

I haven't yet completely organized my opinion about this proposal (that's why I was a bit silent). Some unorganized thoughts:

  • I think the use-case is valid enough to do something about this
  • I'm not sure if a highly split up factory is the way forward. Contrary to Mailer and Notifier, there are just a handful rate limiter policies and there is no reason to believe that we'll have 50 different policy algorithms in any application.
  • From a maintainer perspective, final classes are worth a lot (less maintenance and possibility for BC breaks). I think maybe adding a RateLimiterFactoryInterface and typehinting for that is enough. Users will be able to add support for custom policies by decorating the current factory.
pull request

derrabus merge to symfony/symfony

derrabus
derrabus

[Serializer] Add support of PHP backed enumerations

Q A
Branch? 4.4
Bug fix? yes (new PHP version support)
New feature? no
Deprecations? no
Tickets Fix #40241
License MIT
Doc PR none

Capture d’écran du 2021-04-15 21-41-51

open pull request

derrabus wants to merge symfony/symfony

derrabus
derrabus

[Serializer] Add support of PHP backed enumerations

Q A
Branch? 4.4
Bug fix? yes (new PHP version support)
New feature? no
Deprecations? no
Tickets Fix #40241
License MIT
Doc PR none

Capture d’écran du 2021-04-15 21-41-51

derrabus
derrabus
        return is_subclass_of($type, \BackedEnum::class);
open pull request

derrabus wants to merge symfony/symfony

derrabus
derrabus

[Serializer] Add support of PHP backed enumerations

Q A
Branch? 4.4
Bug fix? yes (new PHP version support)
New feature? no
Deprecations? no
Tickets Fix #40241
License MIT
Doc PR none

Capture d’écran du 2021-04-15 21-41-51

derrabus
derrabus
        return $data instanceof \BackedEnum;

It's okay to use instanceof with undefined classes/interfaces.

pull request

derrabus merge to symfony/symfony

derrabus
derrabus

[Serializer] Add support of PHP backed enumerations

Q A
Branch? 4.4
Bug fix? yes (new PHP version support)
New feature? no
Deprecations? no
Tickets Fix #40241
License MIT
Doc PR none

Capture d’écran du 2021-04-15 21-41-51

pull request

wouterj merge to symfony/symfony

wouterj
wouterj

[WebProfilerBundle] Improved the light/dark theme switching

Q A
Branch? 5.4
Bug fix? no
New feature? yes
Deprecations? no
Tickets -
License MIT
Doc PR -

~Note: I think this is a bug fix ... but maybe you prefer to consider it a new feature.~


The current Symfony Profiler works like this:

  • If you don't set the theme, it selects it automatically form light/dark to match your OS
  • But you can also select "light" or "dark" explicitly

The problem is that when you choose a theme explicitly, the "auto" theme is no longer available. You need to delete the local storage of your browser.

This PR makes it explicit the "auto theme" already available in the Profiler. That way, you can set "light", "dark" or "auto" explicitly:

Captura de pantalla 2021-05-28 a las 11 01 21

It also changes the "theme listener" to respond instantly to OS changes, without having to refresh the page.

push

symfony-splitter push symfony/security-core

symfony-splitter
symfony-splitter

Fix special char used to create cache key

symfony-splitter
symfony-splitter

bug #41737 [Security] Fix special char used to create cache key (jderusse)

This PR was merged into the 5.3 branch.

Discussion

[Security] Fix special char used to create cache key

Q A
Branch? 5.3
Bug fix? yes
New feature? no
Deprecations? no
Tickets -
License MIT
Doc PR -

The remember Me token's series property might contains special chars: because it has been generated with $series = base64_encode(random_bytes(64));.

When using this identifier to create cache items, users get Exception Cache key "foo+bar/baz==" contains reserved characters "{}()/\@:".

This PR sanitize the property before using it as cache key

Commits

fc9e9ff7a1 Fix special char used to create cache key

commit sha: f94b76f50fb6f1179b56990584ccee744ea52ea2

push time in 22 minutes ago
pull request

wouterj pull request symfony/symfony

wouterj
wouterj

[Security] Fix special char used to create cache key

Q A
Branch? 5.3
Bug fix? yes
New feature? no
Deprecations? no
Tickets -
License MIT
Doc PR -

The remember Me token's series property might contains special chars: because it has been generated with $series = base64_encode(random_bytes(64));.

When using this identifier to create cache items, users get Exception Cache key "foo+bar/baz==" contains reserved characters "{}()/\@:".

This PR sanitize the property before using it as cache key

push

wouterj push symfony/symfony

wouterj
wouterj

Fix special char used to create cache key

wouterj
wouterj

bug #41737 [Security] Fix special char used to create cache key (jderusse)

This PR was merged into the 5.3 branch.

Discussion

[Security] Fix special char used to create cache key

Q A
Branch? 5.3
Bug fix? yes
New feature? no
Deprecations? no
Tickets -
License MIT
Doc PR -

The remember Me token's series property might contains special chars: because it has been generated with $series = base64_encode(random_bytes(64));.

When using this identifier to create cache items, users get Exception Cache key "foo+bar/baz==" contains reserved characters "{}()/\@:".

This PR sanitize the property before using it as cache key

Commits

fc9e9ff7a1 Fix special char used to create cache key

commit sha: 2230cfd35169c0125c77b0b4e8a754e5e6c39a93

push time in 23 minutes ago
Activity icon
issue

wouterj issue comment symfony/symfony

wouterj
wouterj

[Security] Fix special char used to create cache key

Q A
Branch? 5.3
Bug fix? yes
New feature? no
Deprecations? no
Tickets -
License MIT
Doc PR -

The remember Me token's series property might contains special chars: because it has been generated with $series = base64_encode(random_bytes(64));.

When using this identifier to create cache items, users get Exception Cache key "foo+bar/baz==" contains reserved characters "{}()/\@:".

This PR sanitize the property before using it as cache key

Activity icon
issue

andrejsstepanovs issue comment symfony/recipes-contrib

andrejsstepanovs
andrejsstepanovs

add new bundle ecoco/sylius-base-price-plugin

Q A
License MIT

If I do proceed to fix Travis CI build then I will just break my recipe. Because I will need to enable and configure so many unrelated bundles. This will definitely be destructing for many sylius shops that oped to not use them.

I tried recipe using given instructions and it works exactly as expected. Not sure what I can do to get this thing merged automatically. Any pointers are welcomed.

andrejsstepanovs
andrejsstepanovs

Can this be checked and accepted by human being please?

open pull request

derrabus wants to merge symfony/symfony

derrabus
derrabus

[Validator] Expression language allow null

Q A
Branch? 5.2
Bug fix? yes
New feature? no
Deprecations? no
Tickets
License MIT
Doc PR

Like other validators, ExpressionLanguageSyntax validator should be ignored when the value is null or receive an empty string, add NotNull or NotBlank if needed.

derrabus
derrabus

This parameter is our forward compatibility layer and it allows us to opt-in to the behavior we want to have in 6.0. An application that does not explicitly enable that new behavior will potentially break when upgrading to Symfony 6.

What we should deprecate is not explicitly setting it to true.

        if (!$this->allowNullAndEmptyString) {
            trigger_deprecation('symfony/validator', '5.4', 'Not setting "allowNullAndEmptyString" of the "%s" constraint to "true" is deprecated.', __CLASS__);
        }
pull request

derrabus merge to symfony/symfony

derrabus
derrabus

[Validator] Expression language allow null

Q A
Branch? 5.2
Bug fix? yes
New feature? no
Deprecations? no
Tickets
License MIT
Doc PR

Like other validators, ExpressionLanguageSyntax validator should be ignored when the value is null or receive an empty string, add NotNull or NotBlank if needed.

derrabus
derrabus

Sorry for stalling here. I have a comment about the deprecation layer. We should make sure that the deprecation supports our upgrade path to 6.0.

Also, when testing the deprecated behavior, please make sure to add it to the legacy group:

/**
 * @group legacy
 */
public function testSomeOldBehavior()
{

This way, the deprecation will not cause the test to fail and we know which tests can be removed on 6.0.

pull request

derrabus merge to symfony/symfony

derrabus
derrabus

[Validator] Expression language allow null

Q A
Branch? 5.2
Bug fix? yes
New feature? no
Deprecations? no
Tickets
License MIT
Doc PR

Like other validators, ExpressionLanguageSyntax validator should be ignored when the value is null or receive an empty string, add NotNull or NotBlank if needed.

derrabus
derrabus

Sorry for stalling here. I have a comment about the deprecation layer. We should make sure that the deprecation supports our upgrade path to 6.0.

Also, when testing the deprecated behavior, please make sure to add it to the legacy group:

/**
 * @group legacy
 */
public function testSomeOldBehavior()
{

This way, the deprecation will not cause the test to fail and we know which tests can be removed on 6.0.

Activity icon
issue

derrabus issue comment symfony/symfony

derrabus
derrabus

[DoctrineBundle] DoctrineLoader relies on AutoMappingTrait

Symfony version(s) affected: 5.2

Description DoctrineExtension#loadValidatorLoader registers the DoctrineLoader as a service. This class uses the Symfony\Component\Validator\Mapping\Loader\AutoMappingTrait which might not be available.

As soon as this service gets autloaded at container build time* this will produce a fatal error under PHP8.1:

PHP Fatal error:  During class fetch: Uncaught ReflectionException: Class "Symfony\Component\Validator\Mapping\Loader\AutoMappingTrait" not found while loading "Symfony\Bridge\Doctrine\Validator\DoctrineLoader`

*) one scenario is for instance reading class annotations/attributes and thereby calling $container->getReflectionClass()

How to reproduce

  1. Set up a Sf application with doctrine-bundle installed.
  2. Add a compiler pass that does the following:
    foreach ($container->getDefinitions() as $definition) {
      $container->getReflectionClass($definition->getClass(), false);
    }
    
  3. Build the container.

This reminded me a bit of https://github.com/symfony/symfony/issues/32395. :slightly_smiling_face: Maybe we could mark the service as synthetic if the AutoMappingTrait is not available or register a dummy instead?

derrabus
derrabus

Though you could argue that the bridge then should either require its dependencies or tolerate missing them?

The latter is the case. The bridge is a collection of glue code for various Symfony components. If we made all dependencies mandatory, the bridge would pull a lot of components that you probably don't use. The alternative would be that we have a symfony/form-doctrine-bridge, a symfony/validator-doctrine-bridge, a symfony/uid-doctrine-bridge and so on. We would end up micro-managing tiny packages.

started
started time in 1 hour ago
started
started time in 1 hour ago
Activity icon
issue

javiereguiluz issue comment symfony/symfony-docs

javiereguiluz
javiereguiluz

[Ldap] Update ldap.rst

Add single quotes in filter option documentation

javiereguiluz
javiereguiluz

Jason, thanks for this contribution!

Looking at https://github.com/symfony/symfony/blob/b617ee0cd014767fcf52971a9644d2f0bfbdf719/src/Symfony/Component/Ldap/Adapter/AbstractQuery.php#L43-L45 it seems that both strings and arrays are accepted. But I don't know LDAP much, so I'm not sure if 'foo, bar' is equivalent to ['foo', 'bar'] (maybe the first one means AND and the second one means OR?)

Let's ask to someone who knows LDAP well. Thanks!

Activity icon
issue

welcoMattic issue comment symfony/symfony

welcoMattic
welcoMattic

[Translation] Rename translation:update command

As Translation Providers feature has been merged into 5.3, I wonder if we should rename the translation:update command to translation:extract. Indeed, as we have now translation:pull & translation:push commands, the update is more ambiguous than before, as pull command will also update the catalogs.

WDYT about renaming this command on translation:extract? It has the advantage of reflecting exactly what the command does.

Could the renaming be done for 5.4 or 6.0? As we have to respect de BC promise, so deprecate the update command, then remove it.

cc @Nyholm @nicolas-grekas

welcoMattic
welcoMattic

@javiereguiluz that's exactly what I was thinking, in matter of deprecation and alias for 5.4. But I wonder if it's possible to introduce the :extract, :update alias and deprecation notice in 5.3.x as it's not a breaking change, keep this for 5.4 and completely remove :update in 6.0. It will let more time to people to change their applications/infrastructures. WDTY?

Activity icon
issue

Aerendir issue comment symfony/symfony

Aerendir
Aerendir

[PropertyAccess] Add the ability to remove elements from the arrays

In a real generic way, the ability to remove the value from the given path (and the path itself) maybe very useful.

But I think that this can cause incompatibilities with objects.

I've implemented the solution found here in an ArrayWriter I wrote using PropertyAccess component and I thought it maybe useful if implemented in PropertyAccess... Or maybe not...

What do you think about? Is it possible? May this be useful? May be this be correct (as the component is called PropertyAccessand not PropertyWriter) o.O?

started
started time in 1 hour ago
started
started time in 1 hour ago
started
started time in 1 hour ago
started
started time in 1 hour ago
started
started time in 1 hour ago
started
started time in 1 hour ago