Upgrade documentation from 2.x to 3.x

If you don't have any custom JavaScript modifying config at runtime or inserting custom tests, yes, just running drush updb after downloading the new version with composer will run the update hooks to modify the tables, migrate all your config, and rebuild the Views. The checker silently disables itself until you run the update so you don't get an invalid table structure error.

...please test before doing that in production...and tell me if you hit any bugs. The only one I know of at the moment is that the custom selectors field to override PDF selectors isn't working right in 3.0.3, so the checker may throw the generic document manual check rather than the specific PDF document manual check. Not exactly a blocker so I'll deal with that in the next release.

And then if you want to recheck your existing content with the new tests you can use a CSA trial activation to do a one time crawl, but that's not necessary. Most of the new tests are developer facing.

If you do have JS modifying config at runtime, there are some syntax changes I can talk you through until I finish writing a comparison for the Drupal 3.x documentation page.

I you were using the CSV exports in 2.x, that functionality moved into a submodule, so you'd want to enable that too.

I am unable to ship the updated configurations.

>  [notice] Update started: editoria11y_update_9012
>  [error]  'view' entity with ID 'ed11y_action' already exists. 
>  [error]  Update failed: editoria11y_update_9012 

@cilefen I have run into that intermittently on dev sites when I had previously played with alpha/beta versions. Are you seeing this in production on a clean upgrade from 2.x to 3.x, or in dev/local where you were helping me test alpha/beta versions?

Fixing a failed update hook like that in my dev/sandbox sites basically involved "kicking" Drupal's configuration system to drop the View namespace collision without caching it somewhere. E.g., delete the View in the UI, then create a new View with the same machine name (ed11y_action), then delete it again to make sure the delete action completes fully and successfully, then re-try the update.

Thanks for the info. This update broke all our tooling in novel ways, so I am trying to work through it.

Allow me to clarify: the update is failing our CI pipelines in ways we are not accustomed to, so we haven't yet been able to deploy v3 to production.

Notes from Slack: @cilefen has a specific `drush updb` vs `drush ci` order of operations problem, because the 2->3 update hook assumes it will see 2.x config. Updating local, committing that config, then running updb on prod confuses the update hook, whereas updating in production and then running config-import tries to restore un-updated config.

Fix will be to modify update hook 9012 to detect intermediate states and disambiguate. Easy change, but I won't be able to get it out until Monday. I'll fork this into a separate issue for tracking.