We're suffering from this exact problem, and I'm hoping to get in a quick fix to stem the bleeding of the data loss. Does anyone have any guidance on how to apply justcaldwell's fix (thank you!!) for existing sites that went with "Option 1" on the install instructions for this project?
For what it's worth, we'd love to have the recent items appear at the top. Our users make a lot of content with the exact same title, and so they are never sure whether they are selecting the right item. Displaying metadata helps, but having the confidence that the top item is the most recent would be a huge user experience improvement for us.
@smustgrave I was wondering if the jQuery selector itself could maybe specify elements without the attributes. We noticed that in some cases the "text-formatted" class cannot be relied on. For example, in webforms.
Thank you for the quick response @roderik! That's helpful. We did do a little debugging at this point in the code:
https://git.drupalcode.org/project/samlauth/-/blob/8.x-3.x/src/SamlServi...
We confirmed that $account_data['name'] was indeed null/empty at that point.
So, this points to some hook_user or entity_presave somewhere else in our custom or contrib code, is that right?
brockfanning → created an issue.
brockfanning → created an issue. See original summary → .
I thought it had been established in #2 that this was a bug - not a feature. I may have confused things because I apparently tried out this module right when the bug started, and so I thought that the bug was intentional. We've ended up using a rather convoluted custom code approach (not using this module), but I would still be very interested in seeing this module work the way it was intended.
Thank you @japerry that's great to know. I had not seen any toggle for edismax in any Search API forms, and in fact I still cannot see them. Is this toggle supposed to appear in the UI anywhere?
I do see this in my config file:
third_party_settings:
acquia_search:
use_edismax: true
So for now I will try changing this to false directly in the config file and report back.
We've noticed already that the selector in #2 can miss certain scenarios, like accordions created in webforms. Probably the ideal code would be for this code to somehow target only those accordions that don't already have the "aria-controls" and "id" attributes that it is adding.
brockfanning → created an issue.
brockfanning → created an issue.
Is the attached patch anything close to what you're looking for here? Or is this about more than just the "direct" parser?
I can definitely follow up with them on this! I can pass long the idea of not forcing edismax internally. Do I understand correctly that if they did not force edismax, that we could potentially continue using "Multiple words"?
brockfanning → created an issue.
Acquia support pointed me to this article, which does seem to resolve the problem: https://acquia.my.site.com/s/article/No-Search-Results-when-stopwords-ar...
In a nutshell, it says to use "Direct query" instead of "Multiple words" for the parser mode.
Since this is specific to the "legacy" option, I'll close this in favor of #3404155.
Actually, this might be specific to a particular setting of the "Navigation (Drupal Toolbar)" in the Gin settings. I'm seeing this problem with "Legacy, Classic Drupal Toolbar", but not with the other settings. So, a workaround might be to use a different option there. I'm still looking into it.
Thanks all for the feedback. I appreciate the help. Unfortunately I'm still am not sure how to resolve the problem. I am perfectly happy to have these stopwords, but I need them to be ignored, rather than actually affecting the query. If the user enters any stopwords at all, 0 results are returned.
I hope that someone else who ran into this might be able to help with some guidance on the correct combination of settings to get around this problem.
brockfanning → created an issue.
I've installed search_api_solr_devel and now I can see the debugging info when I run a search. I thought it would be a little more obvious what I was looking for, but unfortunately I'm being dense. I'm looking for any evidence of my search terms, and I do see them in Solr response body -> responseHeader -> params -> q. If that's the correct place to look, it appears that the stopwords do show up there.
For example if I search for "justice lawyers" then I see this: q => string (21) "+"justice" +"lawyers""
But if I search for "justice and lawyers" then I see this: q => string (28) "+"justice" +"and" +"lawyers""
As for the Solr configuration, I unsure of what I'm looking for there too. On /admin/config/search/search-api/server/[my server name]/solr_field_type I clicked on "Get schema_extra_types.xml" and I see a file with a long list of elements, which mostly appear to be specific to languages (our site is multilingual). The first example is:
<dynamicField name="ts_X3b_ar_*" type="text_ar" stored="true" indexed="true" multiValued="false" termVectors="true" omitNorms="false" />
I gather that I need to compare the name attribute "ts_X3b_ar_*" with something else in another file, but I'm stumped on where to look next.
Thanks so much for the reply! We use Acquia for hosting, and we're experiencing this with one of the built-in "configsets", which is described as: "(Latest) Drupal 9 / 10 - Search API Solr 4.3.2 - Solr 8 - [drupal-4.3.2-solr-8.x-0] - v1.0"
As for module versions, we're using Search API 1.3.1, and Search API Solr 4.3.2.
It's very helpful to know how it should behave, thank you. I will go ahead with your recommendation of trying to see the request that is sent to Solr (I'm not sure offhand how to do that on Acquia hosting but I will research). In the meantime, if you have any prior experience with Acquia's configsets and know of any gotchas, please let me know. I can download the config set so if there is anything in there I should paste here, I can.
Finally in regards to custom code - I tried creating a brand new view which would not have been affected by our custom code (our custom code is tied to a specific view id) and still experienced the problem, so I think we can rule out our custom code as a culprit.
brockfanning → created an issue.
brockfanning → created an issue.
I finally got around to fixing this, and the composer require --no-update oomphinc/composer-installers-extender:^2 command worked perfectly. Thank you!
brockfanning → created an issue.
This feature would be very useful. Our users want inline to be the default. I think the patch is a step in the right direction, but it really needs a config form.
brockfanning → created an issue.
I was also suffering from the "SP private key not found" error, when trying to run my automated tests in a CI environment where the key files don't exist (Github Actions in our case).
In my case, luckily I am able to "drush pmu samlauth" before running the automated tests, so that's the workaround I'm using for now. However I could understand how that would be impossible in the situation that @jwilson3 describes.
brockfanning → created an issue.
I think I figured it out - we needed to uninstall the simplesamlphp_auth module (duh...). The clue was that the path "saml_login" has nothing to do with this module.
Sorry for the noise!
Thank you for all the clarification! I think my biggest missing link was the fact that simplesamlphp was actually a Service Provider. Also, I had no idea that simplesamlphp had a key/certificate. Anyway, thanks again, I will mark this as resolved.
brockfanning → created an issue.
Also, I realized that since our repo is public I can point you directly to our simplesamlphp config files, in case this is helpful: https://github.com/usdoj/foia-api/tree/8.1.0/simplesamlphp
Sorry, I should have read up a bit more before posting. I'll read through these links. In the meantime here is some more info about my question:
My goal is to be able to log into the Drupal site using our IdP. We're currently doing this with simplesamlphp_auth, but we're upgrading to Drupal 10 and need to replace this set up. In practice here is our workflow, from the user's perspective:
1. User goes to /user of the Drupal
2. User clicks a "Federated login" link
3. User is redirected to a separate domain to complete the login process according to the IdP
4. User is redirected back to /user but is now logged in
As mentioned, we're currently doing this with simplesamlphp_auth, and we have the relevant bits from the IdP entered into simplesamlphp configuration files.
My first attempt at migrating to samlauth was to take all of the metadata from our simplesamlphp config files and try to enter it into the samlauth admin form. However all of the stuff under "Service Provider" seems to be new (for us at least).
Maybe this specific question might help me understand - in order to achieve the workflow described above, will I need to create a keypair?
Thanks all for the responses, I really appreciate the support.
brockfanning → created an issue.
@andriy-khomych We would be interested in using that patch, however we have a need to apply a query alteration to only one particular sitemap, while leaving other sitemaps unaffected. Would it make sense to add another parameter to the hook that would let implementers only apply the alteration to certain sitemaps?
brockfanning → created an issue.
@smustgrave - Does that explanation make sense? If so, then the null values are to be expected, and I think the patch is good as it is.
That's a good point. My thinking was that that code actually runs whenever you right click on something, anywhere in the editor. So, it works fine when you right click on an accordion. But if you right click on something else (like a table) then those getAscendant calls return "null" and the hasClass calls produce a JS error (since you can't call .hasClass of null).
brockfanning → created an issue.
Thanks very much! Sorry I never got back to you on this.
We are trying out patch #41 as well, and so far it seems to be working. I'll definitely follow up if any issues come up. Thank you so much!
brockfanning → created an issue.