I recently got this error when running bin/console doctrine:migrations:migrate:
The metadata storage is not up to date, please run the sync-metadata-storage command to fix this issue.
However, running the sync-metadata-storage command yields the same error.
What can I do?
As mentioned in this GitHub issue one possible fix is to specify the MySQL server version in the server URL:
DATABASE_URL=mysql://root:#127.0.0.1:3306/test?serverVersion=mariadb-10.4.11
Then, you should be able to run the bin/console sync-metadata-storage command.
Read more about this configuration option in the doctrine documentation:
[…] you can pass the serverVersion option with a vendor specific version string that matches the database server version you are using […]
If you are running a MariaDB database, you should prefix the serverVersion with mariadb- (ex: mariadb-10.2.12).
I had to downgrade the doctrine/doctrine-migrations-bundle to version "^2.1"
Not sure if that applies here, but I had issues with doctrine lately aswell.
I did a composer update and ever since then, my project wouldn't run anymore. My issue was based on a new version of the following bundle:
https://symfony.com/doc/master/bundles/DoctrineMigrationsBundle/index.html
They restructred the doctrine_migrations.yaml file and I still had the old one. I tried to change the contents to the new 3.0 version but that lead exactly to your error.
Since the bundle comes with the package: symfony/orm-pack you first have to unpack the to be able to manually change the version inside your composer.json: composer unpack symfony/orm-pack
After unpacking you will see the following line inside your composer.json: "doctrine/doctrine-migrations-bundle": "*", which I changed to "doctrine/doctrine-migrations-bundle": "^2.1". Then i ran composer update again. You may specify only the migrations bundle if thats all you want to update.
Hello so i could fixe my issue just by removing (?versionname=5.7) to the database_url and it worked just fine
Related
I was running Symfony 4.4.8, and I wanted to update my project. So I ran:
composer update
It did automatically update the DoctrineMigrationsBundle (https://packagist.org/packages/doctrine/doctrine-migrations-bundle) from 2.1.2 to 3.0.1.
Composer failed at first because doctrine_migrations.yaml was not compatible with the DoctrineMigrationsBundle 3.0.1, so I ran:
composer recipes:install --force -v
composer install
But: it appears that the DoctrineMigrationsBundle v 3 has a totally different configuration and does not use the "migrations_versions" SQL table anymore, but a new "doctrine_migrations_versions"-table and a new migrations directory ('%kernel.project_dir%/migrations' instead of '%kernel.project_dir%/src/Migrations').
This means that every time you do:
php bin/console doctrine:migrations:diff
You will get in the migration:
$this->addSql('DROP TABLE migration_versions');
I read at https://symfony.com/doc/master/bundles/DoctrineMigrationsBundle/index.html that you can set the table name in doctrine_migrations.yaml manually like this:
doctrine_migrations:
storage:
table_storage:
'table_name': 'doctrine_migrations'
But that is of no use, because the v 3 table has an extra column "execution_time" and in the "version" column a namespace is prepended (e.g. "DoctrineMigrations\Version20200702112735.php"). So both tables are incompatible.
I can't find any information anywhere on properly upgrading DoctrineMigrationsBundle from v2 to v3.
I must say I am surprised by this, I thought that "composer update" was to be safe. Appearently, one of the symfony bundles didn't add a version limit automatically where it should if an upgrade is not possible.
So what should I do? Should I just let composer downgrade the DoctrineMigrationsBundle again? Or is there some way to get an upgrade of DoctrineMigrationsBundle from v2 to v3 to work after all?
I think everything is explained here: https://github.com/doctrine/migrations/blob/master/UPGRADE.md
If you have already update the bundle config, just run that command:
bin/console doctrine:migrations:sync-metadata-storage
It should work.
So this is what I got when I try to add the Symfony tool (Symfony version : 3..)
The project was created from another machine and cloned into mine (Git)
I could make the necessary changes for composer.phar and php.exe when adding the Composer tool and I had no problem concerning that but when it comes to add the Symfony tool I got a " Failed to parse command output " error message and there are the details of the error
enter image description here
What should I do?
Thank you
As you can see, yours paths contain both "/" and "\". I think this happened because you create the project in a linux/unix machine and now you are working on Windows.
Path problem is in composer files. Is vendor folder committed in the repository? If yes, remove it and re run composer install.
I'm working with a copy of Symfony (2.8.9) which works perfectly on my development server.
I've cloned the same repository that this server pulls from, down to my local, and updated composer / ran the Symfony installer. I started getting an error:
You have requested a synthetic service ("request").
I did a little research, and found that this is a bug in the next version of Symfony, 2.8.10, as reported here:
https://github.com/symfony/symfony/issues/19840
I will await the bug being fixed in 2.8.10, but in the meantime, I'd love to be able to downgrade from 2.8.10 to 2.8.9, so my local copy runs and matches the copy on my development server.
I've seen posts regarding changing the version numbers in composer.json, but all my numbers related to Symfony say "2.8", with the minor version number excluded. Additionally, my composer.json file matches on both my dev server and local.
Should I add the minor version number ".9" to the end of the composer.json dependencies, and install the dependencies with composer? Is it enough to add the minor version number to only Symfony-related dependencies, and have all other dependencies work correctly, or are there other version numbers that should be changed as well? Is my approach correct, or is there another way to do this entirely?
You can edit just one line in your composer.json:
"require": {
...
"symfony/symfony": "2.8.*, !=2.8.10",
...
This way, you tell Composer to avoid that specific version. All other dependencies will be retrieved automatically.
Important: you have to remove your composer.lock file first, as Composer will complain that you're locked to the very same version you're trying to avoid.
Disclaimer: backup and test first. I tested on a base Symfony install, not sure if other package will complain.
i am trying to set up a symfony2 project on a HHVM machine,
The HHVM is running on FastCGI as explained in the hhvm tutorial, thus running behind an apache2 server on Debian.
I have created everything but when i try to run my application i am getting the following error:
ContextErrorException: 16777217: Declaration of Doctrine\DBAL\Driver\PDOConnection::prepare() must be compatible with that of Doctrine\DBAL\Driver\Connection::prepare() in /LOCATION/shared/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php line 30
I am thinking this has something to do with PDO in HHVM but i tested it using the class_exists('PDO') and that says that PDO is enabled
This is an issue that was fixed via a pull request to the master branch of doctrine/dbal about 2 months ago. However, depending on the branch of Symfony 2 you are using, that doctrine/dbal fix may not be included.
https://github.com/doctrine/dbal/pull/373
If it is possible to use a version of Symfony 2 that includes this latest doctrine/dbal fix, I think you will see that issue go away.
I've had the same issue and upgrading doctrine/orm and doctrine/dbal to latest versions (listed below) fixed my problems.
doctrine/orm : 2.5.#dev
doctrine/dbal: 2.5.#dev
To safely upgrade, open your composer.json file, find and change the versions like so:
composer.json
"require": {
// ... other package requirements
"doctrine/orm": "~2.5.*#dev",
"doctrine/dbal: "~2.5.*#dev",
// .. more packages
Then run composer update doctrine/* which will remove the old versions of doctrine and update all doctrine packages.
The declaration of
Doctrine\DBAL\Driver\PDOConnection::query()
must be compatible with
PDO::query(string $query, ?int $fetchMode = null, mixed ...$fetchModeArgs)
I had the same problem, but the solution was to just change the PHP version from version 8 to 7.3.
Login to your Cpanel with your credentials, search for MultiPHP Manager.
Select the domain or subdomain that you would like to change the PHP version of.
Select from the dropdown menu and chose the appropriate PHP version. (For me, 7.3 worked like a charm.)
Everything worked like it supposed to.
Recently I started a project in Symfony2 from the BETA version available on symfony.com
After a while, I needed to upgrade to the master branch, so I retrieved the latest from github and switched it in vendor/symfony.
However, my bootstrap.php.cache and bootstrap_cache.php.cache are not upgraded, which has generated errors.
I tried clearing the symfony cache, to no avail.
How can I update these files to correspond to my project?
In the 2.0 release the original file is here:
./vendor/bundles/Sensio/Bundle/DistributionBundle/Resources/bin/build_bootstrap.php
Edit: in release 2.3 the file is here
vendor/sensio/distribution-bundle/Sensio/Bundle/DistributionBundle/Resources/bin/build_bootstrap.php
If you run the composer update command you will also update your project dependencies which is not the desired behaviour here. If you do that you'll have to test the new changes to see if they do affect your application somehow.
So if you just want to rebuild your bootstrap cache file then I suggest you run the post-update-cmd command.
Therefore you should use:
composer run-script post-update-cmd
which in my case executes the following scripts (see composer.json):
"scripts": {
"post-install-cmd": [
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile",
"Mopa\\Bundle\\BootstrapBundle\\Composer\\ScriptHandler::postInstallSymlinkTwitterBootstrapSass"
]
}
Please consider that you can also create a new set of scripts in there to just rebuild the bootstrap file and clears the cache without installing the assets and so on:
"scripts": {
"reset-bootstrap-cmd": [
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache"
]
}
and then... composer run-script reset-bootstrap-cmd
In the latest 2.1.0-DEV, the actual script is here:
./vendor/sensio/distribution-bundle/Sensio/Bundle/DistributionBundle/Resources/bin/build_bootstrap.php
I'm using Symfony Standard 2.0.9 (without Vendors).
To update bootstrap.php.cache, just run
php bin/vendors update
This will update all vendors (including Symfony itself) and always call that build_bootstrap.php script for you.
Have you tried running:
php bin/build_bootstrap.php
This will regenerate the bootstrap files
You might prefer to use composer install which "re-installs" the system to the state definied in the composer.lock file and generates autoloads and bootstrap.php.cache. Using composer update updates all packages and changes the state of your system.
I feel like the build_bootstrap script is always changing location :)
So, if you are working with several Symfony versions and don't know where the build_bootstrap is, this will do the trick (Linux/Mac only):
$ cd vendor/
$ find . -name build_bootstrap.php
i couldnt fix a problem on my bootstrap cache, nor update it . i was getting alot of this
[Symfony\Component\Debug\Exception\ContextErrorException]
Warning: Invalid argument supplied for foreach() in /home/sites/fuji/app/bootstrap.php.cache line 2870
Script
Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache
handling the post-update-cmd event terminated with an exception
although they were great suggestions, and i did try the rebuilding of bootstrap cache file after backing it up, and to run composer update these still gave me the same problem.
Solution for me:
i shelled into the pc with the site files on it,
rm -rf app/cache/* -R removed everything inside the cache directory then i was able to run both composer update, AND clear cache etc.. with no problems.
Search for where the "build_bootstrap.php" located at.
for my case in Symfony3.4
php ./vendor/sensio/distribution-bundle/Resources/bin/build_bootstrap.php