Upgrade to Drutopia version 2

I don't expect Drutopia 1 to run on Drupal 10. Drutopia 2 will run on Drupal 10 though. If you update your existing site, it should continue to work. Updating the config to be up to date with the latest installation config of the various Drutopia modules is a different story.

I have been using https://www.drupal.org/project/config_update → to bring in any optimizations to the Drutopia modules. Frankly, this approach is not particularly friendly, and involves a lot of sorting through which config changes you want to keep or get rid of. It is noteworthy that this step is optional. You can switch to Drutopia 2 without attempting to bring in the config optimizations that come with it.

Our intention will not be to continue this approach moving forward, but rather just to write update hooks whenever there are config changes in any of the modules.

As I said, I usually perform the distro update, using the module in the comment above to bring in optimizations. There are plenty, but some of the ones that are nice are related to the sites handling of images. A fresh installation of Drutopia 2 comes with media entities. It also includes optimizations of the image styles.

After the distro update, I write a custom module for my project that includes a deploy hook that uses the fieldToMediaEntity function provided by https://www.drupal.org/project/migration_helpers → . This just migrates all of the images and/or files to media entities. This method involves a bit of manual work, defining migrations via the parameters of this function call.

Alternatively, you could use https://www.drupal.org/project/image_field_to_media → to create the media fields and to migrate the images to media. When I first started using my approach to this, the image_field_to_media module did not support migrating translated media entities, and I had recently done the work of adding this feature to migration helpers. I have not checked whether this has changed. If your site does not utilize translations, this will not be an issue. You could use this module to transition to using media entities, but of course you would not get any other config optimizations without running the distro update.

I intend to take a look at adding such a deploy hook (that utilizes the migration helpers function) to Drutopia. This, of course, would not migrate images that are attached to nodes of any custom content types (or other entity bundles).

Hello, Thanks for these notes. I was hoping to be able to use AEgir multisite hosting platform to ease the pain of updating from drutopia 1.18 to 2.0.x-dev, by setting up a new 2.0.x-dev platform, cloning a site in the current 1.18 (drutopia which is core 9.5.11) and attempting to migrate the clone - and I think it might work, but for the symfony, etc. dependencies. For example, we have this as an error preventing migration:

Successfully connected to the Drupal database.
-
bootstrap
Drush bootstrap phase : bootstrap_drupal_full()
-
bootstrap
Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: The service "group_permission.calculator" has a dependency on a non-existent service "flexible_permissions.chain_calculator". in /data/disk/o2/static/drutopia2dev/vendor/symfony/dependency-injection/Compiler/CheckExceptionOnInvalidReferenceBehaviorPass.php:86
Stack trace:
#0 /data/disk/o2/static/drutopia2dev/vendor/symfony/dependency-injection/Compiler/AbstractRecursivePass.php(86): Symfony\Component\DependencyInjection\Compiler\CheckExceptionOnInvalidReferenceBehaviorPass->processValue()
#1 /data/disk/o2/static/drutopia2dev/vendor/symfony/dependency-injection/Compiler/CheckExceptionOnInvalidReferenceBehaviorPass.php(49): Symfony\Component\DependencyInjection\Compiler\AbstractRecursivePass->processValue()
#2 /data/disk/o2/static/drutopia2dev/vendor/symfony/dependency-injection/Compiler/AbstractRecursivePass.php(95): Symfony\Component\DependencyInjection\Compiler\CheckExceptionOnInvalidReferenceBehaviorPass->processValue()
#3 /data/disk/o2/static/drutopia2dev/vendor/symfony/dependency-injection/Compiler/CheckExceptionOnInvalidReferenceBehaviorPass.php(49): Symfony\Component\DependencyInjection\Compiler\AbstractRecursivePass->processValue()
#4 /data/disk/o2/static/drutopia2dev/vendor/symfony/dependency-injection/Compiler/AbstractRecursivePass.php(86): Symfony\Component\DependencyInjection\Compiler\CheckExceptionOnInvalidReferenceBehaviorPass->processValue()
#5 /data/disk/o2/static/drutopia2dev/vendor/symfony/dependency-injection/Compiler/CheckExceptionOnInvalidReferenceBehaviorPass.php(49): Symfony\Component\DependencyInjection\Compiler\AbstractRecursivePass->processValue()
#6 /data/disk/o2/static/drutopia2dev/vendor/symfony/dependency-injection/Compiler/AbstractRecursivePass.php(47): Symfony\Component\DependencyInjection\Compiler\CheckExceptionOnInvalidReferenceBehaviorPass->processValue()
#7 /data/disk/o2/static/drutopia2dev/vendor/symfony/dependency-injection/Compiler/CheckExceptionOnInvalidReferenceBehaviorPass.php(40): Symfony\Component\DependencyInjection\Compiler\AbstractRecursivePass->process()
#8 /data/disk/o2/static/drutopia2dev/vendor/symfony/dependency-injection/Compiler/Compiler.php(80): Symfony\Component\DependencyInjection\Compiler\CheckExceptionOnInvalidReferenceBehaviorPass->process()
#9 /data/disk/o2/static/drutopia2dev/vendor/symfony/dependency-injection/ContainerBuilder.php(767): Symfony\Component\DependencyInjection\Compiler\Compiler->compile()
#10 /data/disk/o2/static/drutopia2dev/web/core/lib/Drupal/Core/DrupalKernel.php(1335): Symfony\Component\DependencyInjection\ContainerBuilder->compile()
#11 /data/disk/o2/static/drutopia2dev/web/core/lib/Drupal/Core/DrupalKernel.php(934): Drupal\Core\DrupalKernel->compileContainer()
#12 /data/disk/o2/tools/drush/lib/Drush/Drupal/DrupalKernel.php(61): Drupal\Core\DrupalKernel->initializeContainer()
#13 /data/disk/o2/static/drutopia2dev/web/core/lib/Drupal/Core/DrupalKernel.php(494): Drush\Drupal\DrupalKernel->initializeContainer()
#14 /data/disk/o2/tools/drush/lib/Drush/Boot/DrupalBoot10.php(151): Drupal\Core\DrupalKernel->boot()
#15 /data/disk/o2/tools/drush/includes/bootstrap.inc(354): Drush\Boot\DrupalBoot10->bootstrap_drupal_full()
#16 /data/disk/o2/tools/drush/includes/bootstrap.inc(473): drush_bootstrap()
#17 /data/disk/o2/tools/drush/commands/core/drupal/update_10.inc(137): drush_bootstrap_to_phase()
#18 /data/disk/o2/tools/drush/commands/core/core.drush.inc(466): update_main()
#19 /data/disk/o2/tools/drush/includes/command.inc(422): drush_core_updatedb()
#20 /data/disk/o2/tools/drush/includes/command.inc(231): _drush_invoke_hooks()
#21 /data/disk/o2/tools/drush/includes/command.inc(199): drush_command()
#22 /data/disk/o2/tools/drush/lib/Drush/Boot/BaseBoot.php(67): drush_dispatch()
#23 /data/disk/o2/tools/drush/includes/preflight.inc(67): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#24 /data/disk/o2/tools/drush/drush.php(12): drush_main()
#25 {main}
-
error
Command dispatch complete
-
notice
could not bootstrap drupal after updatedb

Can you imagine a way to bypass this kind of error and allow migration on AEgir ? If so, a drutopia public AEgir instance could be setup just to make migration easier for everyone, and I could help with that.

Best,

Ed

When do you hit this error? It looks like you have the new code deployed. I am not particularly familiar with AEgir, and it is unclear why Drush would be attempting to re-bootstrap the system following database updates. Do you know whether the database updates are finishing?

Here is what I would recommend:

1. Try performing this outside of AEgir, and see whether you are still running into these issues
2. Maybe clearly document which build of Drutopia you are moving from and are going to (I realize it is possible some customization has been done)

Otherwise, per the original post: upgrading to Drutopia 2 should be the same as any other upgrade, with one significant caveat: media migration has to be performed - if you want to move to this (e.g. doing a distro-update). We do not (yet) have in place a good media upgrade process. If you want to skip this, you can upgrade to Drutopia 2 without switching/migrating to media entities, but doing a fresh install does force you into requiring a migration.

Another note—the group_permission.calculator service is provided by the group module. I am not sure what is attempting to utilize this service, but my guess is that the group module is not installed, but something else expects it to be, and I am not sure what that something is. Does your site utilize the group module?

Hello,

I gave up 7 months ago as it seemed too difficult, but now I am starting to migrate the 3 drutopia non-profit sites I host to drutopia 2 and I'd like a few tips or help, if possible:

1) drutopia2 installs with a drupal core version of 10.1.x - once installed do I risk anything upgrading the core-recommended and core-recommended-scaffold to core 10.2.x or 10.3.6, for example? (just by changin the composer.json file and updating via composer)?

2) When drutopia_group is enabled, a problem arises and drush feedback is that updating group is too big a leap from drutopia1 to the version of group installed with drutopia2. Is there a way to go into the drutopia composer.json file and specify a lower version of the drupal group module - just to get database updates to work, and then immediately change the version of group back ... ? Could this approach work ?

Thanks, Ed

Hi, Ed. I apologize that this is so difficult. I have done this upgrade a handful of times, and I know that it is challenging, which is part of the reason we have not been able to streamline it. I've got a deadline approaching next week, but I would be happy to meet with you the week of the 21st. Feel free to message me vi drupal.org or slack to coordinate