8000 avoid deprecation notices with Symfony 2.8 by craue · Pull Request #22 · craue/CraueConfigBundle · GitHub
[go: up one dir, main page]

Skip to content

avoid deprecation notices with Symfony 2.8 #22

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 5, 2015

Conversation

craue
Copy link
Owner
@craue craue commented Aug 3, 2015

This PR is meant for trying to avoid as many deprecation notices as possible introduced by symfony/symfony#15079.

I'm pretty sure I've updated all relevant code to not use deprecated functionality while keeping BC. The remaining notices seem to be triggered by Symfony itself.

Travis log:

… 2.8

(the remaining ones seem to be triggered by Symfony itself)
@craue
Copy link
Owner Author
craue commented Aug 5, 2015

I found out that removing the getName method from built-in form types (at least for CollectionType, HiddenType, and TextType as these are used by the bundle's tests -- removing it from FormType leads to an exception) helps in reducing the remaining notices, but this method is going to be removed only in Symfony 3.0. And the notice regarding the scope is obviously trigged by AsseticBundle. So it looks like there's nothing more I can actually do about getting rid of all notices.

craue added a commit that referenced this pull request Aug 5, 2015
avoid deprecation notices with Symfony 2.8
@craue craue merged commit 09ec87c into master Aug 5, 2015
@craue craue deleted the avoid-deprecation-notices branch August 5, 2015 15:52
*/
public function configureOptions(OptionsResolver $resolver) {
$resolver->setDefaults(array(
'data_class' => get_class(new Setting()),
Copy link

Choose a reason for hiding this comment

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

create a setting object just to set the class name?

Copy link
Owner Author

Choose a reason for hiding this comment

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

Yes, obviously. 😏 I'll change that.

Copy link
Owner Author

Choose a reason for hiding this comment

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

Done in #23.

@craue
Copy link
Owner Author
craue commented Sep 9, 2015

@stof, do you see why the tests exit with a fatal error on Symfony 3.0-dev, btw?

@stof
Copy link
Contributor
stof commented Sep 9, 2015

this looks like there is a Twig_Node_Expression_Function created for a non-existent function. This seems weird as Twig should be preventing it before reaching that point. It seems even more weird if it happens only on Symfony 3. I will look into it this evening

craue added a commit that referenced this pull request Sep 14, 2015
@craue
Copy link
Owner Author
craue commented Sep 15, 2015

@stof, any news? I remember when I once tried to find out what's wrong there, it led me to something Assetic-related.

@craue
Copy link
Owner Author
craue commented Nov 30, 2015

@stof, I'm still getting that fatal error Call to a member function needsEnvironment() on boolean in /home/travis/build/craue/CraueConfigBundle/vendor/twig/twig/lib/Twig/Node/Expression/Function.php on line 25 with current 3.0 dev, see https://travis-ci.org/craue/CraueConfigBundle/jobs/93953095#L278.

@stof
Copy link
Contributor
stof commented Nov 30, 2015

@craue can you run a build without disabling xdebug, so that we can get a stack trace for the fatal error ?

@craue
Copy link
Owner Author
craue commented Nov 30, 2015

@stof
Copy link
Contributor
stof commented Nov 30, 2015

@craue this is because your functional test kernel is not enabling the Asset component, and so the asset function is not defined. Assetic needs it.

And the Twig_Node_Expression_Function does not check for the function existence as it expects it to have been validated earlier when parsing the template (and the Assetic node does not validate whether the function is registered or no). This is why you get a fatal error rather than an exception.

@craue
Copy link
Owner Author
craue commented Nov 30, 2015

@stof, now I remember having fixed that in commit 8afeeea already. 😆 Shame on me.

@stof
Copy link
Contributor
stof commented Nov 30, 2015

@craue just cherry-pick this commit to merge it in master 😄

@craue
Copy link
Owner Author
craue commented Nov 30, 2015

Issue is that PrependExtensionInterface is not available in Symfony 2.1, so I got that fix waiting in the branch to drop support for 2.1 and 2.2. I just didn't remember that. Now I'm back on track and will release a new version when 3.0 got stable. 😏

@stof
Copy link
Contributor
stof commented Nov 30, 2015

@craue you can put this in AppKernel::registerContainerConfiguration directly in your testsuite. It will be simpler 😄

@craue
Copy link
Owner Author
craue commented Nov 30, 2015

With a separate config file for >=3.0? I'm already using multiple config files for various test scenarios. That would complicate things.

@stof
Copy link
Contributor
stof commented Nov 30, 2015

@craue
Copy link
Owner Author
craue commented Nov 30, 2015

@stof, thanks. Done in 27bf675.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0