WxT 4.x / Drupal 9 upgrade - catch all

new bug and the fix:

BUG

drush upwd admin 'password123'

Crashes horribly with our configuration

here is the fix:

Add this to the composer.json
"drupal/pathauto": "1.x-dev as 1.8",

pathauto 1.x-dev has fixes for Drupal 9 that we need.
alternatively, find patches and patch 1.8

alternatively, I will also try this patch:

https://www.drupal.org/files/issues/2020-11-23/3184164-2.patch

#3184164: Avoid update query for key_value table if the value did not change

Ok, alternatively, this patch is what we need for 1.8

            "drupal/pathauto": {
                "Fixes drush upwd username 'password'":
                "https://www.drupal.org/files/issues/2020-11-23/3184164-2.patch"
            },

Required for Drupal 9, we didn't have this issue in 8x

Another one:
noticed this when going through 4.x changes.

wxt_bootstrap pull request

https://github.com/drupalwxt/wxt_bootstrap/pull/16/files

missing contextual links
these don't show up after 9x upgrade

@sylus, thanks, I am installing a vanilla wxt 4 right now to double check the contextual links

vanilla install currently giving me this:

The website encountered an unexpected error. Please try again later.

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "entity_bundle:group" plugin does not exist. Valid plugin IDs for Drupal\Core\Condition\ConditionManager are: entity_bundle:block_content, entity_bundle:menu_link_content, entity_bundle:node, entity_bundle:taxonomy_term, language, node_type, request_path, current_theme, user_role, panels_title in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

I think it might be related to the page manager issue,

I'll also pull your latest changes and try again

Note, I checked (enabled) all extend options

ok I recloned wxt-project, going to re-install and see what happens.

@sylus

something is wrong with the build, I'm getting older versions of the wxt_bootstrap with the incorrect twig for the replace function

https://github.com/drupalwxt/wxt-project

Please try doing a composer install from a fresh clone fo wxt-project

it's not pulling the latest code for some reason , the fixes we put in aren't comming down

@sylus , for some reason the wxt-project is locked on wxt_bootstrap 4.2 that doesn't have the latest fixes

I did a composer up, it didn't pull the latest, maybe I have to clear my composer cache

can you please check?

We should be pulling wxt_bootstrap f521bb3034 but it's not going.

Ok ya I overrode wxt_bootstrap and wxt_library in the composer.json and that seemed to fix things.

I did find warning from lighting when uploading an image:
(not related to my patch I'm sure)

here's a patch for the issue I just reported:

#3113656-2: PHP 7.4 notice: Trying to access array offset on value of type null in Drupal\lightning_media\Plugin\EntityBrowser\Widget\FileUpload->getCurrentValue()

just tested the patch, it works

here's the test site I have set up

https://wxt.9pro.ca

, as admin I'm looking to add a comment to a blog, can't seem to make a comment.

Not sure if my installation is correct.

blog comment form error, click this link: https://wxt.9pro.ca/en/blog/blog-test#comment-form

Error: Call to undefined method Drupal\comment\CommentForm::url() in Drupal\comment\CommentForm->form() (line 162 of core/modules/comment/src/CommentForm.php).

@sylus our upgrade has a glitch that I think is related to the removal of the '/welcome' page in the base variant

see details here:
#3187383-56: WxT 4.x / Drupal 9 upgrade

#3187383-60: WxT 4.x / Drupal 9 upgrade

where did the /welcome page go in wxt 4.x ?

Anything we can do for that component to have it upgraded?

this probably also be affecting our contextual edit links on our home page.

our remaining bugs are fixed by this missing step in the upgrade process:

Go to the workflow page here: /admin/config/workflow/workflows
Then press edit and then press save for each of our workflows, this will fix the errors that show up in the logs about a missing table and it also fixes the contextual edit links on the home page.

@sylus, we could possibly automate this step in a wxt hook update?
I haven't looked at what code to load but if we load all the workflows and save them in a hook update this fixes our missing table bug and a few other bugs we noticed like a missing edit link on our blocks for our home page.

this above step fixes Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'block_content_r__48d0019ac1' doesn't exist: SELECT "t".* FROM {block_content_r__48d0019ac1}

after edit and save the workflows and cache rebuild the missing table error seems to be resolved.

hmm, noticed in a fresh vanilla install of wxt 4.x that the sidebar menu example content is gone. I added a sidebar menu manually and put it in the sidebar region but the styles didn't look as good as the wxt 3.x ,

looking into this because we've noticed a wxt 3.x issue and I'm wanting to create a patch because it's an issue everyone will want a fix for .
The sidebar in mobile mode currently slides underneith the date modified main content mid footer, there's an easy fix for this by moving the main element below the nav element and remove the push/pull classes from the main / nav elements.

ok so a fresh install wxt has no sidebar menus but Drupal 9 / wxt4 adds a new functionality that can restore it:

So basically add a new menu if you don't have one called sidebar (machine name)

then place a block for the sidebar region (I have a patch to improve the responsiveness of this for wxt3x and wxt4x)

then specify a theme suggestion of 'sidebar' as seen in the screenshot:

see screenshot

This will get you the nicely formatted sidebar menu as per wet-boew:

In pretty good shape, needs review, easy workaround edit each workflow manually and save, I've also noted the other workarounds above.

lots of fixes went in, would be nice to get a new tagged release for both the wxt-project and the site-wxt.

found another issue with the wxt 4x branch

must upgrade linkit as follows:

composer require 'drupal/linkit:^6.0@beta'

otherwise there'll be issues updating your matchers

should also include another patch:

https://www.drupal.org/files/issues/2020-09-21/3078075-13.patch

            "drupal/linkit": {
                "Detect and strip base URL from pasted URLs to increase matching hits":
                "https://www.drupal.org/files/issues/2020-09-21/3078075-13.patch"
            },

see issue:
#3191874: linkit improvement and improved Drupal 9 support

wxt 4.x now has all the suggested fixes except these two workarounds but we should add some troubleshooting nodes for upgrading from perhaps on the wxt project page and from the release description.

So perhaps what we need to do is document this step from comment #29 to fix "Base table or view not found: 1146 Table 'block_content_r__48d0019ac1' doesn't exist: SELECT "t".* FROM {block_content_r__48d0019ac1}" #3188528-29: WxT 4.x / Drupal 9 upgrade - catch all

To fix this, visit /admin/config/workflow/workflows and edit/save each one of the workflows.

I believe we're using the editorial workflow for block.

the only other thing that I didn't figure out the root cause for was another related missing empty table that I had to restore as part of the upgrade process which was pretty easy dumping two empty tables and restoring them.

from this issue documented here:
#3187383-43: WxT 4.x / Drupal 9 upgrade

Base table or view not found: 1146 Table 'block_content__scheduled_transition_date' doesn't exist

dump the missing tables from your 8.x as follows:

mysqldump --user=dbuser --password='password' c1agqa block_content__scheduled_transition_date > block_cst_date.sql
mysqldump --user=dbuser --password='password' c1agqa block_content__scheduled_transition_state > block_cst_state.sql

restore them into your 9.x like this:

drush sqlc < block_cst_date.sql
drush sqlc < block_cst_state.sql

these tables were empty in our system but for some reason we still needed the tables, the workflow transition is enabled for our blocks but we never used a scheduled transition for our blocks, which likely explains why the table was empty in our case.

Other than this, all deprecated api calls in custom code need to be updated to Drupal 9 apis, I think there's a module to help identify deprecated APIs so by all means use this to make your work faster and thorough.

There's also some twig changes needed in your custom theme, see the code changes in wxt_bootstrap between Nov 2020 and Jan 2021 (using git history of course).

As far as the upgrade, once upgraded, custom code switched to non-deprecated apis, wxt4 and D9 works great! A fairly easy upgrade overall, but does require some troubleshooting hopefully we can finalize some documentation for the upgrade steps and troubleshooting section. Thanks for all your work on this @sylus.

Very cool! My upgrades were dev only. I look forward to upgrading production sites and putting them live in the comming months hopefully.

Finally got some cycles to get back to this but now the the upgrade path no longer works, it WAS working, but is totally gonezo now.

fails on wxt_core_update_8400

cannot uninstall or run the config cleanup portion

if I remove the first 10 or so lines of code from this 8400 and bypass this uninstalling can get around this.

I've tried a bunch of things so far, see below:

drush pmu libraries -y;
drush pmu lightning -y;
cp -pr html/profiles/lightning/modules/lightning_install html/modules/contrib;
drush cr;
drush pmu lightning_install -y;
drush gen module --answers='{"name": "wxt_ext_translation", "description": "desc", "package": "wxt"}';
drush cr; drush pmu wxt_ext_translation; drush cr; drush gen module --answers='{"name": "lightning", "description": "desc", "package": "lightning"}';
drush pmu lightning -y;
drush updb -y;
rm -rf html/modules/custom/lightning;
rm -rf html/modules/custom/wxt_ext_translation;

trying a few things and investigating

> [notice] Batch process has consumed in excess of 60% of available memory. Starting new thread
[error] Update aborted by: wxt_core_update_8400
[error] Finished performing updates.

drush config-delete core.entity_view_mode.media.slideshow doesn't help

I'll try some more things

maybe running out of memory, I'll try a few more things.

wrote this script, it always returns 0

  $module_installer = \Drupal::service('module_installer');
  $uninstalled = $module_installer->uninstall([
    'libraries',
    'lightning',
    'lightning_install',
    'wxt_ext_translation',
  ]);
 echo (integer) print_r($uninstalled, TRUE);

this logic is flawed I think, I'll update this shortly.

ok here's my workaround, increase CLI /etc/php.ini php memory_limit from 128M to 192M

1) added libraries 8.x-1.0-beta1 to my composer.json

2) use this new patch for wxt (wxt_core.install):

then:

3) run these commands, notice the fake modules created via the drush gen module function and subsequent uninstalling.

drush cr;
drush gen module --answers='{"name": "lightning_install", "description": "desc", "package": "lightning"}';
drush gen module --answers='{"name": "lightning", "description": "desc", "package": "lightning"}';
drush gen module --answers='{"name": "wxt_ext_translation", "description": "desc", "package": "wxt"}';
drush cr;
drush updb -y;
drush update:wxt -y;
rm -rf html/modules/custom/lightning_install;
rm -rf html/modules/custom/lightning;
rm -rf html/modules/custom/wxt_ext_translation;

If there's other missing modules you either need to find them or increase your memory limit, that seems to cause some strain to the update process.

after I do all this and whatever I did to get this far, the upgrade process works again.

the issue is, the return code from uninstall returns null or false if the module doesn't exist in the filesystem.

My patch instead relies on the schema version which if it's greater than or equal to 0, it has been installed and needs uninstalling.

There's probably more to it than that but the second part of this patch shouldn't need to run if the items were uninstalled which they were being uninstalled but you can't remove what you've already removed so it threw errors.

Now the return codes are corrected, rely on the schema version as I did. This patch is an improvement while maybe not the easiest to read or understand it does improve the behavior.

***EDIT***

yes this patch is needed

note for those upgrading on pg v11 systems: if you're using pg v11 with D9.0.11 or D9.1.6 , you may have to disable 'distinct' query option on the /admin/content page otherwise a wsod on /admin/content until this view advanced settings query options is adjusted and saved.

Please see patch in #3214811: Update hook wxt_core_update_8403 filed while upgrading to d9 with version 4.0.3

Good news, with all the bug fixes we jammed in, I can now upgrade a wxt3x system using the normal drush up:wxt -y; drush up:lightning -y; drush updb -y; using wxt 4.1.x that previously required workarounds

#3207628: Update to D9 core 9.1.10

upgrade process working smoothly for the most part

I've noticed some css differences with gcweb v9 , to be expected

Revisiting this again on another upgrade , this time in preparation for D10.
uninstalling the actual lightning_scheduler crashed when trying to uninstall it

so I did these steps to resolve it

1. removed the modules/contrib/lightning_scheduler module
2. using drush gen module I generated a new empty module called lightning_scheduler
3. then uninstalled it drush pmu lightning_scheduler
4. then run updb / update.php drush updb -y;

Explanation: basically what I did is about the same as just deleting the lightning_scheduler.install file and then rebuilding caches and running the uninstall for lightning_scheduler without any lightning_scheduler_uninstall() functions, these functions were crashing so avoiding this.
basically left a couple tables in the db, no worries.

no errors in the upgrade this time

so far so good thanks again.