Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When I execute the following command, errors appear and the updates do not occur :
www.EXEMPLE.com@vps000000:~/public_html$ composer update drupal/core --with-dependencies
Cannot create cache directory /home/www.EXEMPLE.com/.composer/cache/repo/https---packages.drupal.org-8/, or directory is not writable. Proceeding without cache
Cannot create cache directory /home/www.EXEMPLE.com/.composer/cache/repo/https---packagist.org/, or directory is not writable. Proceeding without cache
Cannot create cache directory /home/www.EXEMPLE.com/.composer/cache/files/, or directory is not writable. Proceeding without cache
Gathering patches for root package.
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Conclusion: don't install symfony/console v3.2.13
- Conclusion: don't install symfony/console v3.2.12
- Conclusion: don't install symfony/console v3.2.11
- Conclusion: don't install symfony/console v3.2.10
- Conclusion: don't install symfony/console v3.2.9
- Conclusion: don't install symfony/console v3.2.8
- drupal/core 8.4.0 requires symfony/console ~3.2.8 -> satisfiable by symfony/console[3.2.x-dev, v3.2.10, v3.2.11, v3.2.12, v3.2.13, v3.2.8, v3.2.9].
- drupal/core 8.4.0-beta1 requires symfony/console ~3.2.8 -> satisfiable by symfony/console[3.2.x-dev, v3.2.10, v3.2.11, v3.2.12, v3.2.13, v3.2.8, v3.2.9].
- drupal/core 8.4.0-rc1 requires symfony/console ~3.2.8 -> satisfiable by symfony/console[3.2.x-dev, v3.2.10, v3.2.11, v3.2.12, v3.2.13, v3.2.8, v3.2.9].
- drupal/core 8.4.0-rc2 requires symfony/console ~3.2.8 -> satisfiable by symfony/console[3.2.x-dev, v3.2.10, v3.2.11, v3.2.12, v3.2.13, v3.2.8, v3.2.9].
- drupal/core 8.4.x-dev requires symfony/console ~3.2.8 -> satisfiable by symfony/console[3.2.x-dev, v3.2.10, v3.2.11, v3.2.12, v3.2.13, v3.2.8, v3.2.9].
- drupal/core 8.5.x-dev requires symfony/console ~3.2.8 -> satisfiable by symfony/console[3.2.x-dev, v3.2.10, v3.2.11, v3.2.12, v3.2.13, v3.2.8, v3.2.9].
- Conclusion: don't install symfony/console 3.2.x-dev
- Installation request for drush/drush (locked at 8.1.13, required as ^8.1) -> satisfiable by drush/drush[8.1.13].
- drupal/commerce 2.x-dev requires drupal/core ~8.4 -> satisfiable by drupal/core[8.4.0, 8.4.0-alpha1, 8.4.0-beta1, 8.4.0-rc1, 8.4.0-rc2, 8.4.x-dev, 8.5.x-dev].
- drupal/commerce 2.x-dev requires drupal/core ~8.4 -> satisfiable by drupal/core[8.4.0, 8.4.0-alpha1, 8.4.0-beta1, 8.4.0-rc1, 8.4.0-rc2, 8.4.x-dev, 8.5.x-dev].
- drupal/commerce 2.x-dev requires drupal/core ~8.4 -> satisfiable by drupal/core[8.4.0, 8.4.0-alpha1, 8.4.0-beta1, 8.4.0-rc1, 8.4.0-rc2, 8.4.x-dev, 8.5.x-dev].
- Conclusion: don't install drupal/core 8.4.0-alpha1
- Installation request for drupal/commerce 2.x-dev -> satisfiable by drupal/commerce[2.x-dev].
www.EXEMPLE.com@vps000000:~/public_html$ nano composer.json
{
"name": "drupal-composer/drupal-project",
"description": "Project template for Drupal 8 projects with composer",
"type": "project",
"license": "GPL-2.0+",
"authors": [
{
"name": "",
"role": ""
}
],
"repositories": [
{
"type": "composer",
"url": "https://packages.drupal.org/8"
}
],
"require": {
"composer/installers": "^1.2",
"cweagans/composer-patches": "^1.6",
"drupal-composer/drupal-scaffold": "^2.2",
"drupal/admin_toolbar": "^1.19",
"drupal/autologout": "1.x-dev",
"drupal/back_to_top": "^1.0@beta",
"drupal/bootstrap": "^3.3",
"drupal/bootstrap_layouts": "5.x-dev",
"drupal/captcha": "^1.0@beta",
"drupal/colorbox": "^1.4",
"drupal/commerce": "2.x-dev",
"drupal/commerce_license": "2.x-dev",
"drupal/commerce_paypal": "^1.0@beta",
"drupal/commerce_payplug": "^1.2",
"drupal/commerce_shipping": "^2.0@beta",
"drupal/commerce_stock": "1.x-dev",
"drupal/console": "~1.0",
"drupal/copyright_block": "1.x-dev",
"drupal/core": "~8.0",
"drupal/diff": "^1.0@RC",
"drupal/ds": "^3.0",
"drupal/eu_cookie_compliance": "1.x-dev",
"drupal/eva": "^1.2",
"drupal/field_timer": "^1.0",
"drupal/field_validation": "^1.0@alpha",
"drupal/fivestar": "1.x-dev",
"drupal/flag": "4.x-dev",
"drupal/geocoder": "2.x-dev",
"drupal/geofield": "1.x-dev",
"drupal/geofield_map": "^1.4",
"drupal/group": "1.x-dev",
"drupal/honeypot": "^1.24",
"drupal/invite": "1.x-dev",
"drupal/leaflet": "1.x-dev",
"drupal/leaflet_markercluster": "1.x-dev",
"drupal/leaflet_more_maps": "^1.0@alpha",
"drupal/masquerade": "^2.0@beta",
"drupal/message": "1.x-dev",
"drupal/message_digest": "^1.0@alpha",
"drupal/message_private": "1.x-dev",
"drupal/message_subscribe": "^1.0@beta",
"drupal/message_thread": "^1.0@alpha",
"drupal/metatag": "1.x-dev",
"drupal/module_filter": "^3.0",
"drupal/office_hours": "1.x-dev",
"drupal/paragraphs": "1.x-dev",
"drupal/pathauto": "^1.0",
"drupal/piwik": "^1.1",
"drupal/poll": "1.x-dev",
"drupal/redirect": "^1.0@beta",
"drupal/rules": "3.x-dev",
"drupal/schema_metatag": "^1.0@RC",
"drupal/search404": "^1.0@beta",
"drupal/search_api": "1.x-dev",
"drupal/simple_sitemap": "2.x-dev",
"drupal/super_login": "1.x-dev",
"drupal/swiftmailer": "^1.0@beta",
"drupal/token": "1.x-dev",
"drupal/typed_data": "1.x-dev",
"drupal/views_bootstrap": "3.x-dev",
"drupal/views_send": "^1.0",
"drupal/yoast_seo": "2.x-dev",
"drush/drush": "^8.1",
"webflo/drupal-finder": "^0.3.0",
"webmozart/path-util": "^2.3"
},
"require-dev": {
"behat/mink": "~1.7",
"behat/mink-goutte-driver": "~1.2",
"jcalderonzumba/gastonjs": "~1.0.2",
"jcalderonzumba/mink-phantomjs-driver": "~0.3.1",
"mikey179/vfsstream": "~1.2",
"phpunit/phpunit": ">=4.8.28 <5",
"symfony/css-selector": "~2.8"
},
"conflict": {
"drupal/drupal": "*"
},
"minimum-stability": "dev",
"prefer-stable": true,
"config": {
"sort-packages": true
},
"autoload": {
"classmap": [
"scripts/composer/ScriptHandler.php"
]
},
"scripts": {
"drupal-scaffold": "DrupalComposer\\DrupalScaffold\\Plugin::scaffold",
"pre-install-cmd": [
"DrupalProject\\composer\\ScriptHandler::checkComposerVersion"
],
"pre-update-cmd": [
"DrupalProject\\composer\\ScriptHandler::checkComposerVersion"
],
"post-install-cmd": [
"DrupalProject\\composer\\ScriptHandler::createRequiredFiles"
],
"post-update-cmd": [
"DrupalProject\\composer\\ScriptHandler::createRequiredFiles"
]
},
"extra": {
"installer-paths": {
"web/core": ["type:drupal-core"],
"web/libraries/{$name}": ["type:drupal-library"],
"web/modules/contrib/{$name}": ["type:drupal-module"],
"web/profiles/contrib/{$name}": ["type:drupal-profile"],
"web/themes/contrib/{$name}": ["type:drupal-theme"],
"drush/contrib/{$name}": ["type:drupal-drush"]
},
"patches": {
"drupal/core": {
"Number widget validation can break AJAX actions": "https://www.drupal.org/files/issues/2614250-40.patch",
"Fetch User ID from route context views contextual filter for any entity": "https://www.drupal.org/files/issues/fetch_user_id_from_route_for_all-2904908-2.patch",
"If no body field [node summary] [node body] etc tokens are not replaced": "https://www.drupal.org/files/issues/drupal-tokens_are_not_replaced-1671420-12-D8.patch"
},
"drupal/commerce": {
"Add store name to shopping cart when multiple stores enabled": "https://www.drupal.org/files/issues/add-store-name-when-multiple-stores-2870053-6.patch",
"Views refuse to display the product type label": "https://www.drupal.org/files/issues/allow_product_type_labels_in_views-2900472-4.patch",
"With a view catalog only the first product variations works": "https://www.drupal.org/files/issues/2897698-24.patch"
},
"drupal/rules": {
"PHP Fatal error when adding an action and address is installed": "https://www.drupal.org/files/issues/2694685-52.rules-fix_type_definition_error.patch"
},
"drupal/flag": {
"Add relationship to flagged entities when Flagging is base table": "https://www.drupal.org/files/issues/2723703_31.patch",
"Unflag not allowed text does not work": "https://www.drupal.org/files/issues/2886308-Unflag-not-allowed-text-20.patch",
"Views link field doesn't use flag.html.twig": "https://www.drupal.org/files/issues/2888268-8-views-link-doesnt-use-twig.patch"
},
"drupal/leaflet": {
"LeafletMarker could not recognize geofield": "https://www.drupal.org/files/issues/leaflet-recognize_geofield-2839538.patch",
"Leaflet not always working with AJAX": "https://www.drupal.org/files/issues/leaflet-2858091-3-alternative.patch",
"Fix config schema": "https://www.drupal.org/files/issues/leaflet-config_schema-2883700-3.patch",
"Error in leaflet_process_geofield() when twig debug is active": "https://www.drupal.org/files/issues/leaflet-error-when-debug-active-2783843-5.patch",
"Rendered entity tooltip only works for nodes": "https://www.drupal.org/files/issues/rendered_entity_tooltip-2890641-2.patch"
},
"drupal/geofield": {
"Re-implement the Views proximity filter/field for Drupal 8": "https://www.drupal.org/files/issues/geofield_views_proximity_filter-2654360-63.patch"
},
"drupal/geocoder": {
"Incorrect config schema for geocoder.settings": "https://www.drupal.org/files/issues/2824802-geocoder-schema-fix-2.patch",
"Don't add third party settings when geocoder method is none": "https://www.drupal.org/files/issues/geocoder-omit_third_party_settings-2884928-2-D8.patch",
"Convert module to use short array syntax (new coding standard)": "https://www.drupal.org/files/issues/short_array_syntax-2881694-2.patch",
"Remove admin variables when uninstall": "https://www.drupal.org/files/issues/remove_admin_variables-2833058-2.patch"
},
"drupal/views_bootstrap": {
"Missing responsive utilities for grid with horizontal alignment": "https://www.drupal.org/files/issues/6e5acf0.patch",
"Regression Raw field value displayed in accordion panel title": "https://www.drupal.org/files/issues/raw_field_value-2870642-2.patch"
},
"drupal/search404": {
"Custom search to custom url": "https://www.drupal.org/files/issues/2844729-custom-search-to-custom-url_0.patch",
"Allow spaces as seperators for custom search path": "https://www.drupal.org/files/issues/2896547-allow-spaces-as-separator-2.patch"
}
}
}
}
Comment | File | Size | Author |
---|---|---|---|
#9 | Capture du 2017-10-05 20-08-10.png | 104.06 KB | zenimagine |
Comments
Comment #2
cilefen CreditAttribution: cilefen at Institute for Advanced Study commentedComment #3
TynanFox CreditAttribution: TynanFox as a volunteer commentedI think I found the culprit. Please excuse me if this answer isn't as technical as it could be - I'm not a developer and only have a loose understanding of how it is working. Someone more knowledgeable may be able to tell us "why"?
In the DOCROOT composer.json file, I see the following lines:
This directs the DOCROOT composer.json file to refer to the
`core/composer.json`
file and also require those dependencies. The problem is that it is looking at the dependencies from your *currently installed version* of Drupal, whereas the upgraded version has new dependencies. This creates the conflict and error message we're seeing.Here is the solution I found which works - there are probably others and better ones.
1)Download a copy of the
`core/composer.json`
file from *the tarball of the version of Drupal you are upgrading to*.2)In your current installation, *replace* the
`core/composer.json`
file with the new version you just downloaded.3)Update your DOCROOT composer.json file with
"drupal/core:~8.x.x"
(whatever you're upgrading to).4)Run
`composer update drupal/core --with-dependencies`
as usual. This time, the update should proceed. Then apply database/entity updates, rebuild the cache, etc. etc.If any experts out there have a better or proper solution, by all means please post! This took me FOREVER to figure out and there's no documentation anywhere regarding this!
Comment #4
pcambraI had similar problems, the solution for me was doing this https://github.com/drupal-composer/drupal-project/issues/305 plus deleting the vendor folder and composer.lock file.
Comment #5
leymannxConfirming #4
---
Edit: Yes, I deleted /vendor and composer.lock in advance.
Comment #6
zenimagine CreditAttribution: zenimagine commented@leymannx thank you, have you deleted the folder "vendor" and the file "composer.lock" ?
Comment #7
fdverwoerd CreditAttribution: fdverwoerd at Dutch Open Projects commentedOriginal message deleted, read on! :P
Comment #9
zenimagine CreditAttribution: zenimagine commentedDELETE
Comment #10
dajjenIn my case it worked with above solution #4 but I also needed to change version on drupal console to
"drupal/console": "^1"
in composer.jsonComment #11
zenimagine CreditAttribution: zenimagine commenteddo you have the same problem as me to update the database?
Comment #13
itsekhmistro CreditAttribution: itsekhmistro at Adyax commentedHi,
Changing composer.json to (updated version of following 3 packages):
...
"drupal/core": "8.4.0",
"drush/drush": "~9.0"
"drupal/console": "^1",
...
and then running $composer update drupal/core drush/drush drupal/console --with-dependencies
Did work for me.
So for me working solution is:
1) update versions (of drupal/core drush/drush drupal/console) in composer.json
2) execute: $composer update drupal/core drush/drush drupal/console --with-dependencies
Only 2 steps.
All 3 packages have a dependency on symfony components and there is switch to Symfony 3.2 in Drupal 8.4.0.
And it is confusing for composer to resolve it with installed dependencies for the drupal/core, drush and drupal/console without updating all 3 packages.
PS.
>have you deleted the folder "vendor" and the file "composer.lock" ?
No, it's not required. And in this case you will lost exact versions of installed packages.
Also avoid executing:
>$composer update --with-dependencies
without specifying which package to update. Otherwise all packages will be updated.
Comment #15
alexpottIf you want to ensure your composer based build uses exactly the same versions of packages as core there is https://github.com/webflo/drupal-core-strict to do this.
Comment #16
websiteworkspace CreditAttribution: websiteworkspace commentedThis update to 8.4.0 DID NOT go smoothly at all.
Even (especially) using the composer utility, it is an ugly process to say the least.
Thank goodness for test installation sites.
I don't dare run this new version on anything but a test site for a while before updating anything critical.
Comment #17
NiklanAgreed, this update is a bit off. I see the problem in messed dependencies. The core requires new Symfony, but we have installed the old one 2.7 for 8.3 and this, as I think, cause the issue.
I didn't have drush and drupal console as required package for project and this problem is also presented, so this is only core dependency problem. Also it presented with drush 8.1.12.
I have fixed it for myself by changing composer.json package version for core to "~8.4", and removed vendor folder, which allowed to download new Symfony components for 8.4 core, which will not install if old Symfony components presented in vendor folder. And after that, core was updated successful.
1. Change
drupal/core
package in composer.json to "~8.4" manually.2. Remove vendor folder.
rm -rf vendor/
(be careful with that)3. Update with composer
composer update --with-dependencies
4. Update database if it not doing by composer hooks
drush updb
Comment #18
JvE CreditAttribution: JvE at iO commentedA lot of our build, deploy and test scripts use a site-local drush.
Drupal 8.4 won't install with drush < 9 (the mention of >= 8.1.12 is misleading, it does not apply to composer based installs)
In drush 9 almost all the commands and parameters have changed, breaking our scripts.
So no Drupal 8.4 for us :(
I also opened a ticket for Drush at https://github.com/drush-ops/drush/issues/3023
Comment #19
Sebastian HagensAfter changing the drupal/core version to ~8.4 in my composer.json, running
composer update drupal/core --with-dependencies
was not as easy as it should be. Have been struggling a lot, also because the command was stuck at the messageResolving dependencies through SAT
.So I deleted the /core directory and composer.lock file and also changed the version values in my composer.json of these requirements (based on the info in the comments in this thread):
1.
composer install
and this succeeded (tip: add the argument -vvv to your command to see the verbose of the script).2.
composer update
to update all modules and libraries.3. Use drush to clear cache
drush cr
and update your databasedrush updatedb --entity-updates
4. It is working again on 8.4.0 now =)
Comment #20
kala4ekCan recommend step 3.1 for #19 comment:
After updating, you also need to run
drush entity-updates
or it can be combined withdrush updatedb
in the follwoing way:drush updatedb --entity-updates
Comment #21
Sebastian Hagens@kala4ek thanks for that additional note (which is indeed necessary), I've edited my post
Comment #22
zenimagine CreditAttribution: zenimagine commentedWhat is the equivalent of the command :
drush updatedb --entity-updates
With "Console"?
Since drupal there is 17 update of the database to do, but that bug.
Comment #23
k.sandeep CreditAttribution: k.sandeep commentedas a temporary solution you could require "symfony/console": "3.2.8" (as opposed to the newly released 3.3.0) in your composer.lock file.
Update/add your "require" section under composer.lock with "symfony/console": "3.2.8".
Run :
composer update
Note: Composer uses the exact versions listed in composer.lock (composer.lock file created when composer install first time) to ensure that the package versions are consistent for everyone working on your project.
Comment #24
JacobSanfordI understand scrambles happen around these times, however as a tempering voice might I suggest that upgrading to Drush9 should not happen without a moment of consideration. Some Drush 7/8 commands have changed or been deprecated in 9, particularly around configuration import and export.
Additionally, although the changes in 9 are really exciting, make note it is a package in current Beta.
If you have a deployment local development or maintenance system that relies on Drush commands, there be dragons in Drush 9.
Comment #25
websiteworkspace CreditAttribution: websiteworkspace commented@JacobSanford
This does not seem like very good release coordination between the core people, and other tools like drush, and numerous others.
Comment #26
JonMcL CreditAttribution: JonMcL commentedI believe someone will need to update drupal-composer/drupal-project since it currently does not allow for an update of drupal/core to 8.4. It took me a while to find this issue thread and solve the problem. composer output seems useless for tracking down this particular issue.
Is there a drupal.org project page for durpal-composer/drupal-project?
Comment #27
zenimagine CreditAttribution: zenimagine commentedI do not understand, drush appears in my composer.json file
But when I :
the following message appears :
Comment #28
cilefen CreditAttribution: cilefen as a volunteer commentedComment #30
cilefen CreditAttribution: cilefen as a volunteer commentedOpen another issue in the Entity system.
Comment #31
alexpott@zenimagine it looks like you are using the experimental content_moderation module. There are breaking changes in between 8.3.x and 8.4.x for that module. See the release notes for 8.4.0 - https://www.drupal.org/project/drupal/releases/8.4.0 - there is a section on this module which helpfully points to #2896630: Unofficial content_moderation 8.3.7 to 8.4.0 upgrade path that will help you.
Comment #32
Ectopod CreditAttribution: Ectopod commentedI was having this issue and the solution in comment #4 worked for me.
I think @Niklan is correct about the core of the problem. Whenever I ran why-not on Drupal core, it said it couldn't upgrade because Symfony was the wrong version. Except I couldn't upgrade Symfony either, and why-not said this was because Drupal core 8.3 required the version of Symfony that was currently installed. It was this annoying vicious cycle. Sometimes Composer is . . . a little frustrating to work with.
Comment #33
zenimagine CreditAttribution: zenimagine commentedThis update is a horror.
Impossibl for me to update drupal.
When I do "drush updatedb"
The following error is displayed on the set of my site :
"The website encountered an unexpected error. Please try again later."
Comment #34
zenimagine CreditAttribution: zenimagine commentedOn a site in production, should it wait for version 8.4.1 to carry out the update ?
Comment #35
cilefen CreditAttribution: cilefen as a volunteer commentedzenimagine: what is the logged error?
edited "logger/logged"
Comment #36
xjm@zenimagine, waiting for 8.4.1 will not help because we need clear bugs in order to fix them. In #33 and #34, we need the actual PHP error messages from your server logs in order to determine whether there's a bug to be fixed.
@alexpott gave you information about updating Content Moderation (an experimental module which does not have an official upgrade path from 8.3.x). Did you follow his recommendation?
From the release notes:
So, you could try the patch in #2896630: Unofficial content_moderation 8.3.7 to 8.4.0 upgrade path for that, or uninstall Content Moderation.
Also, what version of Drush are you using? As mentioned in the release notes, Drush 8.1.11 and earlier is incompatible with Drupal 8.4.0.
Hope this helps; sorry that you are running into errors with the update. Please provide detailed reports of what modules are installed, what steps you take, and what messages are in your error logs, because otherwise we can't help troubleshoot.
For composer users (crossposting from https://github.com/drush-ops/drush/issues/3023), I'm planning to update the release notes with the following:
Comment #37
dnebrich CreditAttribution: dnebrich commentedI'm also seeing this issue. I've always used option A from Using Composer to manage Drupal site dependencies. Option A uses drupal-composer/drupal-project which adds the drush dependency mentioned in comment #36.
Comment #36 says that having the drush dependency is less common. However, option A on the above link comes across as being preferred as the page states option B "is the simplest solution but lacks additional configuration that can be helpful." Is it true that most sites set up with composer are using something other than the drupal-composer/drupal-project template?
If I setup a new clean site using option A, it pulls 8.3.7, while option B does use 8.4.0. I'll try switching to option B using global drush/drupal.
Comment #38
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedReferring #5, following worked for me:
1. Changing composer.json to:
"drupal/core": "~8.4"
2. Delete vendor and composer.lock
3.
composer update --with-dependencies
4.
drush updatedb --entity-updates
Comment #39
gnuschichten CreditAttribution: gnuschichten at ETECTURE GmbH commentedI check out the composer warnings in order & added the dependencies to the composer command.
There is no need for me to delete the vendor folder or to refactor the composer.json.
composer update drupal/core drush/drush drupal/console drupal/console-en webflo/drupal-finder drupal/console-core symfony/class-loader symfony/console symfony/dependency-injection symfony/event-dispatcher symfony/http-foundation symfony/http-kernel symfony/process symfony/routing symfony/serializer symfony/translation symfony/validator symfony/yaml drupal/console-extend-plugin symfony/event-dispatcher drupal/drupal-extension drupal/drupal-driver behat/behat --with-dependencies
We use drupal-composer/drupal-project.
I also work on another website. I can't update the site with composer update drupal/core --with-dependencies - but my colleague can update the site with this command. We both using ubuntu, but his enviroment uses PHP 7.1, mine runs with 7.0.22.
Comment #40
cilefen CreditAttribution: cilefen as a volunteer commentedComment #42
Lukas von BlarerI keep getting this error when running database updates:
TypeError: Return value of Doctrine\Common\Annotations\AnnotationRegistry::reset() must be an instance of Doctrine\Common\Annotations\void, none returned in /var/www/drupal/public_html/vendor/doctrine/annotations/lib/Doctrine/Common/Annotations/AnnotationRegistry.php on line 55
Any ideas?
Comment #43
Lukas von BlarerSwitching from 7.0 to 7.1 did the trick…
Comment #44
zenimagine CreditAttribution: zenimagine commented@Lukas von Blarer
How did you do ?
Comment #46
agoradesign CreditAttribution: agoradesign commentedIt can cause problems, when you have different PHP versions on dev and production (or in different dev environments). Some Symfony dependencies that are loaded in PHP 7.1 environments are not compatible with the ones that would have been loaded in a 5.6 for example.
You can however trick and force Composer to load the dependencies for a specific PHP version, no matter which one you're currently running: https://getcomposer.org/doc/06-config.md#platform
Comment #47
VVS CreditAttribution: VVS commentedAdding to composer.json:
fix the problem with php 7.1 and doctrine 2.8 (http://www.doctrine-project.org/2017/07/25/php-7.1-requirement-and-compo...).
All working again.
Comment #48
ksavoie CreditAttribution: ksavoie commentedRunning into the same errors. Current suggestions have not gotten me any success. : (
Comment #49
websiteworkspace CreditAttribution: websiteworkspace commentedupdate steps - update to drupal 8.4.0 update with composer
1.
edit composer.json
- change drupal version to ^8.4
- if using drush change drush version ~9.0
2.
rename /vendor to /_vendor
rename /core to /_core
rename composer.lock to _composer.lock
- - available for easy rollback if problems occur
3.
run - composer update drupal/core
- (don't worry about extra arguments)
4.
from the browser run {site}/update.php
5.
clear the cache from either admin GUI or using drush
6.
check basics from admin GUI, such as status report, dblog, etc.
7.
if all goes well:
delete /_vendor
delete /_core
delete _composer.lock
8. proceed to Drupal 8.4.0 - test carefully
- the 8.4.0 update causes various known problems, such as breaking ui features on existing sites that use jquery
Comment #50
gaele CreditAttribution: gaele commenteddrush 8.1.15 is released, which will do instead of drush 9.
Comment #51
kreatIL CreditAttribution: kreatIL as a volunteer commented@DrupalSiteBuilder: Thank you for the clear resume in #49.
I exactly followed the first three steps of #49. I got the following error messages:
I don't know: Is this the same problem or is it another issue? I'm running drupal 8.3.7 on a local Apache Webserver (PHP 5.6.30).
Comment #52
kreatIL CreditAttribution: kreatIL as a volunteer commentedI next followed the error messages from top to bottom.
The line
drupal/console-core 1.0.2 requires webflo/drupal-finder ^1.0 -> satisfiable by webflo/drupal-finder[1.0.0] but these conflict with your requirements or minimum-stability.
contained the hint to adjust the right version of webflo/drupal-finderAfter I had corrected that in the composer.json, the composer update ran successfully for me.
Comment #53
gnuschichten CreditAttribution: gnuschichten at ETECTURE GmbH commentedWon't work - when I adjust the composer.json the next missing dependencies occurs. The only possiblitity for me to get a update, is the composer command that I mentioned in #39.
Comment #54
benjifisherI succeeded in upgrading to Drupal 8.4.0 and Drush 9. A few days later, Drush 8.1.15 was released, and I could have used that. See my blog post for the gory details. (There are already too many screen dumps on this issue.)
Comment #55
xjmFor anyone who has encountered issues updating a site that has Drush as a composer dependency to Drupal 8.4, try changing the Drush requirement to 8.1.15. This (just released in the past few days) should resolve many issues with Drush and local/composer-based installations.
Comment #56
xjmThanks @DrupalSiteBuilder for writing such clear steps!
Thanks @kreatIL also for the debug output. The relevant bit is this:
- drupal/console-core 1.0.0-rc11 requires symfony/event-dispatcher >=2.7 <3.2 -> satisfiable by symfony/event-dispatcher[
So we need to update
drupal-console
to allow Symfony 3.2.Comment #57
websiteworkspace CreditAttribution: websiteworkspace commented@kreatIL
You have an additional dependency, which is drupal console.
You might try temporarily removing drupal console, and then reinstall drupal console after the core update.
To do taht, add the following steps by my list of steps above at #49:
0.
composer.phar remove drupal/console
6.1
composer.phar require drupal/console
Comment #58
xjmThe current release of Drupal Console 1.0.2 has the compatibility set to
~3.0
for Symfony components; see here: https://github.com/hechoendrupal/drupal-console/blob/master/composer.jso...https://github.com/hechoendrupal/drupal-console/issues/2987#issuecomment... suggests issues with Symfony 3.2 and composer, but I wasn't able to find an open issue for what exactly doesn't work. So those encountering issues with Drupal Console should probably remove
composerConsole as described in #57 and open an issue or PR against Drupal Console to make it compatible with Symfony 3.2: https://github.com/hechoendrupal/drupal-console/issues/newSome other commenters on this issue appear to have different issues. If you are not getting the exact error in the summary, you should probably file a separate issue, or look to see if your specific issue has already been reported elsewhere: https://www.drupal.org/project/issues/search?issue_tags=8.4.0%20update
Edit: Be sure to make note "Drupal Console" vs. "Symfony Console".
Hope this helps!
Edit: Corrections.
Comment #59
xjmFor Doctrine compatibility issues, also see: #2898119: Doctrine/Common 2.8 requires PHP ~7.1
Comment #60
tormi@xjm, I'm sure you meant "should probably remove console as described in #57.. " ;)
Comment #61
xjmlol, Freudian slip? Fixed.
Comment #62
cllamas CreditAttribution: cllamas as a volunteer commentedupdating to Drupal 8.4.0 has broken my site. I don't know what to do to recover it, I've tried all the previous answers.
my error log is
PHP Parse error: parse error, expecting `';'' or `'{'' in mysite/vendor/doctrine/annotations/lib/Doctrine/Common/Annotations/AnnotationRegistry.php on line 50
Drush Version : 8.1.15
PHP 7.1.3
Comment #63
benjifisher@cllamas: I think the first thing to try is deleting the
vendor/
directory and thencomposer install
. While you are at it, note what version of doctrine/annotations is being installed. If you still get the same error message, then have a look at line 50 (and a few lines of context) ofmysite/vendor/doctrine/annotations/lib/Doctrine/Common/Annotations/AnnotationRegistry.php
.Comment #64
cllamas CreditAttribution: cllamas as a volunteer commentedHi, benjifisher, first of all, thanks for such fast reply.
I've tried removing vendor folder, and composer.lock. running composer install, this is the version that downloads.
- Installing doctrine/annotations (v1.5.0)
Loading from cache
in that line of the file I can find this, first line being line 50
but I'm not sure what the problem might be. I don't understand what's wrong...
Comment #65
benjifisher@cllamas: I do not see it now, on this issue nor on the related #2898119: Doctrine/Common 2.8 requires PHP ~7.1, but I read a day or two ago that PHP 7.1 introduced the void return type, and some Doctrine components already use it, and this is one reason people are having trouble when upgrading Drupal.
Certainly the line you quote uses the new
void
return type.I would expect PHP 5 to give a parse error like that: when it sees the ":", it is expecting either a ";" (abstract function) or a "{" (start of function body). The weird thing is that you say you are using PHP 7.1, which should have no problem with that line.
Next steps:
composer
anddrush
will use the CLI version, which may not be the same PHP that your web server is using.Also, look at context a few lines above Line 50 as well as a few lines below. Just in case.
Comment #66
cllamas CreditAttribution: cllamas as a volunteer commentedyep, cli was showing 7.1 but php_info showed that it was actually 5.6... damn! THANK YOU SO MUCH!
Comment #67
mariusdiacu CreditAttribution: mariusdiacu commentedUsing PHP 7.1.7 it works, but I get the annotations error on PHP 7.1.10 and 7.1.11. Tried all the above tricks, none worked. I simply downgraded doctrine/annotations from 1.5.0 to 1.4.0 in composer.lock and it works now.
Comment #68
badrange CreditAttribution: badrange at Digia commentedcomposer require drupal/core:^8.4.0 drush/drush:^8.1.15 phpunit/phpunit:^4.8 drupal/console:^1.0 --update-with-dependencies
worked nicely for me. The phpunit was needed because this project was based on drupal-composer.Editing composer.json by hand does feel like a wrong solution.
Comment #69
fooway CreditAttribution: fooway commentedI upgrade to Drupal 8.4.2 + PHP 7.1.11+ MySQL 5.7 now and find that the improper permissions of directories/files might lead to the broken website.
Comment #70
karolus CreditAttribution: karolus as a volunteer commentedI'm having issues upgrading from 8.3.7 to 8.4.2. Based on the comments here, does it only work with PHP 7.1+? If so, I guess I won't be able to update, being that my web hosts won't be doing so soon. I have Drush running at 8.1.15, but still getting a broken site. This is the error I see:
Are there any workarounds, in the meantime?
Comment #71
benjifisher@karolus:
That does not look like a complete error message.
What is your local environment? (If, for example, you are using Vagrant on macOS High Sierra, then try searching for those terms.)
If you are getting composer to install a consistent set of packages, but then you get errors when starting the site, then I do not think that you are seeing the problems described in this issue.
Comment #72
karolus CreditAttribution: karolus as a volunteer commented@benjifisher If I'm not mistaken, part of my issue is due to the fact that Drupal 8.4.x and it's dependencies require PHP 7.1.x, minimum. Based on this thread, Doctrine requires it. I attempted to use a lower version of Doctrine (1.4), but it didn't resolve the issue.
As soon as I roll back to 8.3.7, and do
composer install
, things are running.As an aside--I see a lot of recommendations to use Drush 9.x, but that isn't even stable at this point. Is that good?
Comment #73
benjifisher@karolus:
You may be right, but the related issue #2898119: Doctrine/Common 2.8 requires PHP ~7.1 may be a better fit.
In my experience, Drush 9 mostly works, but contrib modules that supply additional drush commands mostly do not support it. For about a week after Drupal 8.4.0 was released, Drush 8.x could not be installed "locally" (using composer, inside the vendor directory) but then Drush 8.15 came out.
My drush advice is to start experimenting with 9.x, but plan on using 8.15 (or newer) for most purposes.
Comment #74
alexpott@karolus Drupal 8.4 does not require PHP 7.1.x. Are the environments where you are running composer install and serving the website the same. If you have mistmatching PHP versions you can have the sorts of problems you are having. At a guess you are using the drupal composer project. If you do this, using https://github.com/webflo/drupal-core-strict can help you use exactly the same versions of dependencies as Drupal core uses for testing and therefore you know that it works on PHP5.5 through to PHP7.1 - see https://www.drupal.org/node/3060/qa
Comment #75
greg.harvey+1, I just proved this to myself. Having build issues on a brand new server running PHP 7.0 and a new customer's website, so just to check it's not core I did a simple
drush dl drupal
followed bycomposer install
in the newly downloaded Drupal directory, and there's no issue.So it must be a dependency brought in by some contrib, in my case, but it definitely isn't core.Edit: So this is awkward, seems *my* problem is because the customer committed a
composer.lock
file, like you're supposed to, but having built on a machine with PHP 7.1 installed, and that breaks things for the server, which has PHP 7.0 on it.Comment #76
alexpottCustomising the root composer.json can also help iron out prod and dev differences - you can add platform config to tell composer to pretend it is running on a particular version - see https://getcomposer.org/doc/06-config.md#platform
Comment #77
karolus CreditAttribution: karolus as a volunteer commented@alexpott Thanks for the response. I just checked, and this is happening locally for me, where I have PHP 7.0.14 running for local dev, but PHP 7.1.7 running on the system.
As you had pointed out, I am using the Drupal Composer project. What I did was add this to my composer.json file in the require section:
After this, I ran
composer install
, then update.php, and the site is fine.As an aside--should this be added to the documentation for 8.4? I already pinged Webchick and Gabor about this.
Comment #78
ksavoie CreditAttribution: ksavoie commentedWas running into the same dependency conflicts.
With PHP 5.6, I was able to get a successful update from D8.3.7->8.4.4 by first manually updating 'local' Drush to 8.1.15.
Then deleting the 'vendor' directory and ONLY updating to D8.4.4 with DB updates via local Drush. This re-downloads all vendor dependencies. I think some installs may have a dependency config/corruption? that the normal update can't quite work with correctly.
I believe people that find success by updating to PHP 7.x is because removal of PHP 5.x deletes associated symphony files, then when you upgrade Drupal it re-downloads the new ones. The update is successful not because they are PHP 7.x versions, just that the old ones (with whatever was going on with them to not work) have been replaced. (just my theory) : )
Then after that, update any remaining modules.
Good luck.
Comment #79
dudde CreditAttribution: dudde commentedI was simply trying to run a composer update which broke my site "The website encountered and unexpected error"
Having a look at watchdog I saw this error message:
Return value of Doctrine\Common\Annotations\AnnotationRegistry::reset() must be an instance of Doctrine\Common\Annotations\void, none returned
#67 helped me and I added the below line to my composer.json and fixed the site(I tried using php 7.1.12 but it didn't help):
"doctrine/annotations": "1.4",
Comment #80
bleeuwen CreditAttribution: bleeuwen commented#5 did the trick for me!! Thanks
Comment #81
AnybodyWell for me the only really good solution was to delete the composer.json FROM THE /core directory (/core/composer.json) and then composer update --with-dependencies.
After that the core is re-added in the new version with its composer file. So that's not dangerous at all from my point of view.
#5 was already the case before for me.
I think this may help many people even when upgrading to 8.5.x
Comment #82
missmobtown CreditAttribution: missmobtown as a volunteer commented#17 worked for me -- updating from 8.3.7 to 8.5.
Comment #83
drupalfan2 CreditAttribution: drupalfan2 as a volunteer commentedSame problem updating 8.4.5 to 8.5.0.
I solved it like this:
delete /core, /vendor, composer.lock ... and then
composer.json --> change to "drupal/core": "8.5.0" ... and then
composer update --no-dev --with-dependencies
Comment #84
Mile23Comment #85
DhirendraGrazitti CreditAttribution: DhirendraGrazitti commentedI was updating the drupal 8.39 to drupal 8.5.3.
I have edited "drupal/core": "~8.5", in composer.json file.
Then run command composer update drupal/core then getting below issue.
Problem 1
- Installation request for symfony/console (locked at v2.8.18, required as ~2.8) -> satisfiable by symfony/console[v2.8.18].
- drupal/core 8.5.0 requires symfony/yaml ~3.4.5 -> satisfiable by symfony/yaml[3.4.x-dev].
- drupal/core 8.5.0-alpha1 requires symfony/yaml ~3.4.0 -> satisfiable by symfony/yaml[3.4.x-dev].
- drupal/core 8.5.0-beta1 requires symfony/yaml ~3.4.0 -> satisfiable by symfony/yaml[3.4.x-dev].
- drupal/core 8.5.0-rc1 requires symfony/yaml ~3.4.0 -> satisfiable by symfony/yaml[3.4.x-dev].
- drupal/core 8.5.1 requires symfony/yaml ~3.4.5 -> satisfiable by symfony/yaml[3.4.x-dev].
- drupal/core 8.5.2 requires symfony/yaml ~3.4.5 -> satisfiable by symfony/yaml[3.4.x-dev].
- drupal/core 8.5.3 requires symfony/yaml ~3.4.5 -> satisfiable by symfony/yaml[3.4.x-dev].
- drupal/core 8.5.x-dev requires symfony/yaml ~3.4.5 -> satisfiable by symfony/yaml[3.4.x-dev].
- drupal/core 8.6.x-dev requires symfony/yaml ~3.4.5 -> satisfiable by symfony/yaml[3.4.x-dev].
- Conclusion: don't install symfony/yaml 3.4.x-dev
- Installation request for drupal/core ~8.5 -> satisfiable by drupal/core[8.5.0, 8.5.0-alpha1, 8.5.0-beta1, 8.5.0-rc1, 8.5.1, 8.5.2, 8.5.3, 8.5.x-dev, 8.6.x-dev].
What stpes I should follow to update the core version.
Comment #86
agoradesign CreditAttribution: agoradesign commentedIn almost all use cases of "composer update" you should add the "--with-dependencies" parameter, especially with core updates: composer update drupal/core --with-dependencies
Additonally, as far as I can remember, updating to 8.5 required me also to list the dev dependencies (like PHP Unit) in my composer file to update, in order to avoid a version conflict. but I'm unsure, if this is necessary in your project too --> so that in the end you'd need to run something like: "composer update drupal/core phpunit/phpunit behat/mink [AND SOME OTHER STUFF] --with-dependencies"
Comment #87
jrwest_webguy CreditAttribution: jrwest_webguy commentedAnd here was my process for upgrading 8.4.8 to 8.5.4, on a drupal/drupal project (not a drupal-composer/drupal-project project). EDIT: I have Composer and Drush v8 installed globally.
It added back the core/ folder with v8.5 in it (obviously). The update also restored the Drupal v8.5-required components of symfony and the twig folder (within the vendor/ folder).
Though I was successful, we really shouldn't have to re-invent the wheel to install each major D8 revision, IMHO.
Comment #88
Nitin Shirole CreditAttribution: Nitin Shirole at Trigyn Technologies Ltd commentedReferring #5, following worked for me:
1)Download a copy of the `composer.json` file from DOCROOT of the version of Drupal you are upgrading to*.
2)In your current installation, *replace* the `composer.json` file with the new version you just downloaded.
3)Update your DOCROOT composer.json file with "drupal/core:~8.x.x"(whatever you're upgrading to).
4)Run `composer update drupal/core --with-dependencies` as usual. This time, the update should proceed. Then apply database/entity updates, rebuild the cache, etc. etc.
Thanks TynanFox for saving my time.
Comment #89
zenimagine CreditAttribution: zenimagine commentedComment #94
cilefen CreditAttribution: cilefen as a volunteer commentedI am closing this support request because there have been no recent comments.