After 8.5.0 upgrade: Unknown column revision.revision_default

This could be a duplicate(?).

Did you run all updates (without errors)? If you had an error, repeat and if the error doesn't go away, then post that here. update.php/drush updb must report that there are no pending updates to be executed.

I'm experiencing the same problem.
Can visit nodes without media just fine.
Whenever media is set on a node, the error occurs.

Cannot visit admin/content/media either.

There were no errors on update.php, no updates are pending.

Did have som errors while importing the configuration. I'll investigate further

As I can see the bug in the core\modules\system\system.install system_update_8501() function which adds the revision_default field to all revisionable fields. I've copied the code of this function to my module update function and runned it again - the field still was not added to the table.

Which entity type is missing it in your case?

In case it is media, did you update from media_entity to media at the same time? There is a known issue in the media entity queue about that.

In my case the revision_default field is missed in the block_content_revision table, so looks like the problem is not on the Media module.

Upgrading to 8.5 before switching to media instead of at once did indeed solve the issue for me

system 8501 hook_update_n Add the 'revision_default' field to all relevant entity types.
-------- ----------- --------------- -----------------------------------------------------------------

Do you wish to run the specified pending updates? (yes/no) [yes]:
> yes

[notice] Update started: system_update_8501
[error] An existing "Default revision" field was found for the Aangepast blok entity type, but no "revision_default" revision metadata key was found in its definition.
[error] An existing "Default revision" field was found for the Inhoud entity type, but no "revision_default" revision metadata key was found in its definition.
[error] An existing "Default revision" field was found for the Paragraph entity type, but no "revision_default" revision metadata key was found in its definition.
[ok] Update completed: system_update_8501
[success] Finished performing updates.

It generates these errors for me, yet it markes the update as done.

#2947520: media_entity update path needs to run after system_update_8501 when updating to 8.5.x at the same time was fixed today, you should be able to solve that by upgrading your Media Entity code

I have the same issue @NivaDevs in block_content_revision table.

But after run the script update with command /update.php the database has been updated and everything works now.

I don't have media_entity.

Worth to know I don't have media_entity either on this site and I did the database updates with `drush updb`.

 in <em class="placeholder">Drupal\Core\Entity\Sql\SqlContentEntityStorage-&gt;getFromStorage()</em> (line <em class="placeholder">455</em> of <em class="placeholder">core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php</em>). <pre class="backtrace">Drupal\Core\Database\Statement-&gt;execute(Array, Array) (Line: 625)
Drupal\Core\Database\Connection-&gt;query(&#039;SELECT revision.vid AS vid, revision.langcode AS langcode, revision.revision_uid AS revision_uid, revision.revision_timestamp AS revision_timestamp, revision.revision_log AS revision_log, revision.revision_default AS revision_default, base.nid AS nid, base.type AS type, base.uuid AS uuid, CASE base.vid WHEN revision.vid THEN 1 ELSE 0 END AS isDefaultRevision
FROM 
{node} base
INNER JOIN {node_revision} revision ON revision.vid = base.vid
WHERE base.nid IN (:db_condition_placeholder_0)&#039;, Array, Array) (Line: 87)

EDIT:
#13 seemed to work. After restoring my database backup (pre-update) and updating using update.php, the site started working!

I still have a ton of updates not even a second run of update.php would complete:

  comment    enable_comment_admin_view          post-update   Enable the comment admin view.
  dblog      convert_recent_messages_to_view    post-update   Replace 'Recent log messages' with a view.
  field      remove_handler_submit_setting      post-update   Remove the stale 'handler_submit' setting for entity_reference fields.
  language   language_select_widget             post-update   Add the 'include_locked' settings to the 'language_select' widget.
  locale     clear_cache_for_old_translations   post-update   Clear cache to ensure plural translations are removed from it.
  node       configure_status_field_widget      post-update   Load all form displays for nodes, add status with these settings, save.
  system     change_action_plugins              post-update   Change plugin IDs of actions.
  system     classy_message_library             post-update   Clear caches to ensure Classy's message library is always added.
  system     field_formatter_entity_schema      post-update   Clear caches due to schema changes in core.entity.schema.yml.
  system     field_type_plugins                 post-update   Force field type plugin definitions to be cleared.   @see https:www.drupal.orgnode2403703
  views      bulk_field_moved                   post-update   Update dependencies for moved bulk field plugin.
  views      entity_link_url                    post-update   Add additional settings to the entity link field and convert node_path usage  to entity_link.
  views      filter_placeholder_text            post-update   Add placeholder settings to string or numeric filters.
  views      revision_metadata_fields           post-update   Fix table names for revision metadata fields.
  views      table_display_cache_max_age        post-update   Fix cache max age for table displays.
  views      views_data_table_dependencies      post-update   Include views data table provider in views dependencies.

With a single error:
Drupal\Core\Entity\EntityStorageException: 'action' entity with ID 'comment_delete_action' already exists. in Drupal\Core\Entity\EntityStorageBase->doPreSave() (line 425 of htdocs/core/lib/Drupal/Core/Entity/EntityStorageBase.php). (which is a Php 5.6 error, I am upgrading this site to php 7.1 soon!)

@techwolf12 I ran into the same issue as you did, after reading through system_update_8501, I realised I maybe did something wrong, I ran drush entity-updates, before I ran drush updb, this created an unexpacted state of the DB apparently. So I rolled back the DB and went for a drush updb first, which also resulted in entity-updates having no schema updates anymore. This fixed the issue for me.

Really strange thing, I've just uploaded my backup database and run the update.php script - now everything working correctly.

I also saw this error when upgrading from 8.4.5. Part of my issue was that I had a failed update from webform. So ended up running drush updb and drush entup several times. And I think the field definition for the revision_default field got updated somewhere during all this without the actual field being installed.

To fix it, I commented out the conditional on line 2090 of system.install if (!$definition_update_manager->getFieldStorageDefinition($field_name, $entity_type_id)) {

That let the update get installed properly. Then drush entup no longer complained.

same as #15 I was facing issues when performed drush entup first and drush updb later. Then I rerolled to my backup database and ran update.php first and it worked fine.

same as #15 and #19:
- Restore database
- drush updb
- drush entup
Issue Fixed !

After upgrading from 8.4.5 to 8.5.1, we faced the same issues. However we only ran Drush @env updb and that seemed to solve the issue.

I managed to solve it ONLY by manually creating the new column with MYSQL on table node_revision

Notice that maybe you need to do this for more ENTITY_revision tables too. I had no revisions for other entities.

ALTER TABLE node_revision ADD COLUMN revision_default tinyint(5) AFTER revision_log;

Same issue. Updating from 8.4.5 to 8.5.1 .

Based on #22, tried

drush sql-query "ALTER TABLE node_revision ADD COLUMN revision_default tinyint(5) AFTER revision_log"
drush updb
drush entup
drush cr

This seemed to work successfully from my console, but when navigating to the site, I got the error below: However, I tried to run update.php from the console and that successfully ran all the updates.

The website encountered an unexpected error. Please try again later.Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'revision.revision_default' in 'field list': SELECT revision.revision_id AS revision_id, revision.langcode AS langcode, revision.revision_user AS revision_user, revision.revision_created AS revision_created, revision.revision_log AS revision_log, revision.revision_default AS revision_default, base.id AS id, base.type AS type, base.uuid AS uuid, CASE base.revision_id WHEN revision.revision_id THEN 1 ELSE 0 END AS isDefaultRevision
FROM
{block_content} base
INNER JOIN {block_content_revision} revision ON revision.revision_id = base.revision_id; Array
(
)
in Drupal\Core\Entity\Sql\SqlContentEntityStorage->getFromStorage() (line 455 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Drupal\Core\Database\Statement->execute(Array, Array) (Line: 625)
Drupal\Core\Database\Connection->query('SELECT revision.revision_id AS revision_id, revision.langcode AS langcode, revision.revision_user AS revision_user, revision.revision_created AS revision_created, revision.revision_log AS revision_log, revision.revision_default AS revision_default, base.id AS id, base.type AS type, base.uuid AS uuid, CASE base.revision_id WHEN revision.revision_id THEN 1 ELSE 0 END AS isDefaultRevision
FROM 
{block_content} base
INNER JOIN {block_content_revision} revision ON revision.revision_id = base.revision_id', Array, Array) (Line: 87)
Drupal\Core\Database\Driver\mysql\Connection->query('SELECT revision.revision_id AS revision_id, revision.langcode AS langcode, revision.revision_user AS revision_user, revision.revision_created AS revision_created, revision.revision_log AS revision_log, revision.revision_default AS revision_default, base.id AS id, base.type AS type, base.uuid AS uuid, CASE base.revision_id WHEN revision.revision_id THEN 1 ELSE 0 END AS isDefaultRevision
FROM 
{block_content} base
INNER JOIN {block_content_revision} revision ON revision.revision_id = base.revision_id', Array, Array) (Line: 510)
Drupal\Core\Database\Query\Select->execute() (Line: 455)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->getFromStorage(NULL) (Line: 426)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->doLoadMultiple(NULL) (Line: 242)
Drupal\Core\Entity\EntityStorageBase->loadMultiple() (Line: 46)
Drupal\block_content\Plugin\Derivative\BlockContent->getDerivativeDefinitions(Array) (Line: 101)
Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDerivatives(Array) (Line: 87)
Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDefinitions() (Line: 284)
Drupal\Core\Plugin\DefaultPluginManager->findDefinitions() (Line: 175)
Drupal\Core\Plugin\DefaultPluginManager->getDefinitions() (Line: 22)
Drupal\Core\Plugin\DefaultPluginManager->getDefinition('system_branding_block') (Line: 16)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance('system_branding_block', Array) (Line: 76)
Drupal\Component\Plugin\PluginManagerBase->createInstance('system_branding_block', Array) (Line: 62)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->initializePlugin('system_branding_block') (Line: 57)
Drupal\block\BlockPluginCollection->initializePlugin('system_branding_block') (Line: 80)
Drupal\Component\Plugin\LazyPluginCollection->get('system_branding_block') (Line: 45)
Drupal\block\BlockPluginCollection->get('system_branding_block') (Line: 83)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->setConfiguration(Array) (Line: 99)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->addInstanceId('system_branding_block', Array) (Line: 55)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->__construct(Object, 'system_branding_block', Array) (Line: 34)
Drupal\block\BlockPluginCollection->__construct(Object, 'system_branding_block', Array, 'usporg_branding') (Line: 149)
Drupal\block\Entity\Block->getPluginCollection() (Line: 138)
Drupal\block\Entity\Block->getPlugin() (Line: 113)
Drupal\block\BlockAccessControlHandler->checkAccess(Object, 'view', Object) (Line: 105)
Drupal\Core\Entity\EntityAccessControlHandler->access(Object, 'view', NULL, 1) (Line: 362)
Drupal\Core\Entity\Entity->access('view', NULL, 1) (Line: 56)
Drupal\block\BlockRepository->getVisibleBlocksPerRegion(Array) (Line: 137)
Drupal\block\Plugin\DisplayVariant\BlockPageVariant->build() (Line: 259)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 156)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 664)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

@sassafrass on #23 according to the error message you have also block_revisions enabled. So you have to add manually also the block_content_revision table.

Notice that this is a hack to avoid fatal errors and when you try to update the entities tables (see drush entup) it will not work anyway.

We ran into this issue, and no amount of retrying, rerunning the update, clearing cache, or updating entities resolved the issue. @heddn's suggestion in #18 worked for us however, Thanks, @heddn!

For people who run into this problem when updating to 8.5.x whilst also upgrading Webform.
I've created an issue and patch here: https://www.drupal.org/project/webform/issues/2958102

The patch from the webform issue works for us.

@sassafrass #23 thanks

It seemed to work on my development environment of the project in question, though when rolling the update out to our acceptance environment it failed again. Not sure why it first just worked... I'm back to square one. Pretty ugly bug if you ask me.

Edit: After running de ALTER query in #23 I noticed the error changing slightly. This time it is complaining about the `paragraphs_item` table.

Edit 2:: I've just managed to fix the last problem, which was the missing revision_default column in de paragraphs_item_revision table. I did this by running the ALTER query in #23 with slight modifications:

drush sql-query "ALTER TABLE paragraphs_item_revision ADD COLUMN revision_default tinyint(5) AFTER revision_uid"

I'm still not feeling really confident about this fix, since I really do not know how this issue occurred and if I really fix this issue with this update. Still, in the absence of a better fix, I'll just apply this.

@heddn (#18) - Thanks, guy! drush updb has fixed the issue!

Only solution that worked for me was to add revision_default columns to corresponding tables like so:

drush sql-query "ALTER TABLE node_revision ADD COLUMN revision_default tinyint(5) AFTER revision_log"
drush sql-query "ALTER TABLE block_content_revision ADD COLUMN revision_default tinyint(5) AFTER revision_log"
drush sql-query "ALTER TABLE crop_revision ADD COLUMN revision_default tinyint(5) AFTER revision_log"
drush sql-query "ALTER TABLE paragraphs_item_revision ADD COLUMN revision_default tinyint(5) AFTER revision_uid"
drush updb
drush entup
drush cr

I've got the same issue today while upgrading from 8.3.9 to 8.5.3

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'revision.revision_user' in 'field list': SELECT revision.revision_id AS revision_id, revision.langcode AS langcode, revision.revision_user AS revision_user, revision.revision_created AS revision_created, revision.revision_log AS revision_log, revision.revision_default AS revision_default, base.id AS id, base.type AS type, base.uuid AS uuid, CASE base.revision_id WHEN revision.revision_id THEN 1 ELSE 0 END AS isDefaultRevision FROM {block_content} base INNER JOIN {block_content_revision} revision ON revision.revision_id = base.revision_id; Array ( ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->getFromStorage() (line 455 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

The ALTER to all the 4 tables work by letting the site work again but this still leaves this field to never install:

paragraph entity type :
The Default revision field needs to be updated.
Do you wish to run all pending updates? (y/n): y
Cache rebuild complete. [ok]
Finished performing updates. [ok]
server:~/*env*/tmp$ drush @*app*.*env* entup --strict=0
The following updates are pending:

paragraph entity type :
The Default revision field needs to be updated.
Do you wish to run all pending updates? (y/n): n
Cancelled.

I was receiving this error for several of my _revision tables. I altered all of the tables that threw an error by adding the revision_default column with a tinyint(4) datatype. Now, when I attempt to run entity updates with drush entup, I get the following errors, instead of the original error in this thread:

[error] An existing "Default revision" field was found for the Custom block entity type, but no "revision_default" revision metadata key was found in its definition.
[error] An existing "Default revision" field was found for the Workspace entity type, but no "revision_default" revision metadata key was found in its definition.
[error] An existing "Default revision" field was found for the Content entity type, but no "revision_default" revision metadata key was found in its definition.
[error] An existing "Default revision" field was found for the Replication log entity type, but no "revision_default" revision metadata key was found in its definition.
[error] An existing "Default revision" field was found for the Workspace pointer entity type, but no "revision_default" revision metadata key was found in its definition.
[error] An existing "Default revision" field was found for the Paragraph entity type, but no "revision_default" revision metadata key was found in its definition.

Another vote for drush updb

If you're having issue running drush locally.

I highly recommend you give Lando a spin.
https://docs.devwithlando.io/tutorials/drupal8.html#tooling

Hello !
I've an error like #23.
My solution is quite different.
I just need to run only this hook "system_update_8501" before "drush cim sync" and "drush updb".

Hi,

After updating from 8.4.5 to 8.5.3, I had the same problem

Column not found: 1054 Unknown column 'revision_default' in 'field list': INSERT INTO {paragraphs_item_revision} (id, langcode, revision_default, revision_uid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3); Array ( [:db_insert_placeholder_0] => 48 [:db_insert_placeholder_1] => en [:db_insert_placeholder_2] => 1 [:db_insert_placeholder_3] => 1 )

The solution as #29 is to add manually the missing column, in my case it was revision_default

drush sql-query "ALTER TABLE paragraphs_item_revision ADD COLUMN revision_default tinyint(5) AFTER revision_uid"

Ran into the same problem during a 8.4.8 -> 8.5.3 update. Manually ALTERing the DB or changing core code for the update or such hacks are not viable options in our case because of automated deployments, so I tried to get to the root of the problem. Repeated drush updb and drush entup (starting with either of them) didn't solve the problem tho they haven't reported any error either.

My initial gut feeling (based on the comments above) was that system_update_8501() uses some cached field storage definitions instead of the actual thing. Checking #2891215: Add a way to track whether a revision was default when originally created which introduced this function and #2936511: ContentEntityType::getRevisionMetadataKeys() never considers the BC logic because of the new "revision_default" key which changed it before release didn't help either (at least for me; I'm adding these as related issues anyway). I even tried reproducing the problem with a brand-new standard.profile site (install with 8.4.8, upgrade to 8.5.3 afterwards), but I couldn't find what triggers the erroneous behaviour.

Then I checked if my drush updb runs anything BEFORE system_update_8501() that might be related, and it did indeed: block_content_update_8400() is also run during this update. What's interesting is that this block_content_update_8400() is NOT part of 8.4.8: it only got introduced in #2820848: Make BlockContent entities publishable before 8.5.0-alpha1 – IOW, this function is not intended for 8.4.x (as its number hints), but only for 8.5.x. That's problem A.

Then I tried running system_update_8501() BEFORE block_content_update_8400() (by adding an appropriate hook_update_dependencies() implementation). This way the original problem has vanished: when my drush updb finished, I could find the revision_default column in all my related tables (namely, node_revision, block_content_revision and paragraphs_item_revision, but YMMV based on the modules you're using). That's problem B.

In short: if you run system_update_8501() BEFORE any other update hook that might be related (eg. block_content_update_8400(), dubbed problem B above) then your issue seems to be solved without hackish ALTER TABLEs or manually changing core code for an upgrade – regardless the fact that this block_content_update_8400() should have been numbered something like 8500 as it was introduced only for 8.5.x (dubbed problem A above). OTOH, I must admit I still don't know what the underlying problem is. Because of this and the fact that I couldn't reproduce the problem with a new install based on the standard.profile, I don't provide my system_update_dependencies() – I'm simply setting this to active in the hope somebody will be able to understand what went wrong where and when, and how to fix it.

#18 helped me. I ran the code of the update script without the `if (!$definition_update_manager->getFieldStorageDefinition($field_name, $entity_type_id)) {` condition.

With a fresh install of 8.5.3, if I run:

\Drupal::entityQuery('block_content')->condition('revision_user', 1)->execute();

I get the following:

The website encountered an unexpected error. Please try again later.</br></br><em class="placeholder">Drupal\Core\Entity\Query\QueryException</em>: &#039;revision_user&#039; not found in <em class="placeholder">Drupal\Core\Entity\Query\Sql\Tables-&gt;ensureEntityTable()</em> (line <em class="placeholder">348</em> of <em class="placeholder">core/lib/Drupal/Core/Entity/Query/Sql/Tables.php</em>). <pre class="backtrace">Drupal\Core\Entity\Query\Sql\Tables-&gt;addField(&#039;revision_user&#039;, &#039;INNER&#039;, NULL) (Line: 44)
Drupal\Core\Entity\Query\Sql\Condition-&gt;compile(Object) (Line: 163)
Drupal\Core\Entity\Query\Sql\Query-&gt;compile() (Line: 74)
Drupal\Core\Entity\Query\Sql\Query-&gt;execute() (Line: 1)

In my case, the field does exist, so it might be a different issue that's actually to do with entity queries, but it's presenting with the same error...

Moving this to critical.

#18 helped me too.

Jumping from 8.3 to 8.5 in a CI setup, I had to duplicate the system_update_8501 into a custom update_hook, while commenting the aforementioned conditional check if (!$definition_update_manager->getFieldStorageDefinition($field_name, $entity_type_id)).

@Boobaa: looks like @tstoeckler might have stumbled on a similar/related problem with system_update_8501 in #2841291-158: Fix NOT NULL handling in the entity storage and 'primary key' changes when updating the storage definition of an identifier field.

See also #2820848-130: Make BlockContent entities publishable (and #128-129):

Patch in #129 looks good, as long as it gets into 8.4. Otherwise we won't be able to update content_translation_update_8400().

Looks like it was intended for 8.4.x but the backport didn't make it and the patch wasn't updated before commit.

I think the main problem that's leading to these update path bugs is that we're still using the live entity type definitions in some update functions, so I opened an issue that should help with this: #2976103: Make it possible to retrieve all the last installed entity type definitions at once from the update manager

Marked #2865702: Revert schema version when update process failed. as duplicate. @amateescu is #2976103: Make it possible to retrieve all the last installed entity type definitions at once from the update manager a hard blocker for this one?

@catch, I'm not sure about the fix needed for this issue, but that one is just a small step which would allow us to never have to call the entity manager in update functions, thus eliminating all the possible caching problems.

When you update Drupal 8 version, some contributed module does not support the latest code. you will get a fatal errors when update. After you fix the fatal errors, you may find some strange things. The real issue is: the schema version changed, but the update code have never run.

This issue not only exist when you update to 8.5x, also exist when you update to 8.4.x , 8.3.x.

I tried to reproduce this with many update variations:

8.3.0 to 8.5.0
8.4.0 to 8.5.0
8.4.0 with webform 8.x-5.0-rc1 to 8.5.0 and webform HEAD
8.4.0 to 8.5.0 while forcing system_update_8501() to run before or after block_content_update_8400()

All those with the standard profile and a custom block added in the database, and I couldn't get the error :/

Does anyone who encountered this error still have a backup of the site's files and database before running the update? I've no idea how we could debug this without a way to reproduce it..

catch closed the original issues, maybe there are some bad comments in it.
https://www.drupal.org/project/drupal/issues/2865702

Drupal core update from 8.0 - 8.1, 8.1 - 8.2， 8.2 - 8.3， 8.3-》8.4 8.4-》8.5 are OK.

But real website use many contributed modules. strange things happened when you get a fatal error in update process.

Drupal core update system not stable enough when got a fatal error. For common user they always get a fatal error when updating.

I suggest Drupal core team collect some real drupal 8 sites and make it better.

for exapmle:
update Drupal 8.3 to 8.5 without contributed module, it is OK .

update Drupal 8.3 to 8.5 with contributed module page_manager,
Drupal 8.3 + page_manager 8.x-4.0-beta2
when updating, common user does not know Drupal 8.5 not compatible with page_manager 8.x-4.0-beta2.
1,They just updating Drupal core only, replace Drupal 8.3 with Drupal 8.5.
2,Run update.php. Fatal error. Strange things happened.

3,After they fixed the page_manager version issue, update it to page_manager 8.x-4.0-beta3.

4,Run update.php

5,All thing seems OK.

Maybe they think updating is success. Many functions works correct. Maybe one days later, common user find some function not works correctly.

The bug is exist in step 2:
system_update_8301
system_update_8400
system_update_8401
system_update_8402
system_update_8403
system_update_8501

the schema version of system module changed to 8501, but the code from 8301 to 8501 not run.

Other core module may have the same issue. only use system modules as an example.

Other contributed may cause the same issue, not only page manager.

From my experience:
1, Uninstall Admin Toolbar module before you updating your site, after updating success, install it if you still need it.

Maybe we could fix it in this way, write some document and notice user "rollback it" when fatal error happened. When fatal error happened, tell user use the original files and db backup before they run update.php again. Many users do not know this. They continue step 3 base on step 2. But there is a fatal error at step 2.

The correct updating steps:

1,Updating Drupal core only, replace Drupal 8.3 with Drupal 8.5.
2,Run update.php. Fatal error. Strange things happened.
3,Rollback.
4, Repleace Drupal Core and contributed module to right version, for example page_manager from 8.x-4.0-beta2 to 8.x-4.0-beta3

5,Run update.php.

IF there is still a fatal error, for example, you use panels 8.x-4.1, and it is not compatible with 8.5, you need update it to 8.x-4.3.

6,rollback.

7,Repleace Drupal Core and page_manager and panel with the right version.

8, run update.php

.
.
.

At last, success.

You need update From 8.3 to 8.4 first, then From 8.4 to 8.5.

A better way is:

system_update_8301
system_update_8400
system_update_8401
system_update_8402
system_update_8403
system_update_8501

When fatal error happened, if the code from 8301 to 8501 not run, we should not change the schema version.

I have edit some update document, add
"
Always revert to a backup when you get a fatal error in update process.
"
https://www.drupal.org/docs/8/update/update-core-via-composer
https://www.drupal.org/docs/8/update/update-core-manually
https://www.drupal.org/docs/8/update/update-core-via-drush

Also a patch to Drupal core to remind user to revert it.

This could prevent user get similar issue when update.

@g089h515r806 that patch is a good idea, but please open a new issue for it so we can keep this one for reports of the original bug.

Moving back to 'needs more info'.

#13 This worked.
Ran it via /update.php and that too twice.

@catch, you have closed it.
"Marked #2865702: Revert schema version when update process failed. as duplicate."

I had a fun time debugging this one, but fortunately I was able to get to the root cause. For our scenario, in an implementation of hook_entity_type_build() one of our developers had hard-coded the collection of revision metadata keys that were then set on the given entity type, i.e.

$revision_metadata_keys = [
      'revision_user' => 'revision_user',
      'revision_created' => 'revision_created',
      'revision_log_message' => 'revision_log_message'
    ];
$entity_type->set('revision_metadata_keys', $revision_metadata_keys);

This of course would override the initial set of the 'revision_default' key within the ContentEntityType constructor... Not good :)

Again, definitely not a common cause for this issue, but wanted to add a pointer to check on hook_entity_type_alter/build functions in custom modules.

I faced the same problem. Manually adding the column to SQL table got my site back but drush entup was still trying to update things. The solution for me was to temporarily comment out the if as mentioned in #18 then launching:
drush ev "module_load_include('install', 'system');system_update_8501();"

I had the same problem when I was trying to update a site from 8.2.6 to 8.5.3. What I did is as mentioned by @GaëlG :

drush eval "module_load_install('block_content');block_content_update_8003();"
drush eval "module_load_install('system');system_update_8501();"

#2951279-18: After 8.5.0 upgrade: Unknown column revision.revision_default has worked for me, in my case, what I've ended up doing is a custom hook_update_n that mimics system_update_8501 without the condition

function my_module_update_N() {
  $definition_update_manager = \Drupal::entityDefinitionUpdateManager();

  // Clear the cached entity type definitions so we get the new
  // 'revision_default' revision metadata key.
  \Drupal::entityTypeManager()->clearCachedDefinitions();

  // Get a list of revisionable entity types.
  /** @var \Drupal\Core\Entity\ContentEntityTypeInterface[] $definitions */
  $definitions = array_filter(\Drupal::entityTypeManager()->getDefinitions(), function (EntityTypeInterface $entity_type) use ($definition_update_manager) {
    if ($entity_type = $definition_update_manager->getEntityType($entity_type->id())) {
      return $entity_type->isRevisionable();
    }
    return FALSE;
  });

  // Install the 'revision_default' field.
  foreach ($definitions as $entity_type_id => $entity_type) {
    $field_name = $entity_type->getRevisionMetadataKey('revision_default');
    // Install the 'revision_default' field if needed.
    // Make sure the new "revision_default" revision metadata key is available
    // also to code using the latest installed definition.
    $installed_entity_type = $definition_update_manager->getEntityType($entity_type_id);
    $revision_metadata_keys = $installed_entity_type->get('revision_metadata_keys');

    if (!isset($revision_metadata_keys['revision_default'])) {
      // Update the property holding the required revision metadata keys,
      // which is used by the BC layer for retrieving the revision metadata
      // keys.
      // @see \Drupal\Core\Entity\ContentEntityType::getRevisionMetadataKeys().
      $required_revision_metadata_keys = $installed_entity_type->get('requiredRevisionMetadataKeys');
      $required_revision_metadata_keys['revision_default'] = $field_name;
      $installed_entity_type->set('requiredRevisionMetadataKeys', $required_revision_metadata_keys);

      // Update the revision metadata keys to add the new required revision
      // metadata key "revision_default".
      $revision_metadata_keys['revision_default'] = $required_revision_metadata_keys['revision_default'];
      $installed_entity_type->set('revision_metadata_keys', $revision_metadata_keys);

      $definition_update_manager->updateEntityType($installed_entity_type);
    }

    $storage_definition = BaseFieldDefinition::create('boolean')
      ->setLabel(t('Default revision'))
      ->setDescription(t('A flag indicating whether this was a default revision when it was saved.'))
      ->setStorageRequired(TRUE)
      ->setTranslatable(FALSE)
      ->setRevisionable(TRUE)
      // We cannot tell whether existing revisions were default or not when
      // they were created, but since we did not support creating non-default
      // revisions in any core stable UI so far, we default to TRUE.
      ->setInitialValue(TRUE);

    $definition_update_manager
      ->installFieldStorageDefinition($field_name, $entity_type_id, $entity_type_id, $storage_definition);
  }
}

As @amateescu stated in #2976035-11: Entity type CRUD operations must use the last installed entity type and field storage definitions the issue here is caused because of entity CRUD operations relying on the live / dynamic entity types instead on the last installed ones.

The problem occuring here is reproducible if there is an update hook running before the system_update_8501 and in this hook entity CRUD operations are performed on a revisionable content entity type. The problem is even reproducible with the contrib module search_api_solr, which is reimporting its optional configuration in hook_update_N. I don't know why but somehow once it happened that locally in my instance that hook was executed before the system update, leading to re-saving a config entity "block" leading to loading all content entities "block_content". Loading those entities with the live entity type is impossible, because the revision_default field will be included in the select statement of the query, which will throw a PDOException on execution.

Actually... actually ... from our side everything is fine, because as stated in the documentation of hook_update_N we don't support entity CRUD operations in that update phase. But contrib and custom code will still do it, because it is possible. I am reopening the current issue, because with this knowledge it is sure that system_update_N is breaking more and more sites. I think we need a fast solution here before the other issue is ready, even a dirty solution will be better than further breaking sites.

What do you think about setting a flag in the state service in system_update_8501 and adding the revision_default entity key to the entity type only if this flag is set?

In a dedicated issue I would go further and check if entity CRUD operations are performed during a hook_update_N and if so trigger a notice with a message pointing out that even if the update is successful it is possible that under the hood something got broken. Or we simply forbid entity CRUD operations in hook_update_N and throw an Exception in such cases.

One more option would be to ensure that system_update_N runs before all other updates.

What do you think about setting a flag in the state service in system_update_8501 and adding the revision_default entity key to the entity type only if this flag is set?

Not sure I understand this suggestion to be honest.

In a dedicated issue I would go further and check if entity CRUD operations are performed during a hook_update_N and if so trigger a notice with a message pointing out that even if the update is successful it is possible that under the hood something got broken. Or we simply forbid entity CRUD operations in hook_update_N and throw an Exception in such cases.

Let's open a new issue for that, maybe we can get away with a notice in 8.6.x and an exception in 8.7.x

I didn't know that system updates are intended to run before all other updates and my 2 previous comments were based on my observations that the system update was executed in my case as one of the last updates. Today suddenly this is not the case anymore and now the system_update_8501 is being executed as one of the first ones - not the first one, because I have a dependency in a custom code, which has to run first. The problem is that I don't remember to have changed anything that might have influence on this, at least not direct influence.

I've searched for related issues and found #1894286: System updates are executed without priority.

I've read again the comments in the current issue and #2951279-38: After 8.5.0 upgrade: Unknown column revision.revision_default is pretty interesting, because there the observations are similar to mine from the last days - there are updates which are running before the system updates, even if they don't have dependencies. It happened once that search_api_solr_update_8210 was executed before system_update_8501, which has broken my update as the others here are complaining. This sounds pretty much like #1894286: System updates are executed without priority, for which we still don't have proof (test) and cannot really reproduce. In the current issue we have more than enough cases where the updates failed and I think we can now almost definitely conclude that they've failed, because the system_update_8501 was not executed as one of the first updates but for some reason was moved back in the list.

The only possible way for a system update to be executed later is if another update has been declared as a precondition on it in hook_update_dependencies. Still the system update should be executed no later than after the update that is a precondition of the system update.

----

Re #65:

Not sure I understand this suggestion to be honest.

Code never lies :) :

function system_update_8501() {
  $definition_update_manager = \Drupal::entityDefinitionUpdateManager();

  // Clear the cached entity type definitions so we get the new
  // 'revision_default' revision metadata key.
  \Drupal::state()->set('system_update_8501', TRUE);
  \Drupal::entityTypeManager()->clearCachedDefinitions();
...
}

class ContentEntityType extends EntityType implements ContentEntityTypeInterface {
...
  public function __construct($definition) {
  ...
    if (\Drupal::state()->get('system_update_8501')) {
      if (!isset($this->revision_metadata_keys['revision_default'])) {
        $this->requiredRevisionMetadataKeys['revision_default'] = 'revision_default';
      }
    }
  ...
  }
...
}

@catch, what do you think? If we do this, then even if there are updates running before the system update and performing entity CRUD operations, they will run safely with this code addition as the revision_default field will not be returned. This is a dirty solution, but I think the fastest one we could offer.

Let's open a new issue for that, maybe we can get away with a notice in 8.6.x and an exception in 8.7.x

I've opened #2982555: Prevent entity CRUD operations in hook_update_N.

@hchonov, update functions should be self-sufficient (or self-contained? english fails me here :) ), so the order in which they run should have no impact on whether they succeed or not, unless in very specific and rare cases when there is an actual dependency between two update functions.

The real problem here is the usage of live entity type definitions in system_update_8501(), which is a big no-no.

@amateescu:

update.inc:

function update_get_update_list() {
  // Make sure that the system module is first in the list of updates.
  $ret = ['system' => []];

---

\Drupal\system\Controller\DbUpdateController::selection():
// Ensure system.module's updates appear first.
$build['start']['system'] = [];

---

\Drush\Commands\core\UpdateDBCommands::getUpdatedbStatus() : 

// Ensure system module's updates run first.
$start['system'] = [];

Those are two examples from our code base and one from drush that it is desired that system updates are run first.

update functions should be self-sufficient (or self-contained? english fails me here :) ), so the order in which they run should have no impact on whether they succeed or not, unless in very specific and rare cases when there is an actual dependency between two update functions.

The real problem here is the usage of live entity type definitions in system_update_8501(), which is a big no-no.

I agree with you that this is a problem. There are problems with using the live entity types, but those problems arise in the current issue because somehow Drupal is failing to ensure that system updates are executed first. If we ensure correct update order then the system update will perform without causing any harm.
Even if we start using the installed instead the live entity types we still should prevent entity CRUD operations in hook_update_N. As for now system_update_8501 could be isolated if we do what I've suggested in my previous comment. I think that we need a new release as soon as possible with something that is working.

so the order in which they run should have no impact on whether they succeed or not

Theoretically, yes. Practically, no :). Why - because if you have a bunch of contrib modules and upgrade between minor Drupal releases and new contrib module versions at the same time then we have no idea what could happen and therefore we still have to ensure that the system updates are executed first. I am afraid to say how many updates (core, custom and contrib) are going to be executed in our next release :). ... and after I've seen it locally that the update order suddenly changes I am afraid that something might break.

What I am trying to say is that no matter how we look at it - whether the update order or the usage of live entity types is causing the problems - we still have to fix both, but first we need a solution for the current issue which is going to land in a patch release, as the other problems cannot be fixed in a patch release.

Hopefully this will not cause any tests to fail.

Not sure about the approach in #69, but to avoid failures the state value needs to be set in system_install() too so it's set on new sites.

Not sure about the approach in #69, but to avoid failures the state value needs to be set in system_install() too so it's set on new sites.

I am not sure either, thus am I describing it as a "dirty" one. But I think it is better than nothing.

Oups.

The solution for me:
On terminal :

drush sql-query "ALTER TABLE node_revision ADD COLUMN revision_default tinyint(5) AFTER revision_log"
drush sql-query "ALTER TABLE block_content_revision ADD COLUMN revision_default tinyint(5) AFTER revision_log"
drush sql-query "ALTER TABLE crop_revision ADD COLUMN revision_default tinyint(5) AFTER revision_log"
drush sql-query "ALTER TABLE paragraphs_item_revision ADD COLUMN revision_default tinyint(5) AFTER revision_uid"

drush updb
drush entup
drush cr (clear caches!;-)

It works for me!

Please, please, please!

Don't run drush entup on a production database, unless you know exactly what you're doing, that drush command is only designed to be a development helper. If you are still willing to use it, please make sure that the only pending update is the one concerning the revision_default column, or you could mess your DB schema even more.

I hope I finally got this ugly solution to work ...

I think either this is the fast way to go or #1894286: System updates are executed without priority, for which I've provided steps to reproduce in #1894286-14 and a patch ensuring that system updates are executed before others.

From my observations and research I am at 99.99 % sure that the problem that sites are experiencing is because system updates are rearranged under some circumstances in a way that puts them back in the list of updates that will be executed. So if we don't want an ugly solution from here then a review on the patch in the referenced issue will be much appreciated.

One more time - @amateescu is correct that if we would've used the last installed definitions instead of the dynamic/live ones then the problem here would've never occurred. This is a issue on its own which has to be fixed as well.

But if we ensure an updates order where the system updates are executed first then most probably there should be no more sites reporting problems ... except they define in hook_update_dependencies that a specific update has to be executed before system_update_8501 and revisionable content entities are loaded in that update hook.

The update tests are passing when run locally, but they fail on CI. Other test fails need further work.

I guess it isn't worth it to continue working on that solution.

What do you think about #1894286-15: System updates are executed without priority as a solution for the problem here? If the solution in the referenced issue is accepted then here we could add a notice to the system_update_8501 that there should be no updates defined as a precondition of it in which entity CRUD operations on revisionable content entity types are performed.

I've talked with @tstoeckler and he suggested, that I should provide a patch which shows how easy the problem might occur - simply by creating a block config entity and saving it.

The first patch case1 shows that if the new update creating a block config entity runs before block_content_update_8400 we already have a similar problem to the one being reported here but with block_content_update_8400.

The second patch case2 ensures that block_update_8004 runs after block_content_update_8400, but it still runs before system_update_8501 and we get the same failures like reported here by simply running e.g. \Drupal\Tests\aggregator\Functional\Update\AggregatorUpdateTest. By applying the patch from #1894286-20: System updates are executed without priority case2 doesn't fail anymore.

Yes, with this we see that the problem reported here might easily occur also because of other updates, not only the system ones. But the problem here can be fixed by ensuring that the system updates are executed before all others.

One might say that entity CRUD operations are not allowed in hook_update_N and that this is documented in hook_update_N, but there is a case which is not documented - installing a module in hook_update_N which contains config entities. There are cases where one isn't aware of the usage of entity CRUD operations when performing certain actions in hook_update_N. We even have examples in core where we use entity CRUD operations in hook_update_N - file_update_8001. All this for sure makes the need for #2982555: Prevent entity CRUD operations in hook_update_N more clearer.

In my case, I already had the revision_default field, but NOT revision_user, revision_created, or revision_log.

I was getting the error:

Column not found: 1054 Unknown column 'revision.revision_user'

The version on my site at the time of running this is 8.5.4. It's a site that was just migrated from 8.4.7.

Here are some drush commands to fix it, plus the revision_default if you also don't have that.
Each individual command will fail if the column or index already exists, so it should be pretty safe to run.

drush sqlq "ALTER TABLE block_content_revision ADD COLUMN revision_user INT(10) UNSIGNED NULL DEFAULT NULL COMMENT 'The ID of the target entity.' AFTER langcode;"
drush sqlq "ALTER TABLE block_content_revision ADD INDEX block_content_field__revision_user__target_id (revision_user) USING BTREE;"
drush sqlq "ALTER TABLE block_content_revision ADD COLUMN revision_created INT(11) NULL DEFAULT NULL AFTER revision_user;"
drush sqlq "ALTER TABLE block_content_revision ADD COLUMN revision_log LONGTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL AFTER revision_created;"
drush sqlq "ALTER TABLE block_content_revision ADD COLUMN revision_default TINYINT(4) NULL DEFAULT NULL AFTER revision_log;"

Running the sql queries found in #76 worked for me.

Drupal 8.6.1, recently updated from 5.7.
I have this error with the Profile, "The Default revision field needs to be updated"
The profile_revision table is empty. It does contain a column for revision_default.
What am I missing to correct this?

 $ drush updatedb:status
 --------------------- ----------- --------------- ------------------------------------------------- 
  Module                Update ID   Type            Description                                      
 --------------------- ----------- --------------- ------------------------------------------------- 
  profile entity type               entity-update   The Default revision field needs to be updated.  
 --------------------- ----------- --------------- ------------------------------------------------- 

When we apply the patch from #78 we experience "Field is unknown" errors whenever we add or edit content on the website:

Drupal\Core\Entity\EntityStorageException: Field is unknown. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 829 of /mnt/www/html/sitimehxatcwblf4/docroot/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

The files that seem to be explicitly responsible for this error are:

• docroot/core/lib/Drupal/Core/Entity/ContentEntityType.php
• docroot/core/lib/Drupal/Core/Entity/EntityFieldManager.php

The patch modified these to add conditional code checking for system_update_8501:

if (\Drupal::state()->get('system_update_8501')) {

That seems to be the only change made to those two files, but including them in a commit causes the "Field is unknown" error across all content edits/adds.

After applying the patch 2951279-78_0, running drush updatedb:status results in the following message:

 --------------------------- ----------- --------------- ----------------------------------------------------- 
  Module                      Update ID   Type            Description                                          
 --------------------------- ----------- --------------- ----------------------------------------------------- 
  block_content entity type               entity-update   The Default revision field needs to be uninstalled.  
  node entity type                        entity-update   The Default revision field needs to be uninstalled.  
  paragraph entity type                   entity-update   The Default revision field needs to be uninstalled.  
 --------------------------- ----------- --------------- ----------------------------------------------------- 

Running drush updb returns No database updates required. Running drush entity-updates only resolves one of those (block_content), and the other two show SQLSTATE error indicating "Column not found".

Any ideas on how to resolve this? I suspect our DB has some kind of structural issue, but I'm not a strong enough Drupal dev to understand what is wrong or how to fix it.

Given #82 I'm going to reclassify this as a support request - however bug reports should definitely be opened against contributed modules doing CRUD operations with blocks in hook_update_N().

Running drush entup fixed the issue for me.

Hi guys, same issue in Drupal 8.5.x trying to replace Media Entity with Media (Core). I got enabled workspace in 8.x-1.0-beta8 and multiversion in 8.x-1.0-beta9 version:

Performing media_entity_update_8201

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'revision.revision_user' in 'field list': SELECT revision.vid AS vid, revision.langcode AS langcode, revision.revision_user AS      [error]
revision_user, revision.revision_created AS revision_created, revision.revision_log_message AS revision_log_message, revision.revision_default AS revision_default, base.mid AS mid,
base.bundle AS bundle, base.uuid AS uuid, CASE base.vid WHEN revision.vid THEN 1 ELSE 0 END AS isDefaultRevision
FROM 
{media} base
INNER JOIN {media_revision} revision ON revision.vid = base.vid
INNER JOIN {media_field_data} field_data ON field_data.mid = base.mid
INNER JOIN {media_field_revision} revision_data ON revision_data.vid = revision.vid
WHERE (revision_data._deleted = :db_condition_placeholder_0) AND (field_data.workspace = :db_condition_placeholder_1); Array
(
    [:db_condition_placeholder_0] => 0
    [:db_condition_placeholder_1] => 1
)

Thanks @TheodorosPloumis and @sassafrass, #23 got me over a hurdle.

thanks #93, this worked for my case too.
drush entup

I had the similar errors shown in below after upgrading to 8.8.5 from 8.6.x. In summary, I needed to add several columns and it worked.

1. ALTER TABLE `node_field_data` ADD `revision_timestamp` INT(11) NOT NULL;
2. ALTER TABLE `node_field_data` ADD `revision_uid` INT(10) NOT NULL;
3. ALTER TABLE `node_field_data` ADD `revision_log` LONGTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
4. ALTER TABLE `node_field_revision` ADD `revision_timestamp` INT(11) NOT NULL;
5. ALTER TABLE `node_field_revision` ADD `revision_uid` INT(10) NOT NULL;
6. ALTER TABLE `node_field_revision` ADD `revision_log` LONGTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

1. Drupal\Core\Entity\EntityStorageException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'revision_timestamp' in 'field list': INSERT INTO {node_field_data} (nid, vid, type, langcode, title, uid, status, created, changed, promote, sticky, revision_timestamp, revision_uid, revision_log, revision_translation_affected, default_langcode, content_translation_source, content_translation_outdated) VALUES ...
   

2. Drupal\Core\Entity\EntityStorageException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'revision_uid' in 'field list': INSERT INTO {node_field_data} (nid, vid, type, langcode, title, uid, status, created, changed, promote, sticky, revision_timestamp, revision_uid, revision_log, revision_translation_affected, default_langcode, content_translation_source, content_translation_outdated) VALUES ...
   

3. Drupal\Core\Entity\EntityStorageException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'revision_log' in 'field list': INSERT INTO {node_field_data} (nid, vid, type, langcode, title, uid, status, created, changed, promote, sticky, revision_timestamp, revision_uid, revision_log, revision_translation_affected, default_langcode, content_translation_source, content_translation_outdated) VALUES ...
   

4. Drupal\Core\Entity\EntityStorageException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'revision_timestamp' in 'field list': INSERT INTO {node_field_revision} (nid, vid, langcode, title, uid, status, created, changed, promote, sticky, revision_timestamp, revision_uid, revision_log, revision_translation_affected, default_langcode, content_translation_source, content_translation_outdated) VALUES ...

5. Drupal\Core\Entity\EntityStorageException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'revision_uid' in 'field list': INSERT INTO {node_field_revision} (nid, vid, langcode, title, uid, status, created, changed, promote, sticky, revision_timestamp, revision_uid, revision_log, revision_translation_affected, default_langcode, content_translation_source, content_translation_outdated) VALUES ...
   

6. Drupal\Core\Entity\EntityStorageException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'revision_log' in 'field list': INSERT INTO {node_field_revision} (nid, vid, langcode, title, uid, status, created, changed, promote, sticky, revision_timestamp, revision_uid, revision_log, revision_translation_affected, default_langcode, content_translation_source, content_translation_outdated) VALUES ...
   
   

I am closing this support request because there have been no recent comments.

The Drupal Core issue queue is not the ideal place for support requests. Consider other sources of support.