Drupal upgrade 8.8.6 to 8.8.8, Usupport schema version [#3152886]

My installation has always been done via WebGUI/command line and composer has never been used on this system. I see now that x-3.0 no longer support tarball installation in favor of composer.

Image Effects 8.x-3.0 was installed via the tarball when I updated to Drupal 8.8.7. When I installed x-3.0 I simple replaced the image_effects (x-1.3) directory with the latest tarball and ran the update, but did not run composer require 'drupal/image_effects:^3.0' prior.

Upgrading Drupal core 8.8.6 to 8.8.8 I am now getting:

Unsupported schema version: Image Effects
The installed version of the Image Effects module is too old to update. Update to an intermediate version first (last removed version: 8203, installed version: 8102).

Should I put the x-1.3 (unsupported) tarball back, upgrade Drupal 8.8.6 to 8.8.8, then setup composer and composer require 'drupal/image_effects:^3.0'. What is the proper course of action to resolve?

Comments

Comment #1

18 June 2020 at 12:40

Rewted created an issue. See original summary.

Comment #2

rewted commented 18 June 2020 at 12:56

Issue summary:

View changes

Comment #3

rewted commented 19 June 2020 at 02:13

I've gone ahead and put x-1.3 tarball back in place then upgraded from Drupal 8.8.6 to 8.8.8 (Security release) successfully.

Moving forward I'm going to setup composer on my system as most modules seem to be heading in this direction for updates. Will I be able to move up from x-1.3 by simply executing composer require 'drupal/image_effects:^3.0'?

Comment #4

mozh92 commented 7 July 2020 at 21:57

I resolved it:
composer require drupal/imagemagick:^2.7 --update-with-dependencies
composer require drupal/image_effects:^2.3 --update-with-dependencies
vendor/drush/drush/drush updb

composer require drupal/image_effects:^3.0 drupal/imagemagick:^3.1 drupal/file_mdm --update-with-dependencies
vendor/drush/drush/drush updb

Comment #5

rewted commented 8 July 2020 at 02:28

I've never used composer before though, so I'll be setting that up on my dev instance. I can run the composer updates independently on dev and not affect prod, correct?

Comment #6

mmjvb commented 8 July 2020 at 06:51

Watch out using Composer on a module that was introduced manually. Make sure the destination is the same, otherwise you get duplicate modules. Suggest to rebuild cache, specially when destination was different. Remove old afterwards.

AFAIK there is no way to see the destination of a module. Obviously, Drupal knows but doesn't expose that information.

Comment #7

rewted commented 9 July 2020 at 00:12

So modules managed with composer may not install into the ../modules dir, if so, how does one check the installation path prior to install?

That's what has got me in this mess, I find a lot of modules no longer support install via tarball and force the use of composer, image-effects being one such module.

I'm going to follow the official Add Composer to an existing site documentation.

Comment #8

mmjvb commented 9 July 2020 at 08:17

For Drupal it doesn't matter where you place the module. It discovers the modules by visiting several folders (called modules) and their sub folders recursively. So, it is your prerogative where to place them and what kind of tree structure you use or not.

Your project composer.json contains the configuration on where to place what. Obviously, applicable to code managed by Composer. How it is configured is completely under your control. Most distributions provide generic configuration based on type of module. For more complex structures you need to provide more configuration to get things where you want.

To check configuration:

docker@cli:/var/www$ composer config extra.installer-paths
{"web\/core":["type:drupal-core"],"web\/libraries\/{$name}":["type:drupal-library","vendor:harvesthq"],"web\/modules\/mmjvb\/{$name}":["type:drupal-module"],"web\/profiles\/contrib\/{$name}":["type:drupal-profile"],"web\/themes\/contrib\/{$name}":["type:drupal-theme"],"drush\/Commands\/{$name}":["type:drupal-drush"]}
docker@cli:/var/www$

Or use a find for the name of the module starting at the root of your project after requiring the module with Composer. A `composer show ` does report where it is placed (path :).

Despite that modules claim they need installation with Composer, most of the time that is not true. For modules with external dependencies you could use Ludwig. As far as Drupal is concerned, it still works the same way it always did. Even automatic updates doesn't support Composer managed modules yet.

Most distributions are ready to be used with Composer. The only one causing problems is drupal/drupal. Easily identified by not having drupal/core as dependency, instead it is merged. Advice against manipulating such an installation into something that sort of works. Recommend migrating the code base into a properly supported Composer distribution as documented.