I just finished the Symblog tutorial for symfony. Everything works just fine except when I try running the project on the production environment. On the blog page the following error message appears on the top of the page and on top of the comment section: Deprecated: getEntityManager is deprecated since Symfony 2.1. Use getManager instead in F:\xampp\htdocs\php\symblog\vendor\doctrine\doctrine-bundle\Doctrine\Bundle\DoctrineBundle\Registry.php on line 71
I am wondering why because I used the same version (symfony 2.3.10) for other projects and in these I have never seen this message. So what should I do?
Thanks in advance!
You should replace your code to use getManager() method instead of getEntityManager() or just change your error_reporting PHP setting (take a look at the below snippet).
The reason of not showing other depreciation messages in other project is different error reporting configuration (probably somwthing similar to the following - deprecated warnings will not be reported):
error_reporting(E_ALL ^ E_DEPRECATED);
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.
I recently updated ZF2 and started getting this error in the command line when using the Doctrine tool. While it does not effect the work being done, it is annoying.
I have searched about but as I am relatively new to using Doctrine, I am not 100% sure what I need to do to fix this:
PHP Deprecated: "Symfony\Component\Console\Helper\DialogHelper" is
deprecated since version 2.5 and will be removed in 3.0. Use
"Symfony\Component\Console\Helper\QuestionHelper" instead. in
/var/www/cloud/vendor/symfony/console/Helper/DialogHelper.php on line
34 PHP Stack trace:
I am using ZF2 version: 2.4
Thanks for any help on this!
running composer update cleared up the problem for me.
When I deploy a symfony website including mapped superclass entities online, I get the following error:
AnnotationException: [Semantical Error] The annotation "#Doctrine\ORM\Mapping\MappedSuperClass" in class Acme\DemoBundle\Entity\Foo does not exist, or could not be auto-loaded.
Worst is, this error doesn't show if we use web/app.php (with debugging mode true), whereas it blocks the programm if you use web/app_dev.php.
I should add that, locally, this error does not show up while using either web/app.php or web/app_dev.php.
Does anyone have a clue about this dark mystery?
Thanks in advance for any hints.
Ok,
I will be answering to my own question, for the sake of future deployment processed by any fellow programmer.
the problem was in the doctrine annotation.
I put:
#MappedSuperClass
whereas it is:
#MappedSuperclass
REMEMBER:
on mac, it doesn't make a difference. But also on linux if in prod mode (with debug option at true). that is why it was working with web/app.php.
However, in dev mode (web/app_dev.php), it doesn't work on a linux environment, which makes a difference between capitalized and normal letters.
I hope it will save you the headaches it caused me ;)
Regards,
Wisebes
[issue solved]
I have a MVC5 project using signalr to perform updates to a list. Inside script.js, there is a variable link to defined as var link = $.connection.hub. There is also a bundleconfig file to load the dependent scripts, signalr/jquery and jquery in the proper order of course.
The script /signalr/hubs is loaded in from the html manually.
bundles.Add(new ScriptBundle("~/bundles/signalr").Include(
"~/Scripts/script.js",
"~/Scripts/jquery.signalR-2.0.2.min.js"));
When the VS 2013 Web project is run, it works fine until the project is copied over to another PC that it does not work as intended. The variable link is undefined as $.connection is undefined too ($ is defined though).
I presume that jquery.signalR-2.0.2.min.js is not read or executed at all.
Questions:
Might this have anything to do with the environment of the PCs? (Windows 7 is OK, Windows 8 is not OK)
What could prevent jquery.signalR-2.0.2.min.js from running?
Does creating a new View/Controller play a part in the error (creating a view, using a layout page)?
Please see similar question: SignalR and MVC bundle as it shows how to add SignalR into an MVC bundle. I think their answer should help solve your problem.
I would comment instead of answer, but I don't have enough reputation.
I am trying to create pretty error pages for my application by following this cookbook article. Sometimes a bug slips in, which causes the application to return a single line: 503 Service Unavailable. It would make my life a whole lot easier if only I could see the underlying error or exception thrown. Switching over to the development environment doesn't help either as the error templates are only used in production.
I figured out that I needed to add TwigBundle to assetic's configuration to use javascript and css assets. Problems like this are really hard to debug in the production environment.
Setting the debug mode to true in my front controller doesn't help, since production error templates get replaced by development templates.
EDIT
Thanks to Mike Purcell I managed to retrieve the errors provided. I got
Uncaught exception 'Symfony\Component\Routing\Exception\ResourceNotFoundException' in /[snip]/app/cache/prod/appprodUrlMatcher.php:669
Turns out the framework should be handling the exception, but in the case of a possible error inside the error Twig template, it just decides to throw a 503 error.
How do I turn on error reporting for the production environment in a Symfony2 application?
I'm tired of guessing what's wrong and clearing the cache. What is the best way to debug Twig's error templates in production?
The best way to see what errors are being thrown in production is to configure Monolog to email the errors too you or alternatively to a file.
Have a look at the Symfony2 Cookbook on emailing logs http://symfony.com/doc/master/cookbook/logging/monolog_email.html
To make the error pages look nicer have a look at this cookbook entry on how to do that http://symfony.com/doc/master/cookbook/controller/error_pages.html
There are open source tools specifically built for error reporting like Sentry, which has a native Symfony client.
disclaimer: I work for Sentry