breidert → credited banoodle → .
tonypaulbarker → credited banoodle → .
thejimbirch → credited banoodle → .
Oh - you are using SOLR and I am not. I think that is why.
@dubs I don't have a "Unique values filter" on my search index processors page. I even tried upgrading to the 1.x-dev release, but I still don't have it. Are you using some other contrib module that provides this functionality?
Patch #5 no longer applies on the latest 2.0.x-dev branch.
Attaching re-rolled patch.
Thanks!
thejimbirch → credited banoodle → .
Oh, @jphelan, you are correct! I don't know why, but I didn't realize 159 is for 10.3 also. Thanks for pointing this out.
Patch for #159 works perfectly for me.
@smustgrave I'm not sure how we could confirm it. Since applying the MR on this issue over 2 weeks ago, there haven't been any further incidents.
We have never been able to reproduce the 404 on the homepage on-demand, so I think the only way we could validate this, would be to rollback the MR fix, apply the patch for the other issue and then wait to see if it happens again. The longest error-free interval we had when we still had the problem was 10 days.
Also we are on 10.3.1 and it looks like they haven't provided a patch for that yet (but from the latest comment it looks like one may be forthcoming soon). If it is, would we want to apply that on top of the MR from this issue?
@alexpott thank you for working on this. Here are the requested details from our site:
Database: 10.4.25-MariaDB-log
The first query returns a cid of: https://www.rescue.org/eu/search-eu/site/Child%20protection?page=16:
If I change the case and run this query, it returns no results:
select cid from cache_page where cid = 'https://www.rescue.org/eu/search-eu/site/child%20protection?page=16:';
Here is the output from show create table cache_page;:
Thank you, @DuaelFr for patch #157 for D10.3.
It applied cleanly and works well, but it introduces the following error when drush updb is run:
"The following update is specified as removed in hook_removed_post_updates() but still exists in the code base: media_post_update_oembed_loading_attribute"
@larowlan looks like I spoke too soon: we had an incident last night. This was with state_cache set to true. We had gone 10 days since the last incident.
We have applied this issue's patch and will let you know if we have another incident.
@larowlan we can try it, but ever since we set state cache to true last Saturday morning (7/13/24), we haven't had a recurrence of the problem (so it has been over a week since the last incident).
I got a hold of a copy of the database taken shortly before the latest homepage 404 happened.
In the cache data table, I see the culprit...
Once caches are flushed, this bad actor is eliminated. We still can't figure out how this bad actor gets added to cache in the first place.
The :/%20 entry beneath the top :/ entry does seem to support @Catch's suggestion of this issue → being related, but even if I enter myulr.com/%20 on my site, I can't make the problem happen.
In case it is helpful, here is the bad actor's blob data:
a:3:{s:4:"path";s:2:"/ ";s:5:"query";a:0:{}s:6:"routes";O:41:"Symfony\Component\Routing\RouteCollection":4:{s:49:"Symfony\Component\Routing\RouteCollectionroutes";a:4:{s:8:"<button>";O:31:"Symfony\Component\Routing\Route":9:{s:4:"path";s:1:"/";s:4:"host";s:0:"";s:8:"defaults";a:0:{}s:12:"requirements";a:1:{s:7:"_access";s:4:"TRUE";}s:7:"options";a:4:{s:14:"compiler_class";s:33:"Drupal\Core\Routing\RouteCompiler";s:8:"_no_path";b:1;s:4:"utf8";b:1;s:14:"_access_checks";a:1:{i:0;s:20:"access_check.default";}}s:7:"schemes";a:0:{}s:7:"methods";a:2:{i:0;s:3:"GET";i:1;s:4:"POST";}s:9:"condition";s:0:"";s:8:"compiled";O:33:"Drupal\Core\Routing\CompiledRoute":11:{s:4:"vars";a:0:{}s:11:"path_prefix";s:0:"";s:10:"path_regex";s:8:"{^/$}sDu";s:11:"path_tokens";a:1:{i:0;a:2:{i:0;s:4:"text";i:1;s:1:"/";}}s:9:"path_vars";a:0:{}s:10:"host_regex";N;s:11:"host_tokens";a:0:{}s:9:"host_vars";a:0:{}s:3:"fit";i:1;s:14:"patternOutline";s:1:"/";s:8:"numParts";i:1;}}s:7:"<front>";O:31:"Symfony\Component\Routing\Route":9:{s:4:"path";s:1:"/";s:4:"host";s:0:"";s:8:"defaults";a:1:{s:6:"_title";s:4:"Home";}s:12:"requirements";a:1:{s:7:"_access";s:4:"TRUE";}s:7:"options";a:3:{s:14:"compiler_class";s:33:"Drupal\Core\Routing\RouteCompiler";s:4:"utf8";b:1;s:14:"_access_checks";a:1:{i:0;s:20:"access_check.default";}}s:7:"schemes";a:0:{}s:7:"methods";a:2:{i:0;s:3:"GET";i:1;s:4:"POST";}s:9:"condition";s:0:"";s:8:"compiled";O:33:"Drupal\Core\Routing\CompiledRoute":11:{s:4:"vars";a:0:{}s:11:"path_prefix";s:0:"";s:10:"path_regex";s:8:"{^/$}sDu";s:11:"path_tokens";a:1:{i:0;a:2:{i:0;s:4:"text";i:1;s:1:"/";}}s:9:"path_vars";a:0:{}s:10:"host_regex";N;s:11:"host_tokens";a:0:{}s:9:"host_vars";a:0:{}s:3:"fit";i:1;s:14:"patternOutline";s:1:"/";s:8:"numParts";i:1;}}s:8:"<nolink>";O:31:"Symfony\Component\Routing\Route":9:{s:4:"path";s:1:"/";s:4:"host";s:0:"";s:8:"defaults";a:0:{}s:12:"requirements";a:1:{s:7:"_access";s:4:"TRUE";}s:7:"options";a:4:{s:14:"compiler_class";s:33:"Drupal\Core\Routing\RouteCompiler";s:8:"_no_path";b:1;s:4:"utf8";b:1;s:14:"_access_checks";a:1:{i:0;s:20:"access_check.default";}}s:7:"schemes";a:0:{}s:7:"methods";a:2:{i:0;s:3:"GET";i:1;s:4:"POST";}s:9:"condition";s:0:"";s:8:"compiled";O:33:"Drupal\Core\Routing\CompiledRoute":11:{s:4:"vars";a:0:{}s:11:"path_prefix";s:0:"";s:10:"path_regex";s:8:"{^/$}sDu";s:11:"path_tokens";a:1:{i:0;a:2:{i:0;s:4:"text";i:1;s:1:"/";}}s:9:"path_vars";a:0:{}s:10:"host_regex";N;s:11:"host_tokens";a:0:{}s:9:"host_vars";a:0:{}s:3:"fit";i:1;s:14:"patternOutline";s:1:"/";s:8:"numParts";i:1;}}s:6:"<none>";O:31:"Symfony\Component\Routing\Route":9:{s:4:"path";s:1:"/";s:4:"host";s:0:"";s:8:"defaults";a:0:{}s:12:"requirements";a:1:{s:7:"_access";s:4:"TRUE";}s:7:"options";a:4:{s:14:"compiler_class";s:33:"Drupal\Core\Routing\RouteCompiler";s:8:"_no_path";b:1;s:4:"utf8";b:1;s:14:"_access_checks";a:1:{i:0;s:20:"access_check.default";}}s:7:"schemes";a:0:{}s:7:"methods";a:2:{i:0;s:3:"GET";i:1;s:4:"POST";}s:9:"condition";s:0:"";s:8:"compiled";O:33:"Drupal\Core\Routing\CompiledRoute":11:{s:4:"vars";a:0:{}s:11:"path_prefix";s:0:"";s:10:"path_regex";s:8:"{^/$}sDu";s:11:"path_tokens";a:1:{i:0;a:2:{i:0;s:4:"text";i:1;s:1:"/";}}s:9:"path_vars";a:0:{}s:10:"host_regex";N;s:11:"host_tokens";a:0:{}s:9:"host_vars";a:0:{}s:3:"fit";i:1;s:14:"patternOutline";s:1:"/";s:8:"numParts";i:1;}}}s:50:"Symfony\Component\Routing\RouteCollectionaliases";a:0:{}s:52:"Symfony\Component\Routing\RouteCollectionresources";a:0:{}s:53:"Symfony\Component\Routing\RouteCollectionpriorities";a:0:{}}}
The following is the blob data from the :%20 entry:
a:3:{s:4:"path";s:2:"/ ";s:5:"query";a:0:{}s:6:"routes";O:41:"Symfony\Component\Routing\RouteCollection":4:{s:49:"Symfony\Component\Routing\RouteCollectionroutes";a:4:{s:8:"<button>";O:31:"Symfony\Component\Routing\Route":9:{s:4:"path";s:1:"/";s:4:"host";s:0:"";s:8:"defaults";a:0:{}s:12:"requirements";a:1:{s:7:"_access";s:4:"TRUE";}s:7:"options";a:4:{s:14:"compiler_class";s:33:"Drupal\Core\Routing\RouteCompiler";s:8:"_no_path";b:1;s:4:"utf8";b:1;s:14:"_access_checks";a:1:{i:0;s:20:"access_check.default";}}s:7:"schemes";a:0:{}s:7:"methods";a:2:{i:0;s:3:"GET";i:1;s:4:"POST";}s:9:"condition";s:0:"";s:8:"compiled";O:33:"Drupal\Core\Routing\CompiledRoute":11:{s:4:"vars";a:0:{}s:11:"path_prefix";s:0:"";s:10:"path_regex";s:8:"{^/$}sDu";s:11:"path_tokens";a:1:{i:0;a:2:{i:0;s:4:"text";i:1;s:1:"/";}}s:9:"path_vars";a:0:{}s:10:"host_regex";N;s:11:"host_tokens";a:0:{}s:9:"host_vars";a:0:{}s:3:"fit";i:1;s:14:"patternOutline";s:1:"/";s:8:"numParts";i:1;}}s:7:"<front>";O:31:"Symfony\Component\Routing\Route":9:{s:4:"path";s:1:"/";s:4:"host";s:0:"";s:8:"defaults";a:1:{s:6:"_title";s:4:"Home";}s:12:"requirements";a:1:{s:7:"_access";s:4:"TRUE";}s:7:"options";a:3:{s:14:"compiler_class";s:33:"Drupal\Core\Routing\RouteCompiler";s:4:"utf8";b:1;s:14:"_access_checks";a:1:{i:0;s:20:"access_check.default";}}s:7:"schemes";a:0:{}s:7:"methods";a:2:{i:0;s:3:"GET";i:1;s:4:"POST";}s:9:"condition";s:0:"";s:8:"compiled";O:33:"Drupal\Core\Routing\CompiledRoute":11:{s:4:"vars";a:0:{}s:11:"path_prefix";s:0:"";s:10:"path_regex";s:8:"{^/$}sDu";s:11:"path_tokens";a:1:{i:0;a:2:{i:0;s:4:"text";i:1;s:1:"/";}}s:9:"path_vars";a:0:{}s:10:"host_regex";N;s:11:"host_tokens";a:0:{}s:9:"host_vars";a:0:{}s:3:"fit";i:1;s:14:"patternOutline";s:1:"/";s:8:"numParts";i:1;}}s:8:"<nolink>";O:31:"Symfony\Component\Routing\Route":9:{s:4:"path";s:1:"/";s:4:"host";s:0:"";s:8:"defaults";a:0:{}s:12:"requirements";a:1:{s:7:"_access";s:4:"TRUE";}s:7:"options";a:4:{s:14:"compiler_class";s:33:"Drupal\Core\Routing\RouteCompiler";s:8:"_no_path";b:1;s:4:"utf8";b:1;s:14:"_access_checks";a:1:{i:0;s:20:"access_check.default";}}s:7:"schemes";a:0:{}s:7:"methods";a:2:{i:0;s:3:"GET";i:1;s:4:"POST";}s:9:"condition";s:0:"";s:8:"compiled";O:33:"Drupal\Core\Routing\CompiledRoute":11:{s:4:"vars";a:0:{}s:11:"path_prefix";s:0:"";s:10:"path_regex";s:8:"{^/$}sDu";s:11:"path_tokens";a:1:{i:0;a:2:{i:0;s:4:"text";i:1;s:1:"/";}}s:9:"path_vars";a:0:{}s:10:"host_regex";N;s:11:"host_tokens";a:0:{}s:9:"host_vars";a:0:{}s:3:"fit";i:1;s:14:"patternOutline";s:1:"/";s:8:"numParts";i:1;}}s:6:"<none>";O:31:"Symfony\Component\Routing\Route":9:{s:4:"path";s:1:"/";s:4:"host";s:0:"";s:8:"defaults";a:0:{}s:12:"requirements";a:1:{s:7:"_access";s:4:"TRUE";}s:7:"options";a:4:{s:14:"compiler_class";s:33:"Drupal\Core\Routing\RouteCompiler";s:8:"_no_path";b:1;s:4:"utf8";b:1;s:14:"_access_checks";a:1:{i:0;s:20:"access_check.default";}}s:7:"schemes";a:0:{}s:7:"methods";a:2:{i:0;s:3:"GET";i:1;s:4:"POST";}s:9:"condition";s:0:"";s:8:"compiled";O:33:"Drupal\Core\Routing\CompiledRoute":11:{s:4:"vars";a:0:{}s:11:"path_prefix";s:0:"";s:10:"path_regex";s:8:"{^/$}sDu";s:11:"path_tokens";a:1:{i:0;a:2:{i:0;s:4:"text";i:1;s:1:"/";}}s:9:"path_vars";a:0:{}s:10:"host_regex";N;s:11:"host_tokens";a:0:{}s:9:"host_vars";a:0:{}s:3:"fit";i:1;s:14:"patternOutline";s:1:"/";s:8:"numParts";i:1;}}}s:50:"Symfony\Component\Routing\RouteCollectionaliases";a:0:{}s:52:"Symfony\Component\Routing\RouteCollectionresources";a:0:{}s:53:"Symfony\Component\Routing\RouteCollectionpriorities";a:0:{}}}
One thing all 3 of our incidents have had in common, is they occurred when the site was relatively lightly visited. The site gets a lot of traffic, but this occurred when it wasn't getting much traffic.
Could just be a coincidence, I suppose.
We aren't using Browser detection.
That first issue doesn't seem related (d7). In any case, I tried the repo steps here → and couldn't create the problem that way.
We had another occurrence of the 404 error on the homepage about 2 hours ago.
So it looks like the state change had no affect on this issue.
We were able to correct things by flushing/rebuilding cache.
Oh and we aren't sure if clearing caches will fix the issue. So far, our team has just saved the english translation of the homepage node to correct the problem when it happened. We've asked everyone to try flushing caches first if it recurs, because we are curious about that.
Yes, we are using the Redirect module.
Today, we set state cache to FALSE (because we had a high number of states in the key_value table, and the change record → suggested this).
So far, it is too early to tell if this will help, but we will let you know if the problem recurs.
We have only seen the failure 2 times in the 5 days since we upgraded to 10.3. The client has monitoring enabled on the homepage, so we are pretty sure it has only been the 2 times.
@fkildoo after running the suggested queries in the change record → , we have concluded we might benefit from setting $settings['state_cache'] to FALSE, so we are giving that a try. Our incidents of this problem are infrequent (2 in 5 days), so it will be difficult to assess the success or failure of this setting.
One bandaid we may try for now is to set up a ping to hit https://oursite.com/en because @pingwin_cracow mentioned that working to resolve their issue once it occurs. At least if it does happen again, we're thinking the ping might resolve the situation quickly. We are considering pinging the site every 3 minutes.
In our case, saving the homepage node resolved the issue.
Thanks @fkildoo. Interesting.
We are now looking into adding the $settings['state_cache'] = TRUE; to settings.php mentioned in
this change order →
.
Not sure this is our problem, but we are hoping it might help.
We are encountering this problem as well. We have a client with a very high-profile humanitarian aid site that is being affected by this. I think this is critical. For our client, the homepage being down is as bad as the entire site being down. And the homepage will only answer up again if a human intervenes (in the middle of the night).
This site is hosted on Pantheon - curious if the other reported incidents are also on Pantheon?
I plan to open a support ticket with them. I will report back anything I learn.
I just want to chime in here in case it is helpful to others.
We added a field_link_icon field to our menu links using the menu_item_fields module.
We want to display this icon in tb_megamenu along with the menu links.
As noted in this issue, there doesn't appear to be a way through the UI/config to do this.
We were able to achieve this by adding the following to our theme's tb-megamenu-item.html.twig (and installing the twig_tweak → module):
{% set media_id = item.link.entity.field_link_icon.0.target_id %}
{{ drupal_image(media_id, 'thumbnail', {alt: ''}) }}Thanks to @nkarhoff for helping me with this solution!
banoodle → created an issue.
banoodle → created an issue.
Oh my - I posted this in the wrong issue queue! Apologies, this upgrade has been a confusing tangle of dependencies!
I will close this and open an issue in the Group issue queue, which is what I intended.
Please note: I am attempting this with the 2.3.x-dev branch of Group, not 2.0.x (it's just that 2.3.x wasn't an available option for this issue).
OK - I just realized writing a patch for this was dumb (after reading this nice explanation)
Please don't waste your time with this patch.
So now I am asking the maintainer: can you update the flexible_permissions dependency in composer.json from version 1.1. to version 2.0? I realize this may be more involved than just updating composer.json as there could be deprecated functions to refactor.
This would allow us to upgrade Group 2.0 sites to Drupal 10.3.
Uploading patch.
banoodle → created an issue.
Uploading patch.
banoodle → created an issue.
I'm truly grateful for the efforts here, but ideally, I would like to be able to have this option on any full-text field - not just "body."
The 10.2 patch (132) works well for Body fields. Is the ultimate D11 fix also just going to target the body field?
RTBC
Uploading new patch because coding standards.
I added field group config updates to the update hook and I also added missing always_show config.
Uploading patch.
Uploading patch for the 8.x-1.x branch.
Thanks for contributing this module - very helpful!
banoodle → created an issue.
Un-assigning self.
Uploading patch that fixes this issue.
banoodle → created an issue.
I saw comment #38 and noticed that I was on paragraphs 1.16.0.
I just upgraded to 1.17.0 and applied patch #35 and now it is working for me!
Thank you!
Needs review.
Submitting patch.
banoodle → created an issue.
I upgraded to Drupal 10.2.2 and I also can no longer add links to Group menus.
Patch #2 fixes the issue for me, but I have created this task in the Group Content Menu → issue queue to get visibility with the maintainers of that module: https://www.drupal.org/project/group_content_menu/issues/3417879 🐛 Can't create group menu link after upgrade to 10.2.2 - Error: Call to a member function label() on null Closed: duplicate
In the meantime, I'm going to have to use the patch on this issue - so thanks!
banoodle → created an issue.
Patch #7 works beautifully for me - thank you!
I tried path #35. It applies cleanly, but the problem originally reported in this task persists.
I tried the patch from #30 on D10.2 site, but I still get the error reported in #28.
Patch #51 applied OK for me, but throws these errors due to the inclusion of group_content.
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "group_content" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition() (line 139 of /code/web/core/lib/Drupal/Core/Entity/EntityTypeManager.php).
This patch I'm uploading just replaces "group_content" with "group_relationship".
This functionality does not exist in the current 1.10 release. It also doesn't exist in the latest Dev branch.
Was this functionality removed? I could really use it.
Just want to report that this patch works for me and that I had this problem even though I'm just using Drupal core's previewing and not the responsive preview module.
In my case, the extra menu link doesn't get created every time I preview the node, but in the course of several attempts I can see it happen once. Not sure why it is sporadic, but patch 6 seems to fix it.
Thanks!
I'm not going to set this to RBTC because I think someone using Responsive Preview should also validate this.
I posted this to groups.drupal.org today: https://groups.drupal.org/node/536918
Thanks for doing the events posting and other tasks @volkswagenchick!
volkswagenchick → credited banoodle → .
Here are Links mentioned at SFDUG meetup:
- Dries' State of Drupal presentation (with info about PitchBurgh finalists): https://dri.es/state-of-drupal-presentation-june-2023
- DrupalCon Pittsburgh Session Videos: https://www.youtube.com/playlist?list=PLpeDXSh4nHjTZrlCUtl_xp87F3plT7czE
- Latest Drupal news (and to subscribe to weekly update email): http://www.theweeklydrop.com
- Drupal Events: https://www.drupal.org/community/events →
- Drupal Jobs: https://jobs.drupal.org/ →
volkswagenchick → credited banoodle → .
I take it back: the problem happens even with caching disabled on the view.
It seems setting cache to none on the view eliminates the problem. I can maybe get away with that on the current view/site I'm working on, but it's not ideal.
I can confirm I am still experiencing this problem as of core 9.5.9.
I tried applying patch from comment #10 but it won't apply any more.
I do not have AJAX enabled on the view.
The problem is intermittent.
I've never had the problem described in the related issue. Except for things sometimes being all selected, it does seem to remember and apply the appropriate filter(s) sometimes.
banoodle → made their first commit to this issue’s fork.
Changing date of this workshop.
Changing date of this workshop.
Changing date of this workshop.
Changing date of this workshop.
I agree to the 2023 BADCamp CoC
I agree to the 2023 BADCamp CoC
I agree to the 2023 BADCamp CoC
closing
Thanks, Charles - I have fixed the broken link!
closing
closing
closing
closing
closing
closing task
Video of last night’s SFDUG “Viewsapalooza” is available here: https://youtu.be/g0p9RlXXXWU - we discussed some cool modules:
- Entity Reference Exposed Filters
- Fullcalendar View
- Views Conditional
- Views Custom Table
- Views Data export
- Views Field View
- Views Filters Summary
banoodle → created an issue.
banoodle → created an issue.
banoodle → created an issue.
banoodle → created an issue.
We are seeing this on a 9.5.2 site with Drush version: 10.6.2
It's weird though because we have other sites with same versions and on same hosting platform that don't get this error.
In our case, I think the errors are triggered by Pantheon web hooks that run drush updb, cim and cr (and maybe when cron runs). I see them on the Pantheon dashboard. I never see the error in my local copy of the site.
Oh and I noticed this code and the comment that seems to be targeted at the very thing I am experiencing. It seems this code is not working as expected...
banoodle → created an issue.