Hi everyone,
I started to face this issue with a Solr server on Pantheon. The search view started to present some errors, for example, the header was showing "Listing 1-16 of 44 result(s)" - but in fact, it was listing 12 items (not 16). Another issue was that I typed a random string (knowing this should result in an empty response message), but I still got the header showing a random results number.
Then, I saw the error in the logs and found this thread. The comment #16 π The datasource with ID ... could not be retrieved for index Fixed fixed the issue.
Hi everyone,
This morning I faced this issues. By applying the MR patch, I was able to run drush updb properly! Great work!
Hi!
I'm using this with Gin, and I found that the Light version was odd, so I fixed some of that. I also added a check to include a gin.css file to work with Gin's accent colors. I'm submitting the patch and I pushed the code to the branch 1.2.x branch in the issue fork.
cassioalmeida β made their first commit to this issueβs fork.
Hi,
This is a great improvement! I did a test with a website with 4 roles and some modules. The permissions table has 535 rows.
The results are:
Before: 91.7ms
After: 1.7ms
Hopefully this will be merge as soon as possible.
Hi everyone,
I was facing the issue with an Azure instance with the sql_generate_invisible_primpary_key ON. As the client has 300+ websites, turning off the flag was not an option.
I can confirm the MR worked fine! I was able to run pending tasks, re-index content, and so on.
cassioalmeida β created an issue.
Based on the last comments, it seems this is not related to Layout Builder but a combination of it with other modules, such as Layout Builder Modal.
If this is the case, I'd recommend closing this issue.
You're welcome!
Just tag me if you need anything else.
Hey, sorry for the delay and thanks for the comment.
I'll work on that later today.
Thanks for the explanation.
This is the wrong statement. use Radio Buttons and set the field value to empty as many times as you want, not only once.
That statement was about the EmailItem and some other classes under the namespace Drupal\Core\Field\Plugin\Field\FieldType;
I did the following test β a CT with two fields. Email and Boolean (checkbox widget).
Then I created a node and left both fields without filling them out.
Then, on a node preprocess, I created the following example:
//Boolean field
$node->get('field_featured')->isEmpty();
//Email field
$node->get('field_email')->isEmpty();
The result of calling isEmpty on the Email field changes every time I update the node. If I save the node with some value in the Email field, the isEmpty result is false; if I update the node and leave the field without any value, the result of isEmpty is true. So, in that case, I can "trust" the isEmpty method to check against the value.
Probably that was the motivation to create the issue. By using the Radio widget as an example, it does make sense. But this thread can clarify for anyone in the future looking for why it "does not work" for Boolean fields.
I closed the MR until I didn't have the time to work on a complete solution.
That said, I don't believe that passing the responsibility of knowing the underline implementation of a method called isEmpty will return true only once for the Boolean field, a good thing.
Mainly because it's not the same behavior for other field types, although they share the same interface.
The interface docs mention the expected results:
Drupal\Core\TypedData\ComplexDataInterface
/**
* Determines whether the data structure is empty.
*
* @return bool
* TRUE if the data structure is empty, FALSE otherwise.
*/
public function isEmpty();
Beyond that, we have a "field-especific method" - we can see it on other field types. For example:
Drupal\Core\Field\Plugin\Field\FieldType\EmailItem
overwrites the isEmpty method and checks for the value:
Drupal\Core\Field\Plugin\Field\FieldType\EntityReferenceItem
also does it.
Drupal\Core\Field\Plugin\Field\FieldType\StringItemBase
and Drupal\Core\Field\Plugin\Field\FieldType\UriItem
too.
No matter how many times you edit a node, all those fields, if the field value is empty, the method isEmpty return true; if not, false.
The goal is to:
1-) Avoid custom code to check if the field is empty by accessing its value.
2-) Expect the exact behavior of fields that implements the interface.