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.
Related
I have a vulnerability scanner that returns a finding for an outdated dotNET build - 2.1.17. This needs to be removed.
I have confirmed the file is in the right spot (C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All\2.1.17) and I have deployed the updated version "2.1.25".
Unfortunately, 2.1.17 refuses to be removed - the latest dotnet-core-uninstall tool does not list it as an option, and it doesn't let me just hand-jam 2.1.17 as an -aspnet-runtime option either.
Somewhere on the 'net I found a suggestion that if I remove a certain SDK installation (5xx something - naturally can't find it again) that it would also remove the files. It didn't, and 2.1.17 is still there.
I also tried simply taking ownership of the directory in Windows and then removing it with RMDIR. The directory was removed and all the files were gone, but when I rebooted it looks like it was actually restored and now I'm stuck with 2.1.17 again.
I'm no Developer, so my experience with these packages is in deploying and removing them, which I've done successfully in the past either by deleting the folder (for a very old version) or this dotnet removal tool. I've not had the Runtime simply just not be removable.
Is there a way to get rid of these Runtimes without the dotnet tool?
EDIT: I followed Ian Kemp's advice below and it did briefly remove the 2.1.17 folder that was behind my finding, but it actually restores when the machine is rebooted (causing it to be flagged again).
The solution for me was to remove the 2.1.813 SDK, then manually TAKEOWN and RMDIR the offending directories, then reinstall 2.1.813 SDK.
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
I am trying to use Swift Package manager to update my dependencies locally to match those in the Package.resolved file.
For example, when I update my dependencies I run swift package update, which updates the Package.resolved file, which I then commit. When I pull this new commit on to a computer that has an existing .build directory with the old versions of the dependencies I would like to update the local versions to the one in Package.resolved.
I was expecting swift package resolve to do this, but instead it updates the Package.resolved according to the .build/dependencies-state.json.
The obvious solution is to delete the .build directory, but this means the dependencies are recompiled every time, which can be slow on CI.
I want the equivalent of bundle install, yarn install, or carthage boostrap. Is this possible?
This has been confirmed to be a bug, and I have opened a bug in the Swift JIRA.
First of all, I can't use composer because Im under a corporate network. I tried everything to get composer working :
HTTP_PROXY, HTTPS_PROXY, HTTPS_FULLURI ... Nothing is working. Composer diag gives an OK status for http packagist but FAILS for https connectivity. The error it gives me is:
SSL : Handshake timed out.
But that's not my question, I spent to much time trying to get composer working (But if you got a solution, you'll make my day )
My real question is the following : How to install bundles manually
I want to install this bundle : http://knpbundles.com/pierredup/MenuBundle.
What I did to try installing the bundle :
Registering the bundle in appKernel.php :
new \CS\MenuBundle\CSMenuBundle()
Tried to add it in the autoload.php :
$loader->add('CS', __ DIR __.'/../vendor/CS/CSMenuBundle.php');
(Dont know how to add php code properly ... )
But it doesn't work, got the following error :
Attempted to load class "CSMenuBundle" from namespace "CS\MenuBundle".
Did you forget a "use" statement for another namespace?
And then, even if it is not a good practise, I tried to add it to autoload_namespaces.php and did a dump-autoload after that :
'CS\MenuBundle' => array($vendorDir. '/CS/')
I still have an error, but not exactly the same one :
Attempted to load class "CSMenuBundle" from namespace "CS\MenuBundle".
Did you forget a "use" statement for "CS\MenuBundle\CSMenuBundle"?
Now I'm a bit frustrating, I saw many posts (not on Stack) where people scream because we have to use composer to manage dependencies. I totally agree with that, but I can't, so I'm trying to find another way, and as I can't find any clear tutorial which explains how to install vendors without composer, here I am.
Note that I commented on the problems I see with your approach on your question directly.
However, I looked at the package you want to use to see if there would be ANY chance installing it somehow (preferring Composer). I don't think it is possible or feasible.
composer require customscripts/menubundle:dev-master - this would be the easy command for Composer to do everything. However there are problems:
The package you want to use is not registered on packagist.org, so there is no way to simply use Composer on a machine properly connected to the internet, grab the packages, zip them and transfer them to the place you need it.
To work around this, you'd manually add the repository to the composer.json file - this might actually work (however it takes way too much time on my VM). You'll end up with code that was last edited in the year 2012!
The dependencies of that code will likely not work anymore. The composer.json of that package lists "require": {"knplabs/knp-menu-bundle": "dev-master", "symfony/framework-bundle": ">=2.0,<2.3-dev", "jms/di-extra-bundle": "1.1.*"} - even the first "knplabs/knp-menu-bundle" will never work. Remember that the code of this package is from 2012 - now we are in 2016, so "knp-menu-bundle" has seen four years of development on the master branch. There simply is NO WAY of knowing which commit had been used of this package. You'd have to reverse-engineer this lost information.
Additionally, you see why Composer is awesome and doing it manually is bad: In addition to your wished package, you have to download the three additional packages mentioned here.
But detecting packages that have to be added is a recursive task: knp-menu-bundle has a dependency on knp-menu (with no further dependencies) and symfony/framework-bundle (already added). symfony/framework-bundle itself has a dependency on 9 more Symfony packages and doctrine/common... and so on. You have to detect every single package of this and download the correct version manually if you cannot use Composer.
Skipping your original package because that installation wasn't finishing while I was typing my answer, I tried to install knp-menu-bundle to see how many packages would be installed. Composer installed 20 packages, some of them using Symfony in 2.8 (it SHOULD be compatible with Symfony 2.2 stuff, shouldn't it) - and I simply ran composer require knplabs/knp-menu-bundle:1.1.1 to grab a similarly old version of knp-menu-bundle from 2012.
The strength of using Composer is that it supports rapid development by allowing updating quickly, downgrading reliably (if you commit your composer.lock file and always use tagged versions), and simply allowing to add new packages instantly. Not being able to use Composer is a very severe limitation for you as a PHP developer. Talk to your boss or team lead about your company's situation with the HTTPS proxy, and find a solution to use Composer. The alternative is to develop everything from scratch on your own or waste plenty of hours trying to fiddle with manual downloads that don't fit together easily.
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.