🇺🇸United States @brockfanning

Just following up - in practice it seems like the syntax is indeed like what I posted above:

<a id>

But it seems the single wildcards are not supported. So this would not work as expected:

<a *>

The hacky way to allow all attributes would be something like:

<a a* b* c* d* e* f* g* h* i* j* k* l* m* n* o* p* q* r* s* t* u* v* w* x* y* z*>

I believe I have a better understanding of this, after watching this video: https://www.youtube.com/watch?v=_ZPORuW1J_Q&list=PLigU0kVoiQFkvmN97VMvvG...

The point here is to prevent the total number of tags for a path to go up past 127. When the total number of tags goes past 127, the items in this setting will be "merged" into a single tag, thereby reducing the total number to keep it less than 127. So the items here should be items that very infrequently get purged. For example, if you rarely change blocks, maybe block-related items could be put here.

@guptahemant Thanks very much, that video cleared things up a bit. It was especially helpful to see what problems each configuration is meant to solve. Here's what I took away, as it relates to our site:

Cache Tag Prefixes: This is for cases where a particular URL has more than 127 tags. In our case we have a lot of tags on our "blacklist", so we are not concerned with going over 127 tags. So this setting is not so important to us.

Site identifier tag: I understand that this is important for multisite installations where multiple different domains might be used for the same Drupal site. In our case, we have only one domain, so this is not so important for us to customize.

Replace threshold: The wording here was confusing, but after watching the video I understand that this number is the number of pending queue items there needs to be before the entire site is purged, using the site identifier.

There are a few things I'm still confused about, but overall I'm much better informed now. Things I'm not 100% sure about are:

* The purpose of the "File identifier tag"
* How to interpret and act on the info under "Priority tags setup status".

@guptahemant Thank you for the reply. I did read the README but unfortunately it did not clarify things for me, because of my limited understanding of the internals of this module. For example, it states "...this can be customized by implementing..." but I still have the question: should it be customized? In other words: Why would I want to customize it? Is there a downside if I do not customize it?

I recognize that it may be a lot of work to re-write the documentation with more details. But in the short term, what is your recommendation? Are there any steps that we should do after installing this module? Or is it reasonable to use this module just by enabling it without any customization?

brockfanning → created an issue.

This makes a lot of sense to me. If the tags are not being communicated to Akamai, then there is no reason to try to invalidate them in Akamai. It's just a lot of unnecessary API traffic.

brockfanning → created an issue.

brockfanning → created an issue.

I don't know the internals enough to explain why, but one particular line in this patch is causing issues on our side. My wild guess is that maybe in previous versions of Drupal a particular array was associative, but now it's a flat array. Our project also has a ton of patches though, so it's also possible that some other patch is causing this problem. Anyway I'm attaching a version of the patch that seems to get around this problem for us. I changed this line:

$filtered_media_type_ids = array_intersect_key($allowed_media_type_ids, array_flip($permitted_medias));

To this:

$filtered_media_type_ids = array_intersect($allowed_media_type_ids, $permitted_medias);

I should add that, as you can tell from the steps to recreate this above, this is a problem that occurs with regular fields - ie, no "Media with contextual modifications" fields. In other words, the problem happens just by enabling this module. So, although this particular bug is pretty niche, I think this implies that some of the alters/hooks in this module may be having unintended effects.

Not knowing the background behind this particular form alter, this is a bit of a shot in the dark, but this bit of code does seem to fix the problem for us.

Perfect, thank you!

I was also thinking maybe of a no-code solution: We set sitemap #1 to our "default", and then we could go to /admin/config/search/simplesitemap/custom and add a custom link in our default which links to sitemap #2. Do you see any problems with that approach?

brockfanning → created an issue.

brockfanning → created an issue.

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.