doctrine migrations configuration: kernel.project_dir is not interpolated - symfony

I'm trying to generate and execute migrations using doctrine/doctrine-migrations-bundle.
Project specs:
Project deployed in docker. Mapping configured successfully.
Framework: symfony.
Kernel::getProjectDir() overrided successfully.
Project dependencies (not all, only important for this topic) from composer.json:
"doctrine/doctrine-bundle": "^2.1",
"doctrine/doctrine-migrations-bundle": "^3.2",
"doctrine/orm": "^2.7",
"symfony/framework-bundle": "5.1.*",
My project has migrations for two databases. There are 2 config files for this. An example of one of them for understanding (absolute path in container /opt/app/config/packages/migrations/some_config.yaml):
custom_template: '%kernel.project_dir%/config/migration_template.txt' # <- this not works
# custom_template: '/opt/app/config/migration_template.txt' # <- this works
em: some_em
transactional: false
migrations_paths:
'DoctrineMigrations': '%kernel.project_dir%/src/DoctrineMigrations' # <- this not works
#'DoctrineMigrations': '/opt/app/src/DoctrineMigrations' # <- this works
Problem:
I'm trying to generate migration, using following command:
bin/console doctrine:migrations:generate --configuration='/opt/app/config/packages/migrations/some_config.yaml'
An exception is thrown with an message:
The specified template "%kernel.project_dir%/config/migration_template.txt" cannot be found or is not readable
For absolute path everything works fine.
I have tried to debug doctrine-migrations package code and found, that path %kernel.project_dir%/config/migration_template.txt does not turn into /opt/app/config/migration_template.txt

I think the problem is that the command is implemented in the doctrine/migrations lib and is unaware of Symfony, and therefore doesn't know about container parameters. The Doctrine migrations docs have an example for such a path, so you might try this:
'./src/DoctrineMigrations'
(didn't try myself though).
The relevant part in the docs is here: https://www.doctrine-project.org/projects/doctrine-migrations/en/3.6/reference/configuration.html#configuration

Related

Warning: Ambiguous class resolution Doctrine

After running composer update , I keep having the error below:
Warning: Ambiguous class resolution,
"Doctrine\ORM\Persisters\Entity\BasicEntityPersister" was found in
both "$baseDir .
'/engine/Library/Doctrine/ORM/Persisters/Entity/BasicEntityPersister.php"
and
"/var/www/html/shop5/vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/Entity/BasicEntityPersister.php",
the first will be used. Warning: Ambiguous class resolution,
"Doctrine\Common\Proxy\AbstractProxyFactory" was found in both
"$baseDir .
'/engine/Library/Doctrine/Common/Proxy/AbstractProxyFactory.php" and
"/var/www/html/shop5/vendor/doctrine/common/lib/Doctrine/Common/Proxy/AbstractProxyFactory.php",
the first will be used.
I have tried to run the following commands but none of them works:
composer dump-autoload -o
composer clearcache
Any idea how to fix this issue ?
Thank you
[shopware5 - php7.0]
This is the normal behavior of Shopware.
The Doctrine library uses the final class statement quite often and in order to get it to work with the Shopware attribute system the classes were replaced through the composer autoloading. You can find the changed files in shopware/engine/Library/Doctrine/Common
FYI: This is the reason why Shopware only works when the composer autoloading is optimized.
composer dump-autoload --optimize
Otherwiese you will encounter random errors from invalid or wrong entities.
To get rid of these warning you should add files with ambiguous classes to exclude-from-classmap in your composer.json:
"autoload": {
...
"exclude-from-classmap": [
...
"vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/Entity/BasicEntityPersister.php",
"vendor/doctrine/common/lib/Doctrine/Common/Proxy/AbstractProxyFactory.php"
]
},
Then dump-autoload will ignore these files.
This is the reason why Shopware only works when the composer autoloading is optimized.
I didn't investigate how this is done in Shopware, but this also could be fixed/improved. For composer more precise definitions for namespaces have a precedence. So if you have this in your autoload:
"autoload": {
"psr-0": {
"somevendor\\somepackage\\": "vendor/somevendor/somepackage/",
"somevendor\\somepackage\\db\\": "overrides/somevendor/somepackage/db/"
}
},
And if you request for somevendor\somepackage\db\Entity class, the composer will first search in overrides/somevendor/somepackage/db/Entity.php and only if it can't find it, it will try vendor/somevendor/somepackage/db/Entity.php. This is because definition for somevendor\somepackage\db namespace is more precise than for somevendor\somepackage.
So if you want to override 3rd-party classes in this way, you should define more precise namespaces than 3rd-party library do.

howto fix composer.json in forked symfony bundle

I'm trying to install symfony-cmf/routing-auto version 2.0.0-RC1 , it requires jms/metadata:1.5.* which is working under Symfony 2x.
My current project works on Symfony 3.3.x which makes this bundle unable to install, so I made a fork on github, changed req. to jms/metadata:1.6.*
and added one line:
"replace": "symfony-cmf/routing-auto:2.0.0-RC1",
in order to test if it will work and I used in console:
composer require mkoniarz/routing-auto:dev-master
but then I got error:
Reading composer.json of mkoniarz/routing-auto (dev-master) Skipped branch dev-master, Invalid argument supplied for foreach()
What else I should fix to get this fork installed by composer?
PS my composer is up to date.
Did you try to remove the composer.json file ? I'd an similar error, i think it can be resolve your problem.
Or you should to try :
composer require symfony-cmf/routing-auto
always check composer.json:
composer.phar validate
then commit if valid :)
error was in "replace" line:
"replace": "symfony-cmf/routing-auto:2.0.0-RC1",
should be:
"replace": { "symfony-cmf/routing-auto":"2.0.0-RC1" },

How does composer know symfony environment

i try to deploy an app in "integration" environment but after the "composer update" command, the parameters.yml file generated doesn't contains may integration parameters
Here is what i did :
I created a "config_integ.yml" file in app/config with :
# app/config/config_integ.yml
imports:
- { resource: parameters_integ.yml }
- { resource: config.yml }
framework:
profiler: { only_exceptions: false }
the parameters_integ.yml file contains parameters for integration environment. example of the beggining :
parameters:
database_host: localhost
database_port: null
database_name: test_integ
database_user: root
the parameters.yml.dist contains these parameters with default values :
parameters:
database_host: 127.0.0.1
database_port: ~
database_name: symfony
database_user: root
How can i tell to composer to take the parameters_integ.yml file to build the parameter.yml file ? Because i will have a prod environment after, i can't write my parameters in parameters.yml.dist file.
Tell me if you need other informations
Thanks for your help
1) You should include composer.json and composer.lock in your VCS
2) You should not include parameters.yml in your VCS
3) When deploying Sf application you should use composer install
http://symfony.com/doc/current/deployment.html#c-install-update-your-vendors
difference between composer install and composer update (+ composer.lock): https://blog.engineyard.com/2014/composer-its-all-about-the-lock-file
4) I can think of a few ways for creating parameters.yml in the integration environment:
you manually create parameters.yml file and place it beside parameters.dist.yml
or
if there is no parameters.yml or parameters.yml has some missing parameters, when you run composer install, you will be prompted to enter missing parameters and parameters.yml will be created/updated during the composer install process
or
you can have an app/config/parameters folder containing parameters_prod.yml and parameters_integ.yml files, and one of those files is automatically copied into parameter.yml file during deployment (most complicated solution)
If you want integration environment to be accessible via a browser, you should also create a front controller for it. Copy the web/app.php file to web/app_integ.php and edit the environment to be integration:
// web/app_integ.php
// ...
// change just this line
$kernel = new AppKernel('integ', false);
// ...
More info at https://symfony.com/doc/current/configuration/environments.html#creating-a-new-environment
And the answer to the question from the title, "How does composer know symfony environment" - I think composer has no idea about Sf environment :)
The composer has require-dev option for packages that you do not need in your production, packages required for running tests (phpunit for example), some debugging stuff during development, etc.
For an example this is how one of my composer.json files looks like:
...
"require-dev": {
"sensio/generator-bundle": "^3.0",
"symfony/phpunit-bridge": "^3.0",
"doctrine/doctrine-fixtures-bundle": "^2.3",
"nelmio/alice": "^2.1",
"deployer/deployer": "^4.0"
},
...
If I run composer install --no-dev, these packages won't be installed in the vendor directory.
But, how Sf knows when to include/omit some packages in the app.
That is defined inside AppKernel.php.
In the composer.json, under "require-dev" key I defined that I don't want doctrine fixtures in production.
So, inside AppKernel.php I put these lines of code:
if (in_array($this->getEnvironment(), ['dev', 'test'], true)) {
...
$bundles[] = new Doctrine\Bundle\FixturesBundle\DoctrineFixturesBundle();
}
And if I run my app in production mode, there will not be DoctrineFixturesBundle.
Best practice is to set your default parameters in your app/config/parameters.yml.dist file.
See this link:
http://symfony.com/doc/current/best_practices/configuration.html#canonical-parameters
When you run:
composer update
it will use the parameters.yml.dist and overwrite the parameters.yml with the values in the dist file.

What is the difference difference between AwsS3 and Amazon S3 (amazon_s3) for KnpGaugretteBundle?

I'm trying to use Gaufrette and S3 in my Symfony project and it doesn't work. I got the error:
PHP Fatal error: Class 'AmazonS3' not found in /var/www/headoo/app/cache/dev/appDevDebugProjectContainer.php on line 514
So I guessed that maybe I am using the wrong version of the adapter. But I don't understand what is the difference between AwsS3 and Amazon S3. The doc seems a little short for those who are starting with S3.
I use one of the latest versions of aws-sdk-php which is 3.2.*.
I'm using this set of bundles in latest symfony and it works great:
"knplabs/gaufrette": "dev-master",
"knplabs/knp-gaufrette-bundle": "dev-master",
"amazonwebservices/aws-sdk-for-php": "dev-master",
"cybernox/amazon-webservices-bundle": "dev-master",
"aws/aws-sdk-php": "~2.7#dev"

Add phpexcel to my project

I need to generate Excel files, I did a search and phpexcel seems to be good and stable. I'd like to know:
* how to integrate it into my project given that it's a symfony2.0 project
* if I can do all what I do normally on excel file through this php library (cells colors, adding lists ...)
Thanks,
If you are using composer, and since PHPExcel is registered with Packagist, then this is simply a matter of adding PHPExcel to your composer.json config, for example:
"require": {
"php": ">=5.3.3",
"symfony/symfony": "~2.4",
"doctrine/orm": "~2.2,>=2.2.3",
...
"phpoffice/phpexcel": "~1.8.0",
This is from a Symfony 2.4 configuration, but should work equally well for any version of Symfony.
Run $ php composer.phar update to grab the package and it should then be autoloaded into your project. You can then use PHPExcel immediately, say in a controller:
<?php
namespace SomeProject\SomeBundle\Controller;
use PHPExcel;
Or just reference \PHPExcel directly from within your code.
Update:
Note that composer found it's way into Symfony from around version 2.0.4, and was used as an alternative to the old deps and deps.lock files until the deps approach was deprecated from 2.1.
If you're still using deps, you can append this to your deps file:
[PHPExcel]
git=git://github.com/PHPOffice/PHPExcel.git
target=phpexcel
and run php bin/vendors install. This will put the PHPExcel in vendors/phpexcel.
Register PHPExcel with the registerPrefixes array in app/autoload.php and it should be available to your project as described above.
$loader->registerPrefixes(array(
'Twig_Extensions_' => __DIR__.'/../vendor/twig-extensions/lib',
'Twig_' => __DIR__.'/../vendor/twig/lib',
'PHPExcel' => __DIR__.'/../vendor/phpexcel/Classes'
));

Resources