TL.DR: the standard core upgrade procedure (remove /core and /vendor then deploy updated tarball) breaks sites when composer-installed modules/libs/depencies are installed, as parts reside in /vendor.
(or at least that's how I understood what happened - I'm not a developer and that composer thing is quite arcane so I can be wrong ;-) )
Hi.
I tried to upgrade from 8.1.3 to 8.1.6, first by just copying the files over the old ones (broke the site, restored, restarted) then by following the upgrade procedure and moving /core and /vendor first.
This broke the site again, update.php mentioned an ajax 500 error, then WSOD.
I tried via drush too and got this :
root@www:/home/www.example.com# drush up
PHP Fatal error: Interface 'CommerceGuys\Addressing\Model\AddressFormatInterface' not found in /home/www.example.com/modules/address/src/Entity/AddressFormatInterface.php on line 16
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Interface 'CommerceGuys\Addressing\Model\AddressFormatInterface' not found in /home/www.example.com/modules/address/src/Entity/AddressFormatInterface.php, line 16
Drush was not able to start (bootstrap) Drupal. [error]
Hint: This error can only occur once the database connection has already been successfully initiated, therefore this error generally points to a site configuration issue, and not a
problem connecting to the database.
Drush was attempting to connect to:
Drupal version : 8.1.6
Site URI : http://default
Database driver : mysql
Database hostname : localhost
Database port : 3306
Database username : example
Database name : example_d8
Default theme : zircon
Administration theme : seven
PHP configuration : /etc/php5/cli/php.ini
PHP OS : Linux
Drush script : /usr/bin/drush
Drush version : 8.1.2
Drush temp directory : /tmp
Drush configuration :
Drush alias files :
Install profile : standard
Drupal root : /home/www.example.com
Drupal Settings File : sites/default/settings.php
Site path : sites/default
File directory path : sites/default/files
Temporary file directory path : /tmp
Sync config path : sites/default/files/config_XXXXXXXXXXXXXXXXXXXXXXXXXXXX...
So I investigated the address module a bit closer, and found out that parts of the modules and libs (which must be installed via composer as per the module's instructions) go to /vendor and had not been replaced.
I restored the missing folders from a backup and this failed too.
I tried composer dump-autoload , then composer drupal-update ( as found in https://www.drupal.org/node/2608230 ):
composer dump-autoload
Running composer as root/super user is highly discouraged as packages, plugins and scripts cannot always be trusted
Generating autoload files
> Drupal\Core\Composer\Composer::preAutoloadDump
> Drupal\Core\Composer\Composer::ensureHtaccess
root@www:/home/www.example.com# composer drupal-update
Running composer as root/super user is highly discouraged as packages, plugins and scripts cannot always be trusted
[Symfony\Component\Console\Exception\CommandNotFoundException]
Command "drupal-update" is not defined.
At that point I was still out of luck, so i tried to go trough the whole install for the address module again :
root@www:/home/www.example.com# composer config repositories.drupal composer https://packagist.drupal-composer.org
Running composer as root/super user is highly discouraged as packages, plugins and scripts cannot always be trusted
root@www:/home/www.example.com# composer require "drupal/address ~8.1"
Running composer as root/super user is highly discouraged as packages, plugins and scripts cannot always be trusted
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
- Installing commerceguys/enum (v1.0)
Loading from cache
> Drupal\Core\Composer\Composer::vendorTestCodeCleanup
- Installing commerceguys/addressing (v0.8.2)
Loading from cache
> Drupal\Core\Composer\Composer::vendorTestCodeCleanup
- Installing commerceguys/zone (v0.7.1)
Loading from cache
> Drupal\Core\Composer\Composer::vendorTestCodeCleanup
- Installing commerceguys/intl (v0.7.1)
Loading from cache
> Drupal\Core\Composer\Composer::vendorTestCodeCleanup
- Installing drupal/address (8.1.0-beta3)
Loading from cache
> Drupal\Core\Composer\Composer::vendorTestCodeCleanup
commerceguys/addressing suggests installing symfony/intl (to use it as the source of country data)
commerceguys/addressing suggests installing symfony/form (to generate Symfony address forms)
Writing lock file
Generating autoload files
> Drupal\Core\Composer\Composer::preAutoloadDump
> Drupal\Core\Composer\Composer::ensureHtaccess
and then I eventually updated the module :
root@www:/home/www.example.com# composer update drupal/address --with-dependencies
Running composer as root/super user is highly discouraged as packages, plugins and scripts cannot always be trusted
Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update
Generating autoload files
> Drupal\Core\Composer\Composer::preAutoloadDump
> Drupal\Core\Composer\Composer::ensureHtaccessOnly after this did the upgrade proceed properly :
root@www:/home/www.example.com# drush up
Update information last refreshed: Mon, 18/07/2016 - 11:52
Name Installed Version Proposed version Message
Layout Plugin (layout_plugin) 8.x-1.0-alpha22+6-dev 8.x-1.x-dev Update available
Contact Storage Export (contact_storage_export) 8.x-1.0 8.x-1.4 Update available
Panels (panels) 8.x-3.0-beta4+43-dev 8.x-3.x-dev Update available
Token (token) 8.x-1.0-alpha2+11-dev 8.x-1.x-dev Update available
YAML Form (yamlform) 8.x-1.0-beta6 8.x-1.0-beta8 Update available
Code updates will be made to the following projects: Layout plugin [layout_plugin-8.x-1.x-dev], Contact Storage Export [contact_storage_export-8.x-1.4], Panels [panels-8.x-3.x-dev], Token [token-8.x-1.x-dev], YAML Form [yamlform-8.x-1.0-beta8]
Note: A backup of your project will be stored to backups directory if it is not managed by a supported version control system.
Note: If you have made any modifications to any file that belongs to one of these projects, you will have to migrate those modifications after updating.
Do you really want to continue with the update process? (y/n): y
Project layout_plugin was updated successfully. Installed version is now 8.x-1.x-dev.
Backups were saved into the directory /root/drush-backups/example_d8/20160718095239/modules/layout_plugin. [ok]
Project contact_storage_export was updated successfully. Installed version is now 8.x-1.4.
Backups were saved into the directory /root/drush-backups/example_d8/20160718095239/modules/contact_storage_export. [ok]
Project panels was updated successfully. Installed version is now 8.x-3.x-dev.
Backups were saved into the directory /root/drush-backups/example_d8/20160718095239/modules/panels. [ok]
Project token was updated successfully. Installed version is now 8.x-1.x-dev.
Backups were saved into the directory /root/drush-backups/example_d8/20160718095239/modules/token. [ok]
Project yamlform was updated successfully. Installed version is now 8.x-1.0-beta8.
Backups were saved into the directory /root/drush-backups/example_d8/20160718095239/modules/yamlform. [ok]
The following module is missing from the file system: yamlform_node bootstrap.inc:233 [warning]
The following updates are pending:
yamlform module :
8021 - Issue #2757981: Improve YAML form node integration.
8022 - Issue #2764531: Add ownership to YAML form entity.
8023 - Issue #2765057: Remove default elements.
8024 - Issue #2765831: Improve text field autocompletion support.
8025 - Issue #2766453: Add sticky and notes to submissions.
yamlform_ui module :
8001 - Issue #2759531: Provide 'edit yamlform element custom settings' permission.
responsive_image module :
Make responsive image formatters dependent on responsive image styles.
Do you wish to run all pending updates? (y/n): y
Performing yamlform_update_8021 [ok]
Performing yamlform_update_8022 [ok]
Performing yamlform_update_8023 [ok]
Performing yamlform_update_8024 [ok]
Performing yamlform_ui_update_8001 [ok]
Performing yamlform_update_8025 [ok]
Cache rebuild complete. [ok]
Post updating responsive_image [ok]
Cache rebuild complete. [ok]
Finished performing updates. [ok]
root@www:/home/www.example.com#
Now I expect will be a recurring issue and affect other users, especially when I see this :
https://www.drupal.org/node/2608230#comment-10527890
Looks like you accidentally removed your vendor/ directory (replaced it with the tarball one?) when you did the core update.
You should only replace the core/ module instead.
This is not specific to address, I believe, as other modules use composer in the same way and will present the same issue when upgrading.
Comments
Comment #2
cilefen commentedThis is not the update module.
Comment #3
dawehnerWell, its kinda drush not taking into account composer based installations properly.
Comment #4
ehanuise commented@cilefen, thank you .
@dawehner I turned to drush after the upgrade via the web interface failed, so not sure it's only a drush issue.
Comment #5
ehanuise commented... and I ran in the exact same issues upgrading to 8.1.7 so it looks like this will happen with every future upgrade.
Well, at least it's repeatable ^^
Comment #6
ehanuise commentedComment #7
msypes commentedCongratulations! I just tried upgrading from 8.1.3 to 8.19, and still have this mess.
Comment #8
ehanuise commentedAnd yet again with upgrade to 8.1.0.
Maybe this should be updated to priority:Major as each upgrade to a new release ends up in a WSOD ?
Comment #9
bojanz commented"drush pm-update" is a broken command that will be removed at some point.
The right way to update Drupal core is via Composer, by moving drupal/core from "replace" to "require" in composer.json and running "composer update drupal/core --with-dependencies".
Core needs to tell people not to replace the vendor/ folder if they've ever used Composer.
Short version: Once you start using Composer, you use Composer. That includes core updates.
Comment #10
marqpdx commentedso i am/was in the same situation and i implemented what bojanz suggested, and it worked! that is, this:
that was it. i simply deleted the `replace` section in composer.json in the root directory of my site, and moved the `"drupal/core": "~8.1"` line up to be the last item in the `require` section and ran `composer update drupal/core --with-dependencies` and site is working now.
Comment #11
ehanuise commentedmarqpdx could you paste the actual full command you used ? Thank you :-)
Comment #12
marqpdx commentedhi ehanuise
what i did:
then edit the composer.json there, so that you have this sort of "require" section
[note, you probably won't have the audiolabs line, and might have others instead, but the key is the `"drupal/core": "~8.1"` at the end of that section]
further down in that file was a "replace" section for drupal/core, which i deleted.
then:
and my site was working again.
:-)
m
Comment #13
msypes commentedFollowing marqpdx's advice, I get 'Package "drupal/core" listed for update is not installed. Ignoring.'
I tried a plain vanilla
composer updateand that seems to have gone off without a hitch.(Now if I can only get another install that's messed up corrected, I can try again there.)
Comment #14
RKopacz commentedI'm so over the address module. Every time I try to update a site where it is installed, the site breaks, and it takes me forever to get it going again. It's overkill for my needs. I am switching to an will try to support the simpleaddress module. Better for my purposes.
Comment #15
bojanz commented@RKopacz
Doing things the wrong way will get you the wrong results each time, indeed.
Comment #16
ehanuise commented@bojanz the main issue is to a non developer, this is just hell.
- You install the address module, and it works fine
- later on an update gets published, and you get in trouble
I never used compozer before, and only occured to it because the address upgrade broke my drupal install.
until now, when I needed to update a module, i just used the admin interface in drupal itself et /admin/reports/updates/update, and only had to use command line on the server for Drupal core upgrades.
And I don't want to use compozer for core updates, i'm perfectly happy with unzipping the new file and using /update.php, getting dialogs and feedback, and a nice interface!
If the 'new' way of doing thing means users will all have to go use command line on the server instead of using the drupal upgrade module interface, it may be much better from a developper point of view, it may be technically superior, but to a user it just breaks the site.
I'm not throwing blame or anything, I just try here to advocate the point of view of the end user. RKopacz expressed that feeling in a more blunt way, but if you put yourself in the users' shoes, this resentment is easy to understand.
Comment #17
bojanz commented@ehanuise
Right. My approach (enforcing Composer) is aimed at Drupal users who have always used Drush and Git to manage their sites. I'm a part of Drupal's community which considers updating sites through a UI, on production, while bypassing version control to be an unwise and bad practice that should never be supported. That difference in opinions is not resolvable, and I fully expect people who disagree to use a different Address module or a different eCommerce suite, sacrificing certain contrib features to maintain their old workflow.
Comment #18
ehanuise commented:-) I respect that opinion.
This being said, maybe this is resolvable in the future, by ensuring the UI does handle version control. After all, the UI is just that, an interface, so what's behind it can certainly evolve :)
Comment #19
bojanz commentedSure.
We have started building a Composer UI at https://github.com/borisson/composer-ui.
I expect it to some day look and function like Acquia's Dev Desktop.
The command line might not always be required, but what will always be required is the separation of development into:
1) Building a codebase (Composer)
2) Deploying a codebase
3) Using a codebase
That will always mean additional complexity and no updating inside Drupal on production.
Comment #20
bramvandenbulcke commentedI’m building a really simple website with Drupal 8 and I need addressing functionality, with the Address module as the only option (simpleaddress isn't stable). So far, I’ve bricked two installs on localhost due to Composer. I spent a full day reading and trying to resolve the issue. But the Composer thing is still vague to me.
I have around 15 contrib modules. They all update via Drush or via the admin interface. But one module, Address, needs a different approach! I don’t understand why things have to be this hard. The functionality of the module is great but I fear I will have problems in the future updating on shared hosting.
Should I update with Drush first and afterwards with Composer? Or vice versa? Is there a way to manually update on a shared hosting without Composer support?
I want to refer to a similar situation: when Omega 4 was released Drush was recommended. There was a way installing Omega 4 without Drush. That was much harder but the beginners could at least install the damn thing. I would like to see a similar solution for Address: provide a solution and documentation for people unable/unwilling (unwilling: there could be many reasons) to use Composer.
Comment #21
bojanz commented@bramvandenbulcke
Using Drush for module and core updates is legacy at this point. The Drush maintainers agree.
Simply replace it with Composer and you should be trouble-free.
Here's a recent blog post from mglaman: https://glamanate.com/blog/managing-your-drupal-project-composer
Unfortunately, due to the way PHP autoloading and Composer work, there is no alternative to using Composer if you need an external PHP library. That's how the PHP world works now. If there was an alternative I would have documented it by now.
Comment #22
jnicola commentedDrush up drupal totally blows things away for me as well. Same issue with address.
Composer update updates everything but returns a fatal error regarding address.
composer update drupal/core --with-dependencies returns Package "drupal/core" listed for update is not installed. Ignoring.
Comment #23
nedjoOpened a related issue on core: #2840839: Include selected contrib module dependencies in core, starting with Address.
Comment #24
wturrell commented@bojanz - belatedly re: #9 if you've got a moment…
Can you explain why drupal/core is in replace (not require) in the first place? Is it something to do with Symfony?
(suppose for the sake of argument here I'm doing core development with https://git.drupal.org/project/drupal.git)
And then why would there be a need to move it?
I'm mainly a bit confused why git.drupal.org/project/drupal lists core in replace, but github.com/drupal-composer/drupal-project uses require.
(Thanks!)
Comment #25
cilefen commentedIf you leave drupal/core in "replace", it means in a way that the current composer.json file represents drupal/core. See https://getcomposer.org/doc/04-schema.md#replace
Comment #26
frederico commented@marqpdx - Thank you!!!!!! Your input saved me! I appreciate it very much. I guess I'll need to learn Composer.
Comment #27
RAWDESK commented@bojanz about #9
See https://www.drupal.org/forum/support/upgrading-drupal/2017-10-06/update-...
I followed your advice for this upgrade, but I couldn't manage to get the symfony/class-loader constraint solved.
It looks a lot more cumbersome this major upgrade then a "simple" 8.3.x to 8.3.y...
Thanks upfront for your advice
Comment #28
wavesailor commentedThanks @marqpdx - You help saved my frustration.
Comment #29
cilefen commentedThere are now initiatives trying to make the codebase easier to maintain.