Skip to content
This repository was archived by the owner on Feb 4, 2023. It is now read-only.

Conversation

victormacko
Copy link

These changes allow Symfony 5 to be used as well as Twig 3 (the namespaced classes are available in Twig 2 already)

composer.json Outdated
"symfony/framework-bundle": "^3.4|^4.1|^5.0",
"symfony/options-resolver": "^3.4|^4.1|^5.0",
"symfony/property-access": "^3.4|^4.1|^5.0",
"symfony/security": "^3.4|^4.1|^5.0",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

symfony/security has no 5.0 version
https://github.com/symfony/security/releases

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ... strange ... I must've misread it before.
Just looking into this a little further, the only components in the code seem to be the HttpKernel & Console ... did you want me to narrow this list down a little further, or just fix up the version reference for the moment?

@victormacko
Copy link
Author

Any thoughts on this @sspat ? ... I can adjust the version for that component, or otherwise just remove it entirely as I can't see any reference to the security component in the codebase.

The only components in the code seem to be the HttpKernel & Console ... did you want me to remove the unused components from the composer file?

@mbabker
Copy link

mbabker commented Jan 6, 2020

I'm only commenting here because I tried updating one of my apps to use Twig 3.0 and it failed out because of this bundle (since the 1.1.4 stable release didn't declare its dependency on Twig, I ended up with errors compiling the container instead of a Composer conflict).

The symfony/security-core package should be loaded in, that one is used (check the AbstractDatatable class for one case).

As for the actual Symfony dependency list, just on a cursory scan of use statements, I'd suggest these additions (these are directly used by this bundle, don't rely on them to come in as transient dependencies):

  • symfony/config
  • symfony/dependency-injection
  • symfony/http-foundation
  • symfony/http-kernel
  • symfony/property-access
  • symfony/routing
  • symfony/translation

Another thing to be aware of is the removal of Symfony\Component\Translation\TranslatorInterface in Symfony 5.0. Symfony\Contracts\Translation\TranslatorInterface will need to be used instead (for forward/backward compat the typehint will need to be dropped and a runtime instanceof check should be used instead, see BabDev/PagerfantaBundle@2cd009f#diff-1c116d91c7f3d923861ef83b58691bb3 for an example on how I handled this elsewhere).

You should probably also update the Travis config to run a build with Symfony 4.4 and 5.0, the CI for this PR would fail on that Symfony version because of the translator interface change.

$this->authorizationChecker = $authorizationChecker;
$this->securityToken = $securityToken;

if (!($translator instanceof LegacyTranslatorInterface) && !($translator instanceof TranslatorInterface)) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure this is required?
I suppose this should work with both TranslatorInterface.
No need to force people to use Contracts

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it makes sure that you're getting either the deprecated interface from the component (available in Symfony 4.4 and earlier) or the newer interface from the contract (available for Symfony 4.3 and newer). The runtime check replaces the typehint that can't be enforced across multiple Symfony major versions.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yeah I didn't realize you added ! on both conditions. I thought you wanted to force the use of Contracts.

But since the translation interface param is injected with DI, I am not sure this check is very useful.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Seb33300 the services.xml just passes in the @translator service ... so in 4.4 it'll be the previous class... in 5.0 it'll be the new contracts-interface.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know and this means this cannot be something else than a TranslatorInterface.

The the check is quite useless, except if the developer override the configuration to pass something else.

If you really want to keep this check I think this is better to place it at the beginning of the method.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the contracts interface existed in 4.1 though; https://symfony.com/doc/4.1/translation.html

AuthorizationCheckerInterface $authorizationChecker,
TokenStorageInterface $securityToken,
TranslatorInterface $translator,
object $translator,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Composer manifest says PHP 7.1 is the minimum version, so the object typehint isn't available.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cheers for the feedback - now changed :)

"symfony/dependency-injection": "^3.4|^4.1|^5.0",
"symfony/http-foundation": "^3.4|^4.1|^5.0",
"symfony/http-kernel": "^3.4|^4.1|^5.0",
"symfony/framework-bundle": "^3.4|^4.1|^5.0",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know if there is any reason to not be compatible with Symfony 4.0?

Copy link
Collaborator

@Seb33300 Seb33300 Jan 7, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change made here for security reasons: #885

Not sure if its the responsibility of this bundle to force people to upgrade because this version of symfony is not maintained anymore.
IMH we should keep compatibility with 4.0 and let people upgrade when they can.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dunno, but it's a bit out of scope for this PR ... i've only just expanded the existing composer requirements to 5.0 and added the extra components based on the existing 4.1 requirements for the existing components.

pokurek added a commit to RedWeb/DatatablesBundle that referenced this pull request Jan 21, 2020
@Seb33300
Copy link
Collaborator

Can someone confirm if this PR worked properly for him?

@Seb33300 Seb33300 mentioned this pull request Feb 12, 2020
@LauLaman
Copy link

Can this be merged and tagged?

@Seb33300 Seb33300 merged commit 661438c into stwe:master Mar 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants