I am using symfony 2.8 but I don't think it matters for this question.
My production deployment is displaying a different version of the stylesheet than from debug environment.
What do I need to do to align production with debug?
Turns out my problem was when running the following command:
$ php app/console cache:clear --env=prod --no-debug
I would get a
ERROR 522 Validation failed : no DTD found
for one of my translations messages xliff
I removed that and ran the command again and then ran the server and my css was correctly being utilized.
Related
I'm currently having a mental breakdown, hitting my head against different walls.
I'm trying to get my app online to prod, and have been trying for weeks now.
I've had this error a lot : Symfony - twig - Autoloader expected class
Now, it's evolved, and I have this :
Sometime, after clearing cache, running composer install / update a dozen time, this error goes away and..... I get the old error again!
Please help if you've ever seen anything like this
How are you making deployment on prod environment?
Maybe there are some files doubled so loader doesn't recognize them correctly?
Some deployment methods dont remove files deleted at project (php storm deploy).
Last times i had error with Twig_Environment. It was after i upgraded my project's Symfony version from 3.3 to 3.4.
To Sf 3.3 all services defined at services.yml at enabled bundles was PUBLIC.
Since 3.4 they are all PRIVATE by default.
What i did was to add some .yml code at every services.yml file i had:
_defaults:
public: true
Without this code Twig_Environment could not see some Twig Extensions and other classes.
Also I have read your last post. So You don't have access to console, yup?
Maybe try to have second instance of Your project (locally) where everything is set up to prod env?
Then try to:
composer dump-autoload -o
And other preparings for prod:
php bin/console a:install --symlink
php bin/console a:dump --env=prod
php bin/console c:c --env=prod
After this You should upload vendor/autoload.php, generated assets, etc. at production server. And this should happen every site update.
It's really bad having Sf project withoud ssh access.
Situation:
Production mode
Change a file
One of the pages on the site returns the following 500 internal error.
Run composer update, and the error goes away.
Change a file and the problem returns.
The code calling the twig_upper_filter is buried deep inside the now embedded in symfony bootstrap templates.
What does composer update do that might fix this? It is repeatable (on one server only).
UndefinedFunctionException: "Attempted to call function
"twig_upper_filter" from the global namespace." at
Symfony 2.6.
Because at the end of composer update it does a cache clear, everytime you change something somewhere you need to clear the cache for the change to be visible in the production enviroment.
This is automatic on the development enviroment.
You need to run this from console:
cd /your/symfony/app
php ./app/console cache:clear --env=prod
Letting the web server build the cache resolved the problem. The command line environment must not be exactly the same as the web server php. On this server it is difficult to actually run command line scripts as the web server user.
Therefore, clearing the cache on the command line with no warmup is the work around:
php ./app/console cache:clear --no-warmup --env=prod
After A Symfony Upgrade, composer.json
"symfony/symfony": "2.4.*",
"symfony/symfony": "2.7.*",
I get a Error while running phpunit tests. In env dev and prod everything works fine.
log output:
request.CRITICAL: Uncaught PHP Exception Twig_Error_Runtime: "The native_profiler" extension is not enabled in "#WebProfiler/Profiler/toolbar_js.html.twig"
The twig native profile extension is turned on automatically if the debug mode is on and turned off if the debug mode is off in Symfony 2.7. So if you warming up the cache with debug mode on the twig templates are rendered with the profiler enabled.
But if a test runs with debug off (for example Kris Wallsmith solution is used) the extension is disabled in the tests (but still enabled in pre-rendered templates), that cause the error.
Solution: before running tests clear the cache with debug mode off.
app/console cache:clear --env=test --no-debug
The cache will be cleared and warmed up without the twig profiler.
I had the same issue today, but slightly different. At the end I found out, that the TwigProfiler is enabled in debug-mode automatically.
In KernelTestCase.php I found:
isset($options['debug']) ? $options['debug'] : true
So in my TestCases I added the option 'debug' => false and it worked again.
I had a similar error on our jenkins. Our CI job runs (1) PHPUnit tests, than (2) functional tests with LiipFunctionalTestBundle and at the end (3) protractor tests.
The twig templates were compiled by the functional tests (2) which configures the kernel to be in debug mode. The Protractor tests however start a PHP server in test env but not in debug mode. So the twig templates were not compatible. I solved the problem by deleting the cache between step (2) and (3).
Clearing the cache after changing debug mode appears to have solved my issue.
I had to use --no-debug switch also when generating javascript translation files with bazinga:js-translation:dump
For example like this command
../app/console bazinga:js-translation:dump -vvv --no-debug -e stage
Try updating version. It helped for me from version 1.18 to 1.24.
Using Symfony 2.7 with Sylius 0.13
More info:
https://github.com/symfony/symfony/issues/15318
https://github.com/twigphp/Twig/pull/1824
Trying to deploy my updated Symfony2 application, I ran into the following problem.
(note that my application uses the new Symfony 3 directory structure. replace bin/console with app/console and var/cache with app/cache if you're using the current directory structure)
I have recently renamed one of my service classes (VariantSlugListener). When deploying the application on the staging server, I got the following error when running bin/console assetic:dump --env=prod:
PHP Fatal error: Class 'MyBundle\Listener\VariantSlugListener' not
found in
/var/www/example.com/staging/var/cache/prod/appProdProjectContainer.php
on line 494
Line 494 of appProdProjectContainer.php contains the following code:
return $this->services['3f288d4f09c9906944ba7e17358f669b942397baf9d79d5ff0737bb756df7023_1'] = new \MyBundle\Listener\VariantSlugListener();
It is no surprise that \MyBundle\Listener\VariantSlugListener can not be found, since it has been renamed to \MyBundle\EventListener\VariantSlugSubscriber with the latest update. The solution would be to simply clear Symfony's cache.
However, when trying to clear the cache (using bin/console cache:clear --env=prod) I get the exact same error as with the assetic:dump command. So I get an error because my Symfony cache is outdated, but I can not clear the cache because of the error.
I can probably get around this by manually deleting the contents of the var/cache directory, but that doesn't feel like the best solution.
Am I missing something?
Probably you are triggering some events that are handled in your VariantSlugListener when doing 'cache:clear'. So your only choice is to just remove contents of the cache directory or to replace the value manually and then run cache:clear to warm up the cache.
I have two machines, a development machine running Windows and a production machine running Linux.
The problem I have is that Assetic is not deploying (or finding any) assets in the Linux production machine (neither in dev nor in prod mode). It was working in the previous deployment attempts, then all of a sudden it stopped without having changed anything in the system or the config.yml/config_prod.yml file.
The command I am using for dumping:
sudo php app/console assetic:dump --env=prod --no-debug
The assets have been defined in the bundles' public folders and have been installed beforehand and moved to the web folder with:
php app/console assets:install --symlink web/assets
FWIW, I found out that mthaml-bundle was causing the problem, which I am using in the project. Reverting to an older commit solves the problem, in the meantime I am going to report it.