Closed (works as designed)
Project:
Drupal core
Version:
8.8.x-dev
Component:
entity system
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
19 Mar 2017 at 00:00 UTC
Updated:
14 May 2020 at 22:00 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
cilefen commentedWhat do you mean by a "static page"?
Comment #3
liam mcdermott commentedI'm hitting this issue too when upgrading from 8.2.7 -> 8.3.0. Not sure what's meant by 'static page' in this context, in our case the error is occurring on the site front page, which is of the 'Basic page' content type (and also has some blocks on it).
Comment #4
cilefen commented@Liam McDermott Have you got those same modules installed as the original reporter?
Comment #5
liam mcdermott commentedNo, none of those are installed on the site in question. However, I fixed this issue by running
drush updatedb, I'm assuming the cause of this is not running DB updates, so anyone else getting this error after upgrading should try running database updates.I'm closing this for now, but I may be wrong so please re-open it if anyone is still experiencing this issue.
Comment #6
xjmReopening this and bumping to critical since it was also reported in #2867253: Upgrade to 8.3.0: Call to a member function get() on array in CacheCollector.php . In multiple different issues, users have reported running database updates a number of times resolved their issues (in some cases with different fatals reported), so that is worth attempting if anyone else encounters this. Anyone encountering this should also ensure they are on Drush 8.1.10 before running updates since earlier versions of Drush also include bugs with update ordering.
Comment #7
xjmComment #8
xjm@pick_d reported in #2867253: Upgrade to 8.3.0: Call to a member function get() on array in CacheCollector.php , when updating from 8.2.7 to 8.3.0:
Comment #9
xjmIs everyone getting this using a multilingual configuration? Or a language other than English?
Comment #10
xjmComment #11
xjmLooked for other issues with this error in other situations to figure out if such an error could be caused by a problem with entity updates or data integrity, found:
Comment #13
xjmAlso @pick_d, it looks like the last fatals are about AMP code being missing when that was uninstalled. I wonder if that is something else gone wrong.
Comment #14
alexpottThe worrying thing here is that we've somehow got to \Drupal\Core\Entity\ContentEntityBase::getTranslatedField() with no field name. That is very strange.
So we don't even know which field is causing the problem.
Comment #15
alexpottBacktraces here made me looked at the AMP module - I discovered #2867636: amp_update_8002() should be a post update about one of the updates that AMP has. Theoretically that might cause the field data to get out of sync. However only 1 person is confirmed to be or have used the AMP module.
Comment #16
alexpott#2867636: amp_update_8002() should be a post update is possibly related. Not at all confirmed but calling \Drupal::entityDefinitionUpdateManager()->applyUpdates(); inside hook_update_N is not supported and could corrupt entity info.
Comment #17
pick_d commentedThat's weird because last one was from fresh backup (I restored both mysql DB and files) and I haven't uninstalled AMP on this setup.
Also my "experiment" with uninstalling AMP before upgrade to 8.3.0 was made on another web-server, so the log related to "amp stuff not found" is totally strange to me.
I'll try to apply patch #3 from here: https://www.drupal.org/node/2867636
Let's see if that changes anything.
UPD: nope. didn't change anything for me.
I applied the patch by downloading into modules/amp/ with patch -p1 < 2867636-3.patch
Log is exactly the same with:
[Fri Apr 07 11:38:19 2017] [error] [client 193.105.134.166] PHP Fatal error: Class 'Lullabot\\AMP\\AMP' not found in /home/u5712/domains/mydomainname.info/modules/amp/src/Service/AMPService.php on line 54, referer: http://mydomainname/update.php/resultsMy site is using RU locale and language. Might be the case?
@alexpott noted ::getTranslatedField()
I changed system language via UI to English language and updated translations manually via UI.
It caused few updates including drupal core and amp translations (screenshot attached).
But in the end I got same result and same log as above.
Comment #18
pick_d commentedI tried to totally remove AMP on this setup.
Uninstalled via UI, removed modules/amp directory, update DB
And it worked even with drush 8.0.2.
Which means that my issue was related to some kind of error within AMP module.
Comment #19
alexpott@pick_d well the error
Class 'Lullabot\\AMP\\AMP' not foundimplies that the AMP library (which is required by the module) has not been found. Which means for whatever reason your autoloader can't load it. The mostly likely reason is that you don't have vendor/lullabot/amp and somehow you have removed the dependency before uninstalling the module.EDIT: It is possible that you removed the dependency whilst following the update instructions since this dependency is not part of the core.
Comment #20
pick_d commentedI checked now and it doesn't look like that:
ls backup-8.2.7/vendor/lullabot/amp/
amp-console composer.json LICENSE.txt phpunit.xml README.md sample-html src tests
ls live-site-8.3.0/vendor/lullabot/amp/
amp-console composer.json LICENSE.txt phpunit.xml README.md sample-html src tests
(AMP is reinstalled here after upgrading to 8.3.0)
Comment #21
catch@Liam can you confirm you only got this due to not running updates at all? Or that you had to run updates twice?
Comment #22
alexpott@pick_d then my other guess is that somehow vendor/composer/autoload_psr4.php got replaced with the one from the core which doesn't have the map for lullabot\amp classes.
Comment #23
pick_d commented@alexpott
well, probably.
I don't really understand things in Drupal, just trying to maintain my websites, but I'll try to provide all info that could help to catch and/or fix those nasty bugs.
Comment #24
alexpott@pick_d your reports of the issues you've faced are really appreciated. Thank you.
Comment #25
alexpottDiscussed with @catch, @Cottser, @effulgentsia, and @xjm. We really need more information to determine the cause of the exception. Maybe we should create an issue add some instrumentation or an earlier exception somewhere to make the error easier to work out.
@pick_d did you manage to resolve your AMP module issues - there are a number or bugs about re-installing the module - see #2867733: Make the Amp module re-installable - these have been fixed recently.
Comment #26
berdirThe exception message is actually Field X is unknown as pointed out in #14 alreada and it is likely that the reports are all kinds of different problems but I don't think they are core problems. Basically, someone is calling $entity->get(''), possibly due to changed configuration, missing update functions or all kinds of other issues.
I don't think this is something that can be "solved" in core and is not a critical bug *in core* (or at least not in the entity system), but leaving at that for now.
As I think has been pointed out before, the best you can do is enable verbose error logging, check the first module that shows up in the stack trace (Drupal\x\... where X is not Core and report a bug there). And if that module happens to be a core module, then update this issue.
Comment #27
SchwebDesign commentedThis happened to us as well. In our case, this was caused simply by neglecting to run update.php. We had to manually navigate to /update.php, run the updates, and all was well.
Comment #28
guzabi commentedI'm new to Drupal and I can't believe my eyes : critical bug, blocking, reproductible, recurrent acrosse 8.3.x versions, open for over a month and not even attributed to someone? I'm sorry but this can't happen. I can't solve the problem by editing the fields in the content type because there also is an exception when editing fields for a content type :
Uncaught PHP Exception Drupal\Core\Entity\Exception\UnsupportedEntityTypeDefinitionException: "The entity type node does not have a "xxx" entity key." at /core/lib/Drupal/Core/Entity/EntityPublishedTrait.php line 32
After doing that, even the "manage fields" page throws the same exception.
I'l try again using Drupal when it works.
Comment #29
alexpott@guzabi do you have outstanding updates? @SchwebDesign solved it by going to EXAMPLE.COM/update.php and running the updates. The error you are getting is because node_update_8301() has not run.
Comment #30
catch@guzabi
In general core issues don't get assigned to a single individual, because that discourages other people from working on it. This issue has several regular Drupal core maintainers contributing to it including four core committers, several of whom have asked people running into the problem to provide more information. If you're able to answer @alexpott's question in #29 that would help to resolve this issue quicker.
Comment #31
alexpottHere's idea for helping users find there way to update.php #2877643: Redirect to update.php if \Drupal::version() different from container version
Comment #32
drzraf commentedSame error starting migration with 8.3.x
Comment #33
drzraf commentedAlthough I got this message printed thousands of times, I can provide 0 information to this "need info" issue.
I tragically misses a function stack trace (+ arguments). At least add $langcode to the message, maybe log somewhere
$this->fieldsand$definitionor use the migrate-message table to keep track of the errors ?Comment #34
drzraf commentedGot it.
In my case it has to do with one these two tables:
path_redirectorurl_aliasThey contain entries like :
INSERT INTO `path_redirect` VALUES (1305,'categories-faq/FOO/feed','taxonomy/term/483/0/feed','','','',301,1470068425);or
INSERT INTO `url_alias` VALUES (14617,'taxonomy/term/587','categories-faq/BAR','');where "categories-faq" is not a known content type or anything like that (no other occurence of the "categories.*faq" pattern in the DB dump)
That is sufficient to trigger:
Which bug is it a duplicate for?
Comment #35
berdirYour errors are different (you actually have a field name that does not exist) and you have a lot of errors above that, so those are follow-up errors after it likely failed to create taxonomy bundles, fields and so on earlier. If this is the default migration then I would suggest you open an issue about that. If you can, provide the source data so that it can be reproduced, I suspect it will be hard to do that without any data. And you should try to restart the whole migration process on a clean site and provide the first errors you get, because that's likely where it started to go wrong.
Comment #36
begrafx commentedI encountered this error message (Drupal 8.3.2) I don't have any of the modules that were mentioned at the top of the thread, but, someone above suggested running Drush Update. I didn't have Drush on this site, but just running UPDATE.PHP seems to have resolved the issue.
Comment #37
cilefen commentedExecuting update.php is a step in the update instructions.
Comment #38
mrweiner commentedI can confirm that in my case, I was able to fix my problem by updating to the latest version of the AMP module and running
drush updatedbsince the update page was inaccessible. If you are using composer.json to manage your modules, make sure you change the minimum version to dev.Comment #39
begrafx commentedCilefen,
I'm not arguing that point. I'm simply saying, I manually ran UPDATE.PHP and it appears to have resolved the problem.
Comment #40
netnerd85 commentedAny call to a field on a node entity such as $e->get('body') should be wrap in if($e->hasField('body'))
The other stated solutions did not work for me.
Comment #42
skorasaurus commentedI do not have any other languages besides English installed and hit this error when I upgraded my site from 8.2.8 to 8.3.6. I do not have AMP installed; here's a list of my installed modules.
I was able to fix this by visiting mysite/update.php
Comment #43
mingsongHi skorasaurus,
Yes, good point. According to the Drupal 8 update manual, we need to run the update.php
Comment #44
edysmpdrush updbdidn't work for me, It was necessary/update.phpComment #46
ahebrank commentedIf it helps anyone arriving from a search, xdebug reveals Geocoder as the culprit behind this error for me, running $entity->get(NULL) because of what looks like a config mapping change.
For core folks, could ContentEntityBase's getFieldDefinition throw an exception (with stack trace!) if it gets an empty $name?
Comment #47
agoradesign commented@ahebrank
for anyone having this problem due to Geocoder: have a look at #2936857-15: Update to latest-dev fails because of missing config schema update process and the issue referenced in that comment
Comment #48
swentel commentedThis suddenly started to popup on 8.5.2 while building a site.
It's a multilingual setutp. Some fields were made in dutch, so their language is 'nl'. Changing that didn't help or so, still fatal errors.
If I add a return before the InvalidArgumentException all is fine, even more interesting, when going to the node/add page, the field is available and I can save the node.
There's a couple of contrib modules, but most of them are so widely adopted and tested that it's hard to figure out what goes on here.
Pointers to debug appreciated, I'm willing to digg deeper.
Comment #49
kate_raquel commentedIt also happens to me. But it tells me that it is the "comment" field that does not find
"InvalidArgumentException: Field comment is unknown"
Comment #50
vagelis-prokopiou commentedI happened to me too.
Uncaught PHP Exception InvalidArgumentException: "Field comment is unknown." at .../core/lib/Drupal/Core/Entity/ContentEntityBase.php line 580It happens when I try to create a new Article in a Drupal 8.5.3 multilingual setup.
It happened even though I deleted and re-created the article content type.
Comment #51
berdirTo be clear, this exception by itself is *not* a bug. That's exactly what should happen if other code is calling it incorrectly.
In general, before accessing a field with $entity->get('my_field'), you should always check first with $entity->hasField('my_field') (or through the bundle, but in general, I recommend the hasField() approach).
Then, there are at least two different cases here.
This issue is about "Field *nothing* is unknown". This happens when you call $entity->get('') or $entity->get(NULL). Obviously that doesn't make sense. Typically this happens when the field name is stored in configuration and that configuration is missing. For example, you can get that error when updating to 8.5 and you either didn't run updates or block_content_8400() failed to run (there are some known issues with it that should by fixed now but not yet relesed).
Then there is the other message that is "Field *a_field_name* is unknown". This happens when you for example call $entity->get('comment') on a node type that doesn't have a comment field. IMHO, core should not be doing that unless something is very messed up in the field map or so. It's more likely that this is a custom or contrib module or theme.
The best way to figure out what is actually going on is to enable verbose error logging including backtrace and then trigger the error. That should tell you *who* is calling $entity->get() with the incorrect argument. Then inspect that module. If you're not sure what to do about that, post the output of that here.
If you can't do that for some reason (e.g. it only happens rarely or on production), you could try https://www.drupal.org/project/past, one of its goals is to provide better error logging in case of exceptions and fatal errors. Make sure you test that first before adding it to your production site.
If you see that the call is coming from a contrib module that you are using, then I suggest you create a issue there and possibly reference it here. You can also ask on Drupal Answers if you can see that it is coming from custom modules/themes and share your code there.
As mentioned before, I don't see how we could improve something in core, someone is giving this method invalid input and we have to assume that not throwing an exception would result in a way less helpful fatal error.
@swentel: Feel free to ping me somewhere if you still have problems.
Comment #52
swentel commented@berdir already found it - stupid error on my side using a custom field item class :(
So no problems for me anymore at this point (never saw the other ones either)
Comment #53
alexpott@Berdir as
is the case do you think we should recommend this in the error? People seem to be hitting this regularly so it'd be good to help people as much as possible.
Comment #54
berdir> is the case do you think we should recommend this in the error? People seem to be hitting this regularly so it'd be good to help people as much as possible.
Possibly, yes? But is this error really special about that? IMHO, you should *always* do that in case of an error/exception if it is not clear where it is coming from. So maybe we should always suggest to display errors/check log (when display errors is off) and suggest to check the verbose error when the error is displayed without. Not sure about adding it just to this? I've seen dozens of questions on Drupal answers that were basically "My site displays 500 Service unavailable, what's broken?", which obviously is impossible to answer.
Comment #55
plachFWIW I completely agree with #54: a documentation page to explain how to troubleshoot a WSOD and/or an exception would be a very helpful resource we can quickly point people to from issues like this one.
Comment #56
berdirFound https://www.drupal.org/node/158043 and https://www.drupal.org/node/482956 as related existing pages, but they're both set to Drupal 7.
Comment #57
vagelis-prokopiou commentedIndeed, in my case it was a contrib theme.
Thanx Berdir for the insight.
Comment #58
aiglesiasn commentedThanks vagelis-prokopiou, that worked for me for another Content Type.
Comment #60
mikemadison commentedI really think this error is legit and, as @vagelis-prokopiou pointed out is an indication that "something" isn't properly using the Drupal API. It maybe makes sense to provide a more useful error message?
In my case I was using a ->get on a field that didn't exist without doing a ->has first (exactly as @vagelis-prokopiou) suggested. I think we can close this as works as designed personally...
Comment #61
Orion76 commentedI apologize for my English, I google translate help-)
Faced with a similar error.
I had a problem in custom ContentEntity (generated using the drupal console)
I have redefined the ContentEntity constructor.
When adding a constructor, I used the IDE (PHPStorm) function to insert the "parent" method.
Since in the parent constructor, the default value for the $bundle parameter is FALSE, then the IDE inserted the type of the $bundle variable: bool:
Therefore, if $bundle! == FALSE (as well as the type of the entity (string)), then the value of $bundle is converted to TRUE.
and the ContentEntityBase method:
does not "find" field definitions for $this->bundle(), because $this->bundle () === TRUE
Comment #62
Orion76 commentedapologize for my English, I google translate help-)
Faced with a similar error.
I had a problem in custom ContentEntity (generated using the drupal console)
I have redefined the ContentEntity constructor.
When adding a constructor, I used the IDE (PHPStorm) function to insert the "parent" method.
Since in the parent constructor, the default value for the $bundle parameter is FALSE, then the IDE inserted the type of the $bundle variable: bool:
Therefore, if $bundle! == FALSE (equal to the type of the entity (string)), then the value of $bundle is converted to TRUE
and the ContentEntityBase method:
does not "find" field definitions for $this->bundle(), because $this->bundle() === TRUE
Comment #63
mcdeltat commentedI would like some advice or to have this looked at again. We have a client with a site on 8.4.4 that we were trying to mass update to 8.6.1. On my dev environment I had to jump through probably 6 major hoops of updating modules, patches that somehow aren't in their main branch a year later, etc. Finally, I'm stuck on this bug. Notably, I ran into this bug where the command
drush updbfailed midway. I resolved that and finally got to a point where it would get though updb. So running update.php in the front or through drush says that there are no updates, but I wouldn't know where to look for what module might be calling get() as noted in #51I honest might have to pull the site from live again and try for the fourth time over 3 weeks to get the update to stick. It's bad. Here's the report from the page that is failing? Is there anything else I can look for on my end?
The website encountered an unexpected error. Please try again later.InvalidArgumentException: Field field_basic_category is unknown. in Drupal\Core\Entity\ContentEntityBase->getTranslatedField() (line 586 of core/lib/Drupal/Core/Entity/ContentEntityBase.php).
Drupal\Core\Entity\ContentEntityBase->get('field_basic_category') (Line: 42) tahoe_preprocess_page(Array, 'page', Array) (Line: 287) Drupal\Core\Theme\ThemeManager->render('page', Array) (Line: 437) Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195) Drupal\Core\Render\Renderer->render(Array) (Line: 490) Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 99) __TwigTemplate_3a215e081fb03b7d7188c309d1c8734cb9624132f855550f7cac0b1b8bc7fd13->doDisplay(Array, Array) (Line: 432) Twig_Template->displayWithErrorHandling(Array, Array) (Line: 403) Twig_Template->display(Array) (Line: 411) Twig_Template->render(Array) (Line: 64) twig_render_template('themes/tahoe/templates/html.html.twig', Array) (Line: 384) Drupal\Core\Theme\ThemeManager->render('html', Array) (Line: 437) Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195) Drupal\Core\Render\Renderer->render(Array) (Line: 147) Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 582) Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 148) 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: 52) Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23) Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 669) Drupal\Core\DrupalKernel->handle(Object) (Line: 24)Comment #64
vagelis-prokopiou commented@mcdeltat the stack trace makes a reference to
twig_render_template('themes/tahoe/templates/html.html.twig', Array)This is a custom themes's template. Possibly a call to this field exists in there.
Comment #65
stephenplatz commentedThis is also affecting my application, Drupal version 8.7.2. In this case, the error is being thrown when I use
in the build() function in a custom plugin.
Comment #66
dqdShoud we move on ? And it seems to appear in connection with Layout Builder issues too: https://www.drupal.org/project/drupal/issues/2980299
Comment #67
berdirMove on to what? There is no bug here, the bugs are in the calling code. #65 for example is not valid, get() *must* be called with a field name that exists on that entity, you can't mix it with ??, you need to use hasField() ? get()->value : NULL
#53 suggested improving the message and mentioning the backtrace, but per #54, that is true for every error message that you get. IMHO this should be closed, maybe someone could collect some examples and document how to improve it (like the one above) and create a documentation page that people find.
Comment #68
dqd@Berdir, I absolutely agree ... "moving on" was just the wrong phrase by accident. English is not my native tongue. I was asking if we need to set version from 8.6 to 8.8.x or 8.9.x since this is the actual working tree. That's what I was referring to and what I meant with "moving on" (think of moving the number some steps up). :) Sorry for the confusion.
This! +1
Comment #69
catchGoing to close as 'works as designed'.
Comment #70
dqdYes. I think its best to leave it closed. The particular core components and contrib projects causing this error should create their own individual issue reports regarding this error. Finally we maybe shoud post a summary somewhere since it seems all kind of related to a near-by similar wrong call or reset somewhere ignoring some optional and possible multi-language parts in the system?
Comment #71
ashDn999 commented@netnerd85 Your comment (Comment#40) Helped me. Thank you! I spent a full day trying to fix this.