I was hoping that today's minor update (8.1.8) will fix this problem, present since I did a migrate-upgrade to Drupal 8 (I think it was to 8.1.3 when I did that).

The problem

After I associate a vocabulary with a taxonomy field in any given content type (img1) I still can't pick terms for that field via its term selection box (img2), or from a radio box.

Autocomplete widget on the other hand, does serve terms, but when I save the node containing them, The site crashes with the error: "The website encountered an unexpected error. Please try again later."

Here are drush wd-show errors, appearing right after such crash:

 83089  09/Aug 00:32  php       error     Drupal\Core\Entity\EntityStorageException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'title' cannot be null: INSERT INTO {node_field_data} (nid, vid, type, langcode, tit
 83088  09/Aug 00:32  node      error     Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'title' cannot be null: INSERT INTO {node_field_data} (nid, vid, ty

I should note that the rest of the site seems to work just fine... Any advise from the programmers on how to solve it?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Benia created an issue. See original summary.

Benia’s picture

Issue summary: View changes
Benia’s picture

Issue summary: View changes
alexpott’s picture

@Benia can you provide a full error. The error should have the key name. And if possible a backtrace?

Benia’s picture

Issue summary: View changes

Pasted the full longer version.

Benia’s picture

Issue summary: View changes
Benia’s picture

Issue summary: View changes
Benia’s picture

Issue summary: View changes
Benia’s picture

Issue summary: View changes
alexpott’s picture

@Benia can you do drush ws --full

alexpott’s picture

Also a backtrace will help. To get a backtrace turn on verbose logging and then do the actions on your site that create the error and the error and backtrace should display on the screen.

Benia’s picture

Issue summary: View changes
Benia’s picture

I don't have a backtrace as I've yet to learn how to extract it from an IDE in relation to a given local webpage.

Anyway, I have updated the thread with an error appearing in wd-show directly after saving a node with autocomplete terms and drush ws -full ...

Benia’s picture

Issue summary: View changes
Benia’s picture

Issue summary: View changes
cilefen’s picture

68877 04/Aug 10:03 php warning Warning: DateTime::createFromFormat(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() func

That error is unrelated and is because the server has not got a timezone set in php.ini.

cilefen’s picture

Re #13, #11 explains how to create a backtrace. There is no IDE involved.

Benia’s picture

Here is the Verbose logging error when saving a node with autocomplete-added taxonomy terms; It seems to appear only for nodes from content types that where migrated from Drupal 7, and not for new ones I create:

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

Drupal\Core\Entity\EntityStorageException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'title' cannot be null: INSERT INTO {node_field_data} (nid, vid, type, langcode, title, uid, status, created, changed, promote, sticky, revision_translation_affected, default_langcode) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12); Array ( [:db_insert_placeholder_0] => 370 [:db_insert_placeholder_1] => 370 [:db_insert_placeholder_2] => benia_blog [:db_insert_placeholder_3] => he [:db_insert_placeholder_4] => [:db_insert_placeholder_5] => 1 [:db_insert_placeholder_6] => 1 [:db_insert_placeholder_7] => 1470329585 [:db_insert_placeholder_8] => 1470329732 [:db_insert_placeholder_9] => 1 [:db_insert_placeholder_10] => 0 [:db_insert_placeholder_11] => 1 [:db_insert_placeholder_12] => 1 ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 770 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Drupal\Core\Database\Statement->execute(Array, Array) (Line: 610)
Drupal\Core\Database\Connection->query('INSERT INTO {node_field_data} (nid, vid, type, langcode, title, uid, status, created, changed, promote, sticky, revision_translation_affected, default_langcode) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12)', Array, Array) (Line: 81)
Drupal\Core\Database\Driver\mysql\Connection->query('INSERT INTO {node_field_data} (nid, vid, type, langcode, title, uid, status, created, changed, promote, sticky, revision_translation_affected, default_langcode) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12)', Array, Array) (Line: 32)
Drupal\Core\Database\Driver\mysql\Insert->execute() (Line: 917)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->saveToSharedTables(Object) (Line: 855)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->doSaveFieldItems(Object) (Line: 263)
Drupal\Core\Entity\ContentEntityStorageBase->doSave(NULL, Object) (Line: 392)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 761)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object) (Line: 364)
Drupal\Core\Entity\Entity->save() (Line: 356)
Drupal\node\NodeForm->save(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 583)
Drupal\Core\Form\FormBuilder->processForm('node_benia_blog_form', Array, Object) (Line: 314)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 48)
Drupal\Core\Entity\EntityFormBuilder->getForm(Object) (Line: 113)
Drupal\node\Controller\NodeController->add(Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array) (Line: 139)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 62)
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: 98)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 77)
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: 628)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Benia’s picture

Issue summary: View changes
Benia’s picture

Any advice?

Benia’s picture

Issue summary: View changes
alexpott’s picture

It looks like there's no title being set for some reason - do you have some automatic titling module enabled? In fact what modules are installed on the site - if you can export the core.extension config and paste that here that would tell us.

Benia’s picture

No custom modularity. Modules are: Admin_toolbar, Token, Metatag, Search404. That's basically it (including 2 installed after these --- Contact block and Honeypot).

If you meant to core/config/install/core.extension.yml ? This file is basically empty:

module: {}
theme: {}
cilefen’s picture

Re #22, Alex is referring to admin/config/development/configuration/single/export to export a configuration.

Benia’s picture

Simple configuration:

All is zero besides:

  menu_link_content: 1
  content_translation: 10
  views: 10
  standard: 1000

theme:
_core:
  default_config_hash: m2GVq11UAOVuNgj8x0t5fMOPujpvQQ_zxLoaly1BMEU
langcode: he

2 different category fields:

This one is from a content type that was created after migration and I that I can add terms to its nodes:

uuid: fe4d8228-e85e-4c53-ae09-ded4014891ac
langcode: he
status: true
dependencies:
  config:
    - field.storage.node.field_categories
    - node.type.a
    - taxonomy.vocabulary.categories
id: node.a.field_categories
field_name: field_categories
entity_type: node
bundle: a
label: סיווג
description: ''
required: false
translatable: false
default_value: {  }
default_value_callback: ''
settings:
  handler: 'default:taxonomy_term'
  handler_settings:
    target_bundles:
      categories: categories
    sort:
      field: _none
    auto_create: false
    auto_create_bundle: ''
field_type: entity_reference

This one is from a content type that was created before migration and I that I cannot add terms to its nodes (just like all others of the sort):

uuid: 49b2a32b-76cc-4796-a830-80ea34508021
langcode: he
status: true
dependencies:
  config:
    - field.storage.node.field_categories
    - node.type.benia_blog
    - taxonomy.vocabulary.categories
id: node.benia_blog.field_categories
field_name: field_categories
entity_type: node
bundle: benia_blog
label: סיווג
description: ''
required: false
translatable: false
default_value: {  }
default_value_callback: ''
settings:
  handler: 'default:taxonomy_term'
  handler_settings:
    target_bundles:
      categories: categories
    sort:
      field: _none
    auto_create: false
    auto_create_bundle: ''
field_type: entity_reference
alexpott’s picture

@Benia can you show the entire core.extension export - the 0 here refers to the module weight - this way we'll be able to see what core and contrib modules you have installed. Thanks.

alexpott’s picture

Also can you create nodes of the type benia_blog without terms?

Benia’s picture

Yes, I can create nodes of "old" content types (Benia blog or any other "old" content type) when these do not include taxonomy terms.

Did you mean to that?

module:
  admin_toolbar: 0
  admin_toolbar_tools: 0
  aggregator: 0
  automated_cron: 0
  block: 0
  block_content: 0
  breakpoint: 0
  ckeditor: 0
  color: 0
  comment: 0
  config: 0
  config_translation: 0
  contact: 0
  contact_block: 0
  contextual: 0
  datetime: 0
  dblog: 0
  dynamic_page_cache: 0
  editor: 0
  field: 0
  field_ui: 0
  file: 0
  filter: 0
  help: 0
  history: 0
  honeypot: 0
  image: 0
  language: 0
  link: 0
  locale: 0
  menu_ui: 0
  metatag: 0
  metatag_open_graph: 0
  node: 0
  options: 0
  page_cache: 0
  path: 0
  quickedit: 0
  rdf: 0
  rdfui: 0
  responsive_image: 0
  search: 0
  search404: 0
  shortcut: 0
  sitemap: 0
  statistics: 0
  syslog: 0
  system: 0
  taxonomy: 0
  telephone: 0
  text: 0
  token: 0
  toolbar: 0
  tour: 0
  update: 0
  user: 0
  views_ui: 0
  menu_link_content: 1
  content_translation: 10
  views: 10
  standard: 1000
theme:
  stable: 0
  classy: 0
  bartik: 0
  seven: 0
  business: 0
_core:
  default_config_hash: m2GVq11UAOVuNgj8x0t5fMOPujpvQQ_zxLoaly1BMEU
langcode: he
Benia’s picture

Will gladly supply anything else if needed.

Benia’s picture

I could also supply Teamviewer access if someone want to debut it directly on my Ubuntu (PHPstorm already installed).

Benia’s picture

Your take on this will be most appreciated...

alexpott’s picture

@Benia is the node being created when the custom theme is active - i/e the business theme?

The next thing for you to do is to copy your site and try uninstalled each contrib module to work out which one is causing it.

Benia’s picture

Created a backup on Ubuntu, removed all contrib modules. The following happens either when I keep or uninstall the Business theme (flushed all caches afterwards):

I could then add terms to a node from a D7-originated content type and save the node without crashing:

The conclusion is that the problem seems to be contrib-module related (most probably Metatag, which indeed has some problems I have reported).

Though, I still have that problem in which I can't use the selection-box or radio-buttons for term selection (these will jut appear as "none" or "NA".

When I'm inside the edit backend-form, these are the only JS console errors:

Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help http://xhr.spec.whatwg.org/ jquery.min.js:4:14346

Use of getPreventDefault() is deprecated.  Use defaultPrevented instead.

No errors in drush ws --full ...

Any ideas what's going on there before I just pay about 150$ (with much pain) for a programmer to debug this whole SQL charade to finally solve it?

alexpott’s picture

@Benia if you removed each contrib module 1 by 1 then we'd be able to confirm where it is coming from. I agree metatag is likely but *knowing* would mean we could assign this bug report to the correct queue and get you the help you need.

Benia’s picture

I found the source of the autocomplete problem specifically:

After I removed all modules and could add autocomplete terms, I started bringing the modules one after one and to check after adding each module, just as you suggested.

After the first module I brought back --- Search404, the problem came back as well and: adding auto_complete terms crashes the site with the error "The website encountered an unexpected error. Please try again later".

Also the same error from above comes in Drush:

94351 php Drupal\Core\Entity\EntityStorageException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'title' cannot be null: INSERT INTO {node_field_data} (nid, vid, type, langcode, tit error http://benia.biz/node/add/benia_blog 79.180.7.140 12/Aug 13:04

I reproduced what I did on production server and saw that the same things happens there with Search404 so it must be that module that is causing the autocomplete problem.

Though please keep in mind that in any case I can't add terms from selection boxes or radio buttons, in these content types even after removing all contrib modules or themes.

I will now report on Search404 forum but please give me any other advice you have...

Benia’s picture

Published by mistake.

Benia’s picture

You are welcome to offer a solution to another, maybe-associated problem also regarding taxonomy data.

https://www.drupal.org/node/2783423#comment-11511609

swentel’s picture

I know this may sound stupid, but is the title visible on the node form ? If not, that's the problem (see #2111443: Show a warning when configuring form displays when a field is hidden and has no default value. and related). Basically, hiding the title and not setting one programmatically in a different way will crash the site. Can you check on the manage form display of this content type if the title is visible, if not, make the title visible and try again, because looking at search404 I can't see anything that would cause the crash to be honest, so in the end this might not be a taxonomy problem.

Benia’s picture

FileSize
30.8 KB

Hi! Thanks for your answer. As you can see from the attached image (aaa.jpg) it is seen alright in the backend form.

In the link above (#37) I share a milestone in another discussion; Would thank you so much if you'll take a look there in the that discussion and at least tell me what to take from the DB and how and I will paste that there.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

pameeela’s picture

Status: Active » Closed (cannot reproduce)
Issue tags: +Bug Smash Initiative
Related issues: +#2783423: Taxonomy terms not displayed after migration

Thanks for reporting this issue. We rely on issue reports like this one to resolve bugs and improve Drupal core.

As part of the Bug Smash Initiative, we are triaging Drupal core issues with the priority 'Major'.

Since no other users reported this issue, and no updated have been added since 2016 after considerable assistance was provided, I'm going to mark this 'Closed (cannot reproduce)'. I also note that in the other issue, #2783423: Taxonomy terms not displayed after migration, Benia noted in #74 that the issue was resolved.