I was having this problem just now. The culprit was a full root partition on the VM that runs our solr server. For some reason, the log had grown to an unbelievable size. After removing it, everything works as expected again.
I just tried following the instructions in the README.md file with my site, Drupal 10.3.0 running locally with DDEV. When I tried ddev drush --numShards=1 search-api-solr:upload-configset dll_catalog
, as recommended in the documentation, I received the following error:
Command "search-api-solr:upload-configset" is not defined.
Did you mean one of these?
search-api-clear
search-api-disable
search-api-enable
search-api-index
search-api-list
search-api-search
search-api-solr-delete-and-reinstall-all-field-types
search-api-solr-get-server-config
search-api-solr-multilingual-delete-and-reinstall-all-field-types
search-api-solr-multilingual-get-server-config
search-api-solr:execute-raw-streaming-expression
search-api-solr:finalize-index
search-api-solr:get-server-config
search-api-solr:install-missing-fieldtypes
search-api-solr:reinstall-fieldtypes
search-api-status
search-api:clear
search-api:disable
search-api:disable-all
search-api:enable
search-api:enable-all
search-api:index
search-api:list
search-api:rebuild-tracker
search-api:reset-tracker
search-api:search
search-api:server-clear
search-api:server-disable
search-api:server-enable
search-api:server-list
search-api:set-index-server
search-api:status
I tried ddev drush --numShards=1 search-api-solr-get-server-config dll_catalog
and found that the "--numShards" option does not exist.
sjhuskey β created an issue.
I'm positing this here in case anyone just wants the status messages to be color-coded and minimally themed.
The quick fix (and one I can live with) is to copy the content of web/core/themes/starter_kit/css/components/messages.css
into your custom theme. I also had to uncheck the "Aggregate CSS files" and "Aggregate JavaScript files" at admin/config/development/performance
, save, clear caches, then recheck the boxes and save again before the changes took effect.
Forgive me for being dim, but the issue cited by #41 π Fix access checks for bundle permissions to avoid triggering a config validation error Fixed has to do with Drupal core 11.x-dev, doesn't it? Those who have posted earlier in this thread have been concerned about 10.3 and previous versions.
I implemented the custom module solution as suggested by #30 π Fix access checks for bundle permissions to avoid triggering a config validation error Fixed on my 10.3 site. It seems to have resolved the issue.
I'm sorry for reopening this, but I could use some clarification before I create a bunch of work for myself. I have a collection with four indexes, each customized in its own way. If I delete the collection as recommended, do I need to redo all of those customizations? I just want to be sure to budget my time appropriately before I start breaking things.
I did a test without deleting the collection. I created some new content and queued everything for reindexing. The reindexing was successful without the error mentioned here.
Drupal Field: Added hint to use node.id
if the template is for multiple nodes.