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?
Comment | File | Size | Author |
---|---|---|---|
#39 | aaa.JPG | 30.8 KB | Benia |
Can't choose tags.JPG | 14.25 KB | Benia | |
Vocabulary already chosen.png | 9.9 KB | Benia |
Comments
Comment #2
Benia CreditAttribution: Benia commentedComment #3
Benia CreditAttribution: Benia commentedComment #4
alexpott@Benia can you provide a full error. The error should have the key name. And if possible a backtrace?
Comment #5
Benia CreditAttribution: Benia commentedPasted the full longer version.
Comment #6
Benia CreditAttribution: Benia commentedComment #7
Benia CreditAttribution: Benia commentedComment #8
Benia CreditAttribution: Benia commentedComment #9
Benia CreditAttribution: Benia commentedComment #10
alexpott@Benia can you do
drush ws --full
Comment #11
alexpottAlso 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.
Comment #12
Benia CreditAttribution: Benia commentedComment #13
Benia CreditAttribution: Benia commentedI 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 ...
Comment #14
Benia CreditAttribution: Benia commentedComment #15
Benia CreditAttribution: Benia commentedComment #16
cilefen CreditAttribution: cilefen commented68877 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.
Comment #17
cilefen CreditAttribution: cilefen commentedRe #13, #11 explains how to create a backtrace. There is no IDE involved.
Comment #18
Benia CreditAttribution: Benia commentedHere 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.
Comment #19
Benia CreditAttribution: Benia commentedComment #20
Benia CreditAttribution: Benia commentedAny advice?
Comment #21
Benia CreditAttribution: Benia commentedComment #22
alexpottIt 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.
Comment #23
Benia CreditAttribution: Benia commentedNo 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:
Comment #24
cilefen CreditAttribution: cilefen commentedRe #22, Alex is referring to admin/config/development/configuration/single/export to export a configuration.
Comment #25
Benia CreditAttribution: Benia commentedSimple configuration:
All is zero besides:
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:
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):
Comment #26
alexpott@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.
Comment #27
alexpottAlso can you create nodes of the type benia_blog without terms?
Comment #28
Benia CreditAttribution: Benia commentedYes, 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?
Comment #29
Benia CreditAttribution: Benia commentedWill gladly supply anything else if needed.
Comment #30
Benia CreditAttribution: Benia commentedI could also supply Teamviewer access if someone want to debut it directly on my Ubuntu (PHPstorm already installed).
Comment #31
Benia CreditAttribution: Benia commentedYour take on this will be most appreciated...
Comment #32
alexpott@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.
Comment #33
Benia CreditAttribution: Benia commentedCreated 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:
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?
Comment #34
alexpott@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.
Comment #35
Benia CreditAttribution: Benia commentedI 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...
Comment #36
Benia CreditAttribution: Benia commentedPublished by mistake.
Comment #37
Benia CreditAttribution: Benia commentedYou are welcome to offer a solution to another, maybe-associated problem also regarding taxonomy data.
https://www.drupal.org/node/2783423#comment-11511609
Comment #38
swentel CreditAttribution: swentel commentedI 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.
Comment #39
Benia CreditAttribution: Benia commentedHi! 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.
Comment #47
pameeela CreditAttribution: pameeela commentedThanks 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.