After I've upgraded the module from alpha10 release to alpha11 I'm no more able to index content.
When I start to reindex I always get this message: "Couldn't index items. Check the logs for details."
But there are no log to se in watchdog. No one in apache2 error.log too.
In order to investigate possible causes I tried to enable and run the search_api_db_defaults module and also with this default module I was not able to index content and I get the same message: "Couldn't index items. Check the logs for details." but none logs.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 2642704-7--indexing_und_entities.patch | 1.92 KB | drunken monkey |
Comments
Comment #2
swentel commentedThere's a possibility you have to check your fields configuration of the index - or maybe even delete the index and start over again.
Also, #2642534: processors shouldn't be unset in Index::__sleep, processorPlugins should be needs to get in as well as most of the indexing is currently broken anyway.
Comment #3
emanuelrighetto commentedI made another test: I tried to bulk updating all the nodes setting the language code as "en". Before the langcode was set to "und".
Then I tried to reindex content. After setting the right langcode reindexing works like a charme.
It's a bug or just isolated scenario?
Comment #4
drunken monkeyLike swentel says, I would first have guessed that the fields configuration of your index was destroyed by #2574969: Add a Views-like UI for adding fields. However, the Database Search Defaults module should of course still have correct configuration.
But if reindexing works after changing the node language, maybe it's just an obscure problem in that part. As far as I'm aware, Core has now for quite some time created new nodes always with a valid language, never with
und, even on single-language sites. If this was not the case for you, maybe you have the site already running for some time, and that might confuse some internal system of either Core or the Search API. I'd therefore just guess "isolated scenario" here, unless you can reproduce the bug from a clean site install.I just tested from a clean install again, just to be sure, and indexing worked fine. (It seems we don't currently test actual indexing or searching with the Database Search Defaults module in our test suite, that's why I wasn't completely sure there.)
Comment #5
emanuelrighetto commented@Thomas you are right: on a clean installation nodes always have got the correct value for langcode setted.
The problem is that most of my nodes went from a D6 migration where lang was "und".
By the way the first thing I've checked was that field correctly set after first reindex failure and those fields were ok.
So we can say that if node->langcode = "und" broke reindex process.
Comment #6
drunken monkeyHm, OK, then maybe create a Core issue for the D6 migration code? (That's in Core, right?) Seems to me if nodes now always have a valid language, this should also be the case for migrated ones.
In any case, though, I guess we should still search for what causes this problem – it might still be a bug in the Search API itself, and it might still be triggered by other items that might not have any language.
Would be great if someone else could verify this problem exists and try to pinpoint where this fails.
Do you have strict error reporting enabled on your server? If not, maybe doing that would lead (or would have lead) to the underlying issue.
Comment #7
drunken monkeyJust came across this myself, via #2645968: Generated taxonomy terms have langcode "und".
I'm still not sure we should have to fix this, since I still think entities should always have a "real" langcode set, but on the other hand I came up with a very easy workaround (see the attached patch). So I guess just applying that workaround to our code can't do any harm.
We should also properly log items that could not be loaded, so the "Check the logs for details" message gets a bit less frustrating and more helpful.
#2574589: Move the "remove unloadable items from tracking" logic to the index would be another issue related to this, though it wouldn't help much here – it would just remove all the items that couldn't be loaded from tracking. Might be helpful in seeing more clearly what's going on, though.
Comment #8
emanuelrighetto commented2642704-7--indexing_und_entities.patch works fine.
I took the old migrated db dump coming from D6 with node langcode "und". Before apply the patch I can't reindex. After applying reindex had no problem.
Comment #9
borisson_Confirmation by @emanuelrighetto is great, the code also looks good and the tests pass. rtbc!
Comment #11
drunken monkeyGreat to hear, thanks for testing/reviewing!
Committed.
Comment #13
jnimchuk commentedI'm also migrated from Drupal 6 to 8. Is the "und" langcode still an issue?
Content and Content types that migrated from 6 are not displaying in the search results. Content and Content types that I created natively in Drupal 8 work just fine. The difference seems to be "und," because newly created content uses "en" for the langcode.
It does seem like everything was working in an earlier release of Search_API, but it's not working now.
Any idea how to fix?
John N.