Workspace upgrade path

Workspace upgrade path

We've taken some time recently to discuss how we're going to handle the upgrade from the Workspace contrib module to the Workspace core module, once it's released. In our setup we have around 20 sites, each with 4 (or more) environments, all with Workspace installed, syncing content between each environments (and sometimes between each site). Therefore this is a task we are taking very seriously and want to make sure we have a super stable approach which will result in no loss of production content.

The obvious idea is that we provide some kind of update hook that converts all of the workspaces to the new core module, along with all of their content. However, the new Workspace module is quite different in the way that it stores and handled entities, therefore this will be a lot of work. We don't have a lot of time to do a lot of work because we have to port Multiversion and Relaxed modules over to handle all the features that are not going into core. We also have "day job" work to do helping to build and support these 20+ sites.

The idea we are looking to implement is a lot more simple. Uninstall the contrib Workspace module, and install the core Workspace module.

Uninstalling the Workspace module (and all dependencies) will delete all workspaces, and all content in them. Therefore what you will be left with, effectively, is the live workspace and all live content. Installing the new module will recreate a live (and stage) workspace, and all content will be associated with the live workspace. There will be some kind of check available to see if all content has been synced up to the live workspace to prevent real data loss, but we see workspaces as disposable anyway.

Another option we are looking into is being able to replicate content off to another Drupal site (or CouchDB database), then do the uninstall / reinstall process, and sync content back. This will work well because the HTTP API used will be the same on both versions of Relaxed module. However, because of the number of moving parts here we feel the straight uninstall / reinstall process, dropping all non-live content, might actually provide better stability.

This process will be fully documented in release notes and on when the time comes.

It'd be great to hear any feedback from users of the contrib Workspace module if this approach would work.

timmillwood Thu, 07/06/2018 - 10:03


Submitted by Vijay(vijaycs85) (not verified) on Sun, 10/06/2018 - 21:50


I have been thinking about this part especially after I installed contib workspace on 8.6.x core and got weird exception (which remains me to raise this issue)

How does the install/unstall would react to module with same name? Is it still possible to use \Drupal::service('module_installer')?

Uninstalling contrib workspace module means uninstalling replication and multiversion (dependecies) and probably installl again with core module?

Add new comment