First attempt at migrating to Drupal 9 -> many questions

[joachim]

Hi Sebastien

@sponce

Concerning the site, it’s ok to keep it on drupal 8 for some time with visibility only within CERN. As you can guess, most of our members are at CERN anyway. Just a question : how shall I trigger the migration when we are ready ?

I need to accentuate that while you naturally have time to make your website Drupal 9 compatible, we strongly encourage everyone to get it resolved as fast as possible (hence us stressing November 2nd!). We very much appreciate the short notice, and understand that it can be hard to allocate resources in this manner. However, we hope that the Upgrade Status tool will help ease the process; even in instances where work is necessary. As for triggering the migration when you are ready: We will be at your disposal for that, please just let us know!

@sponce

There is no such entry “Modules → Custom” in my site, neither under drupal 8, nor on the test site under drupal 9. My own custom module (rcc_module) is installed directly in “Modules”.

I see. This differs slightly from the norm. In general, all custom modules will be present in the Modules → Custom subfolder. This way, you can easily distinguish between modules which you actually have installed yourself, and modules which were included as part of your initial site creation.

@sponce

So I’m still not really sure what you mean by “it is generally good practice to properly remove modules” for the ones in the remove list. And I have 33 there !

All modules which show up in the REMOVE section are modules which are not actually used by your website. Instead, they are either modules which have been centrally distributed (e.g. a bunch of CERN ... modules), or they are modules which your website at one point or another has utilised. The actual list is going to be revised slightly as we try and shorten it centrally (e.g. remove some of the CERN ... modules from showing).

The reason why we recommend users to examine the modules listed here despite them being safe to ignore is that every module will still show up under the Extend tab. This means that if incompatible modules are left lingering around, there is a risk someone inadvertently attempts to install what would then be an incompatible module months into the future. This could break the website in question.

@sponce

I probably can drop it if the defects are gone. So indeed, not much difference between the 2 sections ?

In your specific case, no, not so much!

@sponce

I’m puzzled by your answer here : will the migration occur this week or not ? You were saying we would stay on drupal 8. Or do you mean that we will migrate to openshift, but still under Drupal 8 ? If yes, where can we test this ?

Apologies for any confusion!

Allow me to rephrase: Two things are happening these weeks. The first is all websites being moved to the OpenShift infrastructure. This is a separate operation from the Drupal 9 upgrade entirely, though it happens around the same time! The move to OpenShift itself eases a lot of other tasks, including those concerning managing Drupal across CERN.

The .webtest.cern.ch website is a preview of your production website on the OpenShift infrastructure. It is there to both give you a chance to inspect how things look as well as peak at the Upgrade Status report, thereby allowing you to understand what, if anything, needs updating on your production website(s) prior to upgrading to Drupal 9. The .webtest.cern.ch version is on a Drupal 8.9 installation. It is not yet upgraded to Drupal 9.

@sponce

Ok, I’m progressing a tiny bit : I’ve sorted out the CERN Override theme (simple rebase was enough) and updated it.

Happy to hear this, thanks for the update!

@sponce

I think I understand also why the rescan does not change things : because I assumed this was restarting from my original web site and thus I was updating package versions there. I now suppose that I should update package version on the webtest site and redo it if fine on the original site. Is that correct ? Can you maybe make this clear in the documentation if it it correct ?

Correct. While the .webtest.cern.ch is a preview version, you can think of it is a test website in that regard. Changes applied to the .webtest.cern.ch website are not going to persist on your production website; though at the same time, any potentially breaking changes are not going to affect your production website either. I will make this clearer in the documentation; thanks for the feedback!

@sponce

trying to update Calendar package on the webtest site, the update complains that “You are not using an encrypted connection, so your password will be sent in plain text.” and then says “To continue, provide your server connection details”. Is that another “feature” of the webtest setup ?

This is not something we have had reported before.

We will publish revised Update and Removal guides later today… hopefully these will resolve this.

Thanks for your many detailed responses and questions!