I've upgraded a site from Drupal 7 to Drupal 8. I did it manually, not using composer. So I downloaded the zip core tarball, and then installed modules manually (the old way, by downloading and extracting modules in modules/contrib and enabling them in "Extend" in the admin of the site). The site is working perfectly. The "status report" shows no errors and just one non-relevant warning. I seem to have read that composer was the recommended way but the old procedure could still be used.
But then I read that for Drupal 8 and 9 and beyond, composer is supposed to be the tool to use. So I'm starting to adjust my site to the use of composer. I read that if I installed the last Drupal 8 version (in my case 8.9.13) the site is already composer compliant.
But the first command I tried (in a test site fortunately):
composer upgrade
misconfigured completely my site. Here is what it does:
Loading composer repositories with package information
Updating dependencies
Lock file operations: 0 installs, 8 updates, 0 removals
- Upgrading composer/installers (v1.9.0 => v1.10.0)
- Upgrading drupal/core (8.9.1 => 8.9.13)
- Upgrading drupal/core-composer-scaffold (8.9.1 => 8.9.13)
- Upgrading drupal/core-project-message (8.9.1 => 8.9.13)
- Upgrading drupal/core-recommended (8.9.1 => 8.9.13)
- Upgrading drupal/core-vendor-hardening (8.9.1 => 8.9.13)
- Upgrading pear/archive_tar (1.4.9 => 1.4.12)
- Upgrading symfony/http-kernel (v3.4.41 => v3.4.44)
Installing dependencies from lock file (including require-dev)
Package operations: 2 installs, 0 updates, 26 removals
- Removing webmozart/path-util (2.3.0)
- Removing webmozart/assert (1.9.1)
- Removing webflo/drupal-finder (1.2.2)
- Removing symfony/var-dumper (v4.4.19)
- Removing symfony/polyfill-php80 (v1.22.0)
- Removing symfony/finder (v5.2.2)
- Removing symfony/filesystem (v4.4.19)
- Removing psy/psysh (v0.10.6)
- Removing nikic/php-parser (v4.10.4)
- Removing league/container (2.4.1)
- Removing grasmash/yaml-expander (1.4.0)
- Removing grasmash/expander (1.0.0)
- Removing drush/drush (10.3.6)
- Removing dnoegel/php-xdg-base-dir (v0.1.1)
- Removing dflydev/dot-access-data (v1.1.0)
- Removing container-interop/container-interop (1.2.0)
- Removing consolidation/site-process (2.1.0)
- Removing consolidation/site-alias (3.0.1)
- Removing consolidation/self-update (1.2.0)
- Removing consolidation/robo (1.4.13)
- Removing consolidation/output-formatters (3.5.1)
- Removing consolidation/log (1.1.1)
- Removing consolidation/filter-via-dot-access-data (1.0.0)
- Removing consolidation/config (1.2.1)
- Removing consolidation/annotated-command (2.12.1)
- Removing chi-teck/drupal-code-generator (1.33.1)
- Installing drupal/core-vendor-hardening (8.9.13)
- Installing drupal/core (8.9.13)
29 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
All those removals already made me think that my site is not composer ready.
Can anybody give me a hint on where to look on how to adapt my site to composer? Or is it now impossible to do if I downloaded and installed core and modules the old way? That would be very bad news for me, I spend a lot of time migrating my Drupal 7 site, this version ugrade has been the hardest and I've upgraded sites from Drupal 4 on.
Comments
Sounds like you are leaving out steps
Looks like something with dev requirements.
Nothing wrong with what you mentioned above. Although I wouldn't recommend that procedure.
With the zip core tarball you get a composer managed drupal code base based on drupal/legacy-project. You could have started that with composer yourself. Or even better, one based on drupal/recommended-project for having separate web folder.
Nothing wrong with traditional extending Drupal. What is managed with composer needs to be managed with composer. Recommend against using upgrade/update. Suggest to whitelist primary dependencies of your project for update. Either with their dependencies whitelisted or using option --with-dependencies. As you have no idea what is going to happen, use --dry-run to find out what it intents to do. Better save than sorry.
Below the protocol for doing as described. Note, the site wasn't installed.
Thanks for the prompt answer.
Thanks for the prompt answer. I do have a separate web folder, paralell to a vendor folder. In the upper level I have composer.json and composer.lock, the ones which came with the Drupal core tarball I downloaded and extracted. I know it would have been better to start the install directly with composer, but I got some error or something and since I knew how to do it "manually", I went the old way, hoping to be able to adapt to composer once I had my site working, like we use to do with drush. But it looks harder.
Anyway, I will try the above (with dry-run and later in my test file), and keep reading the documentation for composer.
I tried
I tried
and it does nothing.
composer update --dry-run --with-dependencies
does the same as
composer update --dry-run
that is, it suggests to remove a lot of stuff and if run it destroys my installation. This is what is suggests:
composer update --dry-run --with-dependencies
Loading composer repositories with package information
Updating dependencies
Lock file operations: 0 installs, 8 updates, 0 removals
- Upgrading composer/installers (v1.9.0 => v1.10.0)
- Upgrading drupal/core (8.9.1 => 8.9.13)
- Upgrading drupal/core-composer-scaffold (8.9.1 => 8.9.13)
- Upgrading drupal/core-project-message (8.9.1 => 8.9.13)
- Upgrading drupal/core-recommended (8.9.1 => 8.9.13)
- Upgrading drupal/core-vendor-hardening (8.9.1 => 8.9.13)
- Upgrading pear/archive_tar (1.4.9 => 1.4.12)
- Upgrading symfony/http-kernel (v3.4.41 => v3.4.44)
Installing dependencies from lock file (including require-dev)
Package operations: 2 installs, 0 updates, 26 removals
- Removing webmozart/path-util (2.3.0)
- Removing webmozart/assert (1.9.1)
- Removing webflo/drupal-finder (1.2.2)
- Removing symfony/var-dumper (v4.4.19)
- Removing symfony/polyfill-php80 (v1.22.0)
- Removing symfony/finder (v5.2.2)
- Removing symfony/filesystem (v4.4.19)
- Removing psy/psysh (v0.10.6)
- Removing nikic/php-parser (v4.10.4)
- Removing league/container (2.4.1)
- Removing grasmash/yaml-expander (1.4.0)
- Removing grasmash/expander (1.0.0)
- Removing drush/drush (10.3.6)
- Removing dnoegel/php-xdg-base-dir (v0.1.1)
- Removing dflydev/dot-access-data (v1.1.0)
- Removing container-interop/container-interop (1.2.0)
- Removing consolidation/site-process (2.1.0)
- Removing consolidation/site-alias (3.0.1)
- Removing consolidation/self-update (1.2.0)
- Removing consolidation/robo (1.4.13)
- Removing consolidation/output-formatters (3.5.1)
- Removing consolidation/log (1.1.1)
- Removing consolidation/filter-via-dot-access-data (1.0.0)
- Removing consolidation/config (1.2.1)
- Removing consolidation/annotated-command (2.12.1)
- Removing chi-teck/drupal-code-generator (1.33.1)
- Installing drupal/core-vendor-hardening (8.9.13)
- Installing drupal/core (8.9.13)
29 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Remember that this is a working 8.9.13 with several modules installed manually.
As mentioned you are leaving out steps!
Having a web folder next to vendor suggests mixing drupal/recommended-project with drupal/legacy-project. Sounds like you don't understand that composer.json, composer.lock and vendor/composer need to be in sync. And made in sync with composer. The amount of packages to be removed proves that is not the case! It is only not the case because thing were done but not mentioned.
The protocol I provided above is doing exactly what you claim to have done. It works!
The removals can be because vendor (vendor/composer/installed.json) contains packages no longer desired or composer.lock also contains them. In which case your manual actions are not consistent. Either the composer.lock or vendor/composer/installed.json comes from different environments.
Thanks again for your
Thanks again for your comments. It is obvious that I'm just starting with composer, which is not surprising since I never used it for my Drupal 7 sites. The thing is as I said in my original message: 1) I installed the Drupal site the old way, 2) I migrated my Drupal 7 to Drupal 8, very hard work, but it finished with a perfectly working Drupal 8, 3) I tried to check if I can manage my new site with composer, in the documentation it is said that if I started with Drupal 8.9.13 the site should be composer ready. As you see, it is not.
I think I found the place in the documentation to start now making my site really synced in the composer way. If i manage, I will put a summary here explaining what I had to do.
=-=
comperizing an already existing site can be painful. If you run into issues, I suggest a composer installed site and a migration of your D8 -> new composer D8 site. D8 -> D8 is not as painful as D7 - D8 migration.
Thanks VM, I'm already
Thanks VM, I'm already thinking of doing that.
A suggestion for the documentation is that it should state clearly that if a site is started the "legacy" way, it will need a new migration to the "composer" way. From the documentation it looks as if it fine to start the site either way, and that you can start using composer later. Maybe it is not painful but the least you want to do after the D7 -> D8 migration is another one.
Again, you are leaving out information.
Your situation can only exist when doing things wrong. Only you are not telling us what you did. Starting a site the way you did resulted in a 8.9.1 code base managed as drupal/legacy-project by composer. There is no need to composerize, it is already managed by composer.
My protocol above shows that it is no problem to upgrade to 8.9.13. There are no removals as the composer info from the tarball is consistent. The error is in your project, not the procedure you mentioned. Something happened in your project that is causing these unexpected removals. It should be no problem to figure out whether these packages are in vendor and/or in composer.lock.
The packages that it wants to remove is because you managed to corrupt it. Either the lock or vendor is manipulated outside of composer. Possibly by others and you are not aware of it. Fact remains that it is corrupt.
To fix, use the composer.json for a new project. Run `composer install` and compare with original project. Overwrite composer.lock and vendor from the original with that from the new project. Conclude with updating the database.
Choosing for legacy way is by definition the composer way. Obviously, legacy is not the only composer way. There are far more composer ways than legacy and recommended !
Thanks, good to know it may
Thanks, good to know it may be a mistake on my part. As far as I can tell, I just downloaded the 8.9.13 zip archive, uncompressed, and started migrating my site. But maybe in the process I did something to bork the installation. As I said, the migration was a lot of work.
You must have started with 8.9.1
Composer won't upgrade from 8.9.1 to 8.9.13 when already on 8.9.13 !
=-=
unsure what documentation you are referring to since you didn't link but most of it is community-driven which means you can edit it for clarity when you find something that warrants it.
Thanks, you're right, now
Thanks, you're right, now that I got back I see the page can be edited. I was referring to this link:
https://www.drupal.org/docs/installing-drupal/add-composer-to-an-existin...
"Even if you installed Drupal 8.8.0 from the tarball, Composer was pre-installed. So you should be able to manage your site using Composer without taking any extra steps to convert the site."
But as I was suggested earlier, may be this is true but I did something wrong in the installation that borked my site.
Very poorly formulated!
The code base in a tarball is created with composer using the drupal/legacy-project template, as such it is ready to be managed with composer. No need to composerize. Contrary to a git fork of the project.
So, it is not that Composer is pre-installed, the code base is created with Composer.
I think I manage to fix my
I think I managed to fix my installation. I basically followed the instructions in:
https://www.drupal.org/docs/installing-drupal/add-composer-to-an-existin...
but as if it was a pre Drupal 8.8 site. The steps were:
1) Reinstall Drupal 8.9.13 in a new folder with:
where "new_html" was the name of the folder I chose.
2) Just erase new_html/web and copy the web folder of my existing borked site.
3) Reinstall all modules that I had with compose:
composer require drupal/module
where "module" was substituted by each module I had in web/contrib.
And that was just about it, I just readjusted a couple of things in settings.php for the new site folder, such as the private files setting, and pointed the web server to the location of the new web.
Now "composer update" updated some things, and the next "composer update" said everything is up to date. And the site status doesn't show any error or warning.