I'm using Symfony2 and Assetic. Lately I've been doing a lot of CSS work so at a certain point I needed the command
$ php app/console assetic:dump --env=prod --no-debug
Ever since I've used it I need to run that command everytime I change CSS to see the difference. Now I've did some research and found out that I can put Assetic in to watch mode so I don't have to run the command above after every change using the following command:
$ php app/console assetic:dump --watch --env=prod
However, I just want it back to before I put it into this manual mode. The Symfony2 documentation explains how to do an assetic dump, but not how to put it back in dynamic mode (http://symfony.com/doc/current/cookbook/assetic/asset_management.html#dumping-asset-files)
Does anyone know how to put it back in dynamic mode?
There are two likely possibilities for Symfony not dynamically serving assets from the internal controller:
1. assetic.use_controller is not really true
Confirm 100% you are telling Symfony assetic.use_controller is true. One straightforward method of debugging would be adding this to the top of your controller action and reloading the page:
var_dump($this->container->getParameter('assetic.use_controller'));die();
Not getting true as a return value could mean you are overriding use_controller in either config_dev.php or config_prod.php depending on what environment you are pointing at.
2. Your web server is checking for static assets before passing to Symfony
Most webservers can be configured to check if a URL points to a physical file asset and deliver that file. So if you have dumped assets in Symfony, the webserver might be serving that file and not passing the request onto Symfony.
For nginx see: http://nginx.org/en/docs/http/ngx_http_core_module.html#try_files
For apache see: Apache rewrite rule similar to Nginx try_files
The solution would be to remove the dumped asset files from the file system. Their location depends on where you configured them to go, but check in web/js, web/bundles, etc.
I was looking to add a separate sub-directory to cache directory for one of the services.
What is a default cache path variable (%cache%) for symfony2?
Wasnt easy to find but its %kernel.cache_dir%
I don't understand the difference between these two ways of setting global constants in Symfony2. Is it only about being able to set default values and types in config.yml (+configuration.php) ?
parameters.yml file is the place for all constants that are environment dependent. If you use composer to deploy your app it will ask you about their values. You can also define paramteters.yml.dist to provide some defaults values. If you use parameters.yml you have all parameters needed to setup an application (for example on production server) in one place.
Nope, nope, nope.
parameters.yml is for passwords and server specific parameters such as database connection information.
The main difference between config.yml (and all the other config files) and parameters.yml is that parameters.yml should never be checked in to your source control system. Doing so will expose your passwords and other private information to whomever has access to your source code.
It is the way to separate some independent data in files. You can put in your config.yml all the data located in another config-files (parameters.yml, routing.yml, security.yml and so on). But it will be hard to maintain the whole project even if you are the single developer on the project.
All config data should be splitted according to their domain. Settings for email - in email-settings file, settings for integrating payment system - in payment-settings file, services - in services-config file.
If you have some personal information in the config files you can add this file to .gitignore and define some default values to the your_config.yml.dist. Then you can set up your composer to run some script to fill your_config.yml file like it has been made in symfony standard edition.
Why every single time I generate a curd for some entity , every thing works right except for last action which is updating routing file. I always get this :
Generating the CRUD code: OK Confirm automatic update of the Routing
[yes]? Importing the CRUD routes: FAILED
The command was not able to configure everything automatically.
You must do the following changes manually.
Import the bundle's routing resource in the bundle routing file ....
I know that I can do it manually as the message suggests but I want to understand why it Fails ?
I have done the following checklist:
created translation file respecting format domain.lang.loader
cleared cache
checked that language catalogue is created in cache folder
Though in my twig template file,
{{ 'message'|trans }}
never translates.
Where can I look next in order to make translations work?
Is there any chance that Doctrine Translatable Extension that I am using generates some kind of conflicts?
In Symfony 3.0 I had to clear the cache:
php bin/console cache:clear
I see you already did that, maybe it helps other like me.
Have you enabled the Translator service in your config file?
framework:
translator: { fallbacks: en }
The language catalogue is created in your cache folder irrespective of whether your translator is enabled or not.
Did you try translating in your controller?
$trans = $this->get('translator')->trans('message');
Try to specify domain. If you not specify domain by default it a messages.
{{ 'message'|trans({}, 'some_domain') }}
Then translations can be found in
the kernel root directory/Resources/translations directory;
the kernel root directory/Resources/bundle name/translations
directory;
the Resources/translations/ directory of the bundle.
For example some_domain.fr.yml. Last step is to configure your locale. You can get current locale from request with $request->getLocale()
P.S. try to rm -r app/cache to make sure that the cache is deleted
I could use one of the translations, but not the other and didn't know why. If you have troubles with translations also, read this.
First, standard checklist:
Make sure you enabled and configured translator.
Make sure translation is in proper place and follows proper naming convenction ( domain(messages by default).lang_code.file_format ).
Clear cache using php app/console cache:clear command.
Try to manually call $this->getRequest()->setLocale('en'); in Controller, also you may try to use $this->get('translator')->trans('Some message'); directly in your Controller.
If it still doesn't work, make sure BOM isn't in your translated file. That was my case.
Watch out for BOM in the translated file. The translator who translates the yml file used UTF8 which is OK, but editor he used leaved BOM at the beginning of the file. This is dangerous probably because of PHP's UTF8 BOM bug as it adds few invisible characters to first section of your file.
Btw, debugging your translations may be very helpful, too.
According to the Symfony Translations Documentation page, if you are not using a Service Container for your translation purpose, these are simple steps to go:
Enable and configure Symfony's translation service.
YAML
framework:
translator: { fallbacks: [en] }
PHP
$container->loadFromExtension('framework', array(
'translator' => array('fallbacks' => array('en')),
));
Abstract strings (i.e. "messages") by wrapping them in calls to the Translator ("Basic Translation").
public function indexAction()
{
$translated = $this->get('translator')->trans('Symfony is great');
return new Response($translated);
}
Create translation resources/files for each supported locale that translate each message in the application.
Symfony looks for message files (i.e. translations) in the following default locations:
the app/Resources/translations directory;
the app/Resources/<bundle name>/translations directory;
the Resources/translations/ directory inside of any bundle.
Translation File Name
The filename of the translation files is also important: each message file must be named according to the following path: domain.locale.loader (e.g. filename: navigation.en.xlf):
domain: An optional way to organize messages into groups (e.g. admin, navigation or the default messages) - see Using Message Domains;
locale: The locale that the translations are for (e.g. en_GB, en, etc);
loader: How Symfony should load and parse the file (e.g. xlf, php, yml, etc).
The loader can be the name of any registered loader. By default, Symfony provides many loaders, including:
xlf: XLIFF file;
php: PHP file;
yml: YAML file.
The choice of which loader to use is entirely up to you and is a matter of taste. The recommended option is to use xlf for translations.
Determine, set and manage the user's locale for the request and optionally on the user's entire session.
Clear the cache:
php bin/console c:c
The Translation Process
To actually translate the message, Symfony uses a simple process:
The locale of the current user, which is stored on the request is determined;
A catalog (e.g. big collection) of translated messages is loaded from translation resources defined for the locale (e.g. fr_FR). Messages from the fallback locale are also loaded and added to the catalog if they don't already exist. The end result is a large "dictionary" of translations.
If the message is located in the catalog, the translation is returned. If not, the translator returns the original message.
This helped me to get it worked, since clearing the cache also didn't help.
Symfony 4.6.2:
Try this command to update translation files:
php bin/console translation:update --dump-messages --force de
(Source: https://symfony.com/doc/current/translation.html#configuration)
I can already answer your 2 questions:
1: you can look at
https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Twig/Extension/TranslationExtension.php#L97
https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/Translation/Translator.php
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Translation/Translator.php#L174
2: If you're talking about gedmo doctrine extensions, or Knplabs DoctrineBehaviors, no, there is no way it conflicts with symfonys's translator. These are 2 independant pieces.
Just faced the same issue and fixed it by $this->get('translator')->setLocale('fr'); in the controller action. I fixed it by adding {_locale} in the route path.