the Symfony2 service SecurityContext is deprecated since version 2.6. In a current project under developpment we frequently use user roles. Therefore, it make senses to
switch immediately to the new security services of 2.6.
On the other hand we use FOSUserBundle in the project as well. As far as I see, the latest version of this bundle is at the level of Symfony 2.3. Since in the dev-environment version 2.6 ist not 100% bc with 2.3 (for example if Xdebug is acivated) the usasge of the new services yields conflicts ...
Our questions:
does someone know whether the FOSUserBundle will be compatible wih 2.6 in the near future?
has someone encountered the same problem and can give hints to handle it?
Best wishes
The problem has been solved.
First of all it turned out that all the Deprecated-errors - which prevented a development in our current envirement/configuration - came from a Symfony 2.7-dev version.
It seems that Symfony 2.6 itself does not have such errors. In this sense the above comments were correct. Thus, for the moment one has to use Symfony 2.6 in order to rewrite the own app such that the usage of security aspects becomes compatible with version 2.6.
From a FOS-developer we got the feedback that there will be an 2.6 compatible update of the user bundle before the release of a stable Symfony 2.7 vesion. Therefor one can switch smoothly form 2.6 to 2.7.
Related
I'm trying to upgrade a Symfony instance from 2.8 to 3.0, and, while I was checking the deprecations in profiler, I found:
The Twig\Template class implements Twig_TemplateInterface that is deprecated since 1.12 (to be removed in 3.0) (2 times)
The Twig\Lexer class implements Twig_LexerInterface that is deprecated since 1.12 (to be removed in 3.0)
The Twig\Compiler class implements Twig_CompilerInterface that is deprecated since 1.12 (to be removed in 3.0)
The Twig\Node\Node class implements Twig_NodeInterface that is deprecated since 1.12 (to be removed in 3.0)
The Twig\Parser class implements Twig_ParserInterface that is deprecated since 1.12 (to be removed in 3.0)
My Twig version is 1.42.4
Just to confirm: we agree this is deprecation messages from twig itself, telling it will remove those functions in its own 3.0 version ? I mean: it's not Symfony telling it will not support this anymore in its 3.0.0 ?
I also suppose upgrading Twig will not help on this. It is the the responsible for those calls I guess ;)
After confirming the above basics, how can I locate the bundle which uses those deprecated functions, because I suppose THIS is the package I need to upgrade first (I'm pretty sure the problem is not in my own code...) ?
The message does not give so many details, and... the stack is just unclear to me...
DebugClassLoader::loadClass()
spl_autoload_call()
class_exists() (called from Template.php at line 5)
require() (called from DebugClassLoader.php at line 169)
DebugClassLoader::loadClass()
spl_autoload_call()
ReflectionClass::__construct() (called from ClassCollectionLoader.php at line 307)
ClassCollectionLoader::getOrderedClasses() (called from ClassCollectionLoader.php at line 120)
ClassCollectionLoader::load() (called from Kernel.php at line 405)
Kernel::doLoadClassCache() (called from Kernel.php at line 124)
Kernel::boot() (called from Kernel.php at line 180)
Kernel::handle() (called from app_dev.php at line 28)
Maybe that can help to answer: I noticed the deprecation warnings appear ONLY when I load a page for the first time, or when I just deleted the cache... So, it's something generating the Symfony cache, which is calling deprecated features...
At last, but not least, I tried to upgrade Twig from 1.x to 2.x, knowing Symfony composer tells "twig/twig": "^1.0||^2.0". I first though it would go to 2.x, but it just upgraded it to the lmatest 1.x (1.42.4), my current version... Composer message was not clear about what was reponsible of the fact it did not go higher...
IF I understood well, those deprecation warnings are not about Symfony upgrade itself, so I 'could eventually go for it. I have something in my instance, that uses old Twig functions, so I would like to get rid of it...
BONUS question: sometimes, I wonder... it's so complicated to fight with all those version constraints... Wouldn't it be more simple just to use generic composer.json, provided with the symfony version we are trying to reach, instead of editing the one we get for years, in our old version ? At least, I guess all libraries would be updated at versions tested by developpers ?
Thanks for helping, and happy new year ;)
In short, sometimes deprecations are reported for vendor code that you can't really change. This is the case. It's useless for you.
It will go away eventually, once you upgrade to higher Symfony/Twig.
After Symfony 4.1 update to 4.3 I get templating deprecation warnings.
After reading https://symfony.com/blog/new-in-symfony-4-3-deprecated-the-templating-component-integration
I've removed templating and added fragments.
But now I get this error
You cannot set both "templating.hinclude_default_template" and "fragments.hinclude_default_template", please only use "fragments.hinclude_default_template"
I had this same error. It seems FOSUserBundle was still using templating. I was already planning to remove this bundle. When I removed FOSUserBundle the error went away. It may not be an option for you, but maybe it will help you find the problem.
I already read this cookbook, about non shared service, so my question, can this be used in symfony 2.7 ?
As already said, this feature was introduced in 2.8.
So, in 2.7, you can deal with scopes to have several instances of the same service across your application.
To get the same behavior as shared (a new instance for each service call), use:
your_service:
# ...
scope: prototype
From the cookbook that you linked.
2.8 The shared setting was introduced in Symfony 2.8. Prior to Symfony 2.8, you had to use the prototype scope.
There is a combo with versions just below the main title. Select "2.8 version" and check yourself.
I would like to know is there any plugin available in symfony 1.4 to login with Google+.
Hey Wow that is some old legacy going on there.
Unfortuantly I don't know of any bundles that are still maintained for Symfony 1.
But!!!! I have heard of a legacy handler that will allow you to place you symfony 1 app into symfony 2.
https://github.com/Ingewikkeld/IngewikkeldWrapperBundle
This will allow you to refactor over time but that will mean you can use a symfony 2 bundle for google plus something like
https://github.com/hwi/HWIOAuthBundle
I need to upgrade an existing rather large application from Symfony 2.0.15 to Symfony 2.4.x (replace with current version).
I'm not quite sure what would be the best strategy to do so. Migration critical features like forms or esi are used, of course :)
Upgrade "step by step" from one major version to another (2.1, 2.2, 2.3, 2.4)
Upgrade directly from 2.0.x to 2.4
Do you have any tips / experience to share ? Would appreciate it :)
Thanks,
Stephan
Each new version comes with an update UPGRADE-2.x.md file containing all intructions to convert your application from the immediately previous version.
I had to do that on my project as well, and I found the step-by-step method more natural and easier to manage. Fact is, there is no file such file as UPGRADE-2.0-to-2.4.md that would help you out for a direct conversion to 2.4.
I shall first recommend to make sure that none of your code uses obsolete functionnalities of Symfony 2.0 (not sure if there are deprecated parts in this version, though), because these can be removed in ulterior versions and will not be included in the UPGRADE file.
If you have done indeep modifications of the core Symfony code, you may find that some undocumented modifications are needed. For instance, there is a custom error handler in my project, extending the Symfony error handler. Well, although it was not documented in the UPGRADE file, the signature of ErrorHandler::handle() was modified and needed to be updated in my custom handler.
Similarly, I had to modify some namespaces because files had been moved in the framework code.
The conversion is still ongoing and I'm currently experiencing a weird error I'm trying to get rid of: The 'request' scope on services registered on custom events generates errors in the logs.