I would like to inject a YAML configuration to a service in Symfony. Currently, I inject path of my bundle and a relative path to the file and parse it manually with Yaml::parse but is there an easier way to do this?
So the goal would be that the constructor of the service would receive an array of the already parsed YAML config.
To put some more detail about it:
Currently, I have a YAML file in a Resources directory in my bundle and to parse it in a service, I use something like this:
$yamlFile = sprintf(
'%s/%s',
$container->get('kernel')->getBundle('MyBundle')->getPath(),
$pathToFile
);
So I have to inject both the container (can I somehow inject just the path to the bundle?) and the path to the file. I wouldn't mind restructuring my system a bit, e.g. put the yaml file in the config directory of the bundle, if that would help, but I'd like to keep it separate from other configuration.
You can load needed configuration in bundle extension like described there: http://symfony.com/doc/current/cookbook/bundles/extension.html and save it to new parameter, or inject to any service you like.
Related
According to README.md from https://github.com/hslavich/OneloginSamlBundle/tree/1.x
The only way to provide certificate for OneloginSaml is via app/config/config.yml
We strongly don't want to load them by pasting it into yaml file, instead, we want to load certificates from a file, given the path to the file in this yaml file.
I noticed that the only way to achieve this would be to override the class HslavichOneloginSamlExtension.
What is the "right" way to override a HslavichOneloginSamlExtension class to allow certificates to be loaded from a file path?
The would suggest using environment variables for private certificates and use them in .yml files likes this:
privateKey: '%env(PRIVATE_KEY)%'
I think it is not possible to load a file in a yml config.
My goal is to add to a new Symfony 4.4 project an extra config file to define some behavior of the system. It could be anything, like, pancakes.yaml:
pancakes:
enablePancakes: false
I wish to know how can I load that config file. find a way to read its parameters and values to change some custom behavior the system might have but honestly I think I'm not smart enough to understand what the documentation says.
For now it could be anything, like printing the configuration file values, for now I only need to know how to load it.
you can update the following file :
# config/service.yaml
# This file is the entry point to configure your own services.
# Files in the packages/ subdirectory configure your dependencies.
parameters:
locale: 'en'
chat_update_interval: 10000
and use service decoration in your new application to override your parameters.
I have a line in a sample Symfony app that reads:
$seo = $this->get('sonata.seo.page');
However the config.yml file reads:
sonata_seo:
page:
metas:
property: ... etc ...
I've read http://symfony.com/doc/current/service_container.html but I'm not clear how exactly the get('sonata.seo.page') works. Does it somehow equate to the key / values in the config file? i.e. does the underscore in sonata_seo get magically changed to a period?
You cannot access values in config.yml direcly, like values in parameters.yml.
That file can store configuration values for bundles thought.
Read more here
What it is 'getting' in this instance, usually within a controller action, is a Symfony Service.
In this instance, sonata.seo.page is a reference to a service, setup in the sonata-project/seo-bundle, which returns an instance of the SeoPage class. Normally, this information is set within your local configuration file (config.yml, or a file that it includes), but the service returns the class that allows you to change the values at runtime.
No service are (directly) defined inside config.yml. It's the bundle that define the service. With $this->get('sonata.seo.page'); you get those.
The config.yml file it's just used to customize the bundles.
The SeoBundle defines the semantic configuration section sonata_seo from config.yml and registers the own Extension of DI container.
Extension implements the load() method. Configuration values from sonata_seo are passed as its first argument.
Method loads various resources including service definition from Resources/config/service.xml:
<parameter key="sonata.seo.page.default.class">Sonata\SeoBundle\Seo\SeoPage</parameter>
...
<service id="sonata.seo.page.default" class="%sonata.seo.page.default.class%"/>
Next, extension set up sonata.seo.page definition with given configuration parameters.
This process will be invoked during the container compilation, when the service definition and its settings will be embedded in the container. Result of this process you can find in the dumped container in the cache directory.
This is a typical scheme of work for the Symfony bundles: define the configuration structure, make an extension, set up the services.
I want to access the base_path (base_url registered) of a specific Asset component directory from a controller in order to store my reports to a specific path preconfigured in config.yml.
I started changing my configuration, after upgrading to Symfony 2.7, like the following:
app/config/config.yml
framework:
assets:
version: 'v5'
version_format: '%%s?version=%%s'
base_path: ~
base_urls: ['http://cdn.example.com', 'https://secure.example.com']
packages:
reports:
base_path: bundles/mybundle
So, when I request a specific route, with the correct request parameters my controller generate the HTML from a particular Twig template and, at the end, it will be converted to PDF using KnpSnappyBundle.
At last, my purpose is to build a list of generated PDF reports accessible from a public assets directory.
$kernel->locateResource()
However, I can access the complete path using a workaround like the following:
$this->container->get('kernel')->locateResource('#MyBundle/Resources/public/reports')
Using parameters.yml
I have also asked for some hints and it seems legit to use the parameters.yml in order to manage the Asset component configuration. So, from the controller, they would be accessed using $this->getParameter() and, at the same time, as a configuration value for Asset.
The simplest way to deal with that is to define it as a parameter in parameters.yml, as you suggested yourself.
It's really easy to get it and it totally makes sense.
Update
I wanted to provide a bit more reasoning for my answer, so I will cite http://symfony.com/doc/current/best_practices/configuration.html as a reference.
Reading there, it seems that you should put into "parameters.yml" all infrastructure parameters which do not really change your application behaviours. I think this applies to your case as well: your application does not change its behaviour according to assets paths, it only needs to know where they are.
So, again, I'd say that putting them in parameters.yml not only provides you an easy solution but also it's a "good practice".
Is there a way of getting the Doctrine Uploadable extension to store a path relative to a directory in the database?
We use Capistrano to manage releases on our servers, so when a file is uploaded, the stored path looks like: /var/www/sitename/releases/20140625151300/web/uploads/$filename. While the files themselves are safe (uploads is a symlink), when the release is deleted the paths necome broken.
For example, the stored path could just be the filename or relative to %kernel.root_dir%.
I had the same problem and rather than dig into the listener (which I assume would be the other possibility) I set the path in my parameters file and then referenced that parameter in the stof_doctrine_extensions section. This way it allowed me to have the real path but allow it to be different for each version.
In app/config/parameters.yml
parameters:
....
acme.upload.path: '/The/Absolute/Path/app/Resources/files/uploads'
....
In app/config/config.yml
stof_doctrine_extensions:
....
uploadable:
default_file_path: %acme.upload.path%
....
If you're not using the stof bundle then I assume you would just pass the parameter into your listener as one of the calls.
Like I say though, I'm pretty sure you would be able to go into the listener and play with that but I found this the easiest approach.