fkildoo → created an issue.
Add on to my comment #74:
2. I ran the query: "select cid from cache_page where cid = 'https://www.example.com//blog:';" which returned the same result as the first part.
3. Output of show create table cache_page:
mysql> show create table cache_page;
+------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| cache_page | CREATE TABLE `cache_page` (
`cid` varchar(255) CHARACTER SET ascii COLLATE ascii_bin NOT NULL DEFAULT '' COMMENT 'Primary Key: Unique cache ID.',
`data` longblob COMMENT 'A collection of data to cache.',
`expire` bigint NOT NULL DEFAULT '0' COMMENT 'A Unix timestamp indicating when the cache entry should expire, or -1 for never.',
`created` decimal(14,3) NOT NULL DEFAULT '0.000' COMMENT 'A timestamp with millisecond precision indicating when the cache entry was created.',
`serialized` smallint NOT NULL DEFAULT '0' COMMENT 'A flag to indicate whether content is serialized (1) or not (0).',
`tags` longtext COMMENT 'Space-separated list of cache tags for this entry.',
`checksum` varchar(255) CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL COMMENT 'The tag invalidation checksum when this entry was saved.',
PRIMARY KEY (`cid`),
KEY `expire` (`expire`),
KEY `created` (`created`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='Storage for the cache API.' |
+------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)@alexpott in response to #65:
1. My database is MySQL v8.0.39
2. Running the query "select cid from cache_page limit 1;" returns 1 result (https://www.example.com//blog:), but I'm unclear on the rest of your request -- "...use the cid returned to a select where you have changed the case of the cid select cid from cache_page where cid = 'cid_case_changed';"
3. ?
Since applying the patch I haven't received the error. My Drupal version is 10.3.1.
Just an update... 3 days since applying the patch and there have been no errors. I assume the patch did the trick, but the last time there were 5 days between errors, so I can't be 100% sure yet. @banoodle went over 7 days between errors. If we both go over 8 days without seeing the error, I'd say it's probably good. I'll report back in a few days.
I applied the patch to my production site. So far so good. I've visited all the URLs below (with the site URL in front) and they all redirect to my home page without a 404 or an error in my log. I'll keep monitoring my logs for the error.
/%20
/index.php/
/
@larowlan Thanks, I figured it out and tested it on my dev site. Will apply to production tonight and report back if I get the error again.
@larowlan - Sorry, you all lost me a while ago! I don't have any experience with or knowledge of testing a merge request. I know how to implement a patch with Composer so I'm currently reading up on how to download and use a patch file from a merge request → . If successful, I will test it and report back.
On another note, this error has occurred 18 times starting on 7/12. Below are the frequency and times it has occurred, if that is helpful.
2024-07-22 13:45:26.248
2024-07-22 11:24:41.247
2024-07-20 11:48:51.248
2024-07-15 13:15:26.248
2024-07-14 23:12:35.248
2024-07-14 23:12:30.253
2024-07-14 23:12:15.248
2024-07-14 23:10:22.248
2024-07-14 23:00:52.248
2024-07-14 22:00:51.248
2024-07-12 19:15:05.441
2024-07-12 11:32:16.441
2024-07-12 11:28:39.149
2024-07-12 11:28:34.934
2024-07-12 11:24:59.982
2024-07-12 11:20:46.981
2024-07-12 11:00:48.981
2024-07-12 10:00:46.982
I ran the same query @banoodle did (below) but it returned an empty result because I ran it after I flushed the cache. I know, not very helpful.
SELECT * FROM `cache_data` WHERE `cid` LIKE '%route"[language]=en:[query_parameters]=:/' ORDER BY `cache_data`.`cid` ASC
If I enter myulr.com/%20 on my site, I get the same error in my log, but no 404 on the home page.
I have a dev site with almost the same setup and the issue is not occurring there. Caching and CSS/JS aggregation are enabled on both. I am trying to identify all the differences. One difference (which I don't think is preventing the issue) is my dev site is using the Search 404 module which will send the user to my custom Search page (using Solr Search) when a 404 occurs.
This is hard to reproduce and I'm not great at debugging. I have read through the related issues to see if I can get any useful info.
For now, my non-ideal temporary fix (fingers crossed) is to set up a cron job to clear the Drupal cache every 6 hours, 5 minutes after the automated Drupal cron is scheduled.
cd /var/www/site/html && /var/www/site/html/vendor/bin/drush --uri=https://siteurl cr
Other temporary fixes I've considered:
-- Add a rewrite rule to strip out trailing spaces (and trailing %20)
-- Exclude caching for the front page using the Cache Exclude module → or another way
Our issue happened once again at 6 PM on Sunday. The same error and 404 occurred on the home page. Flushing the cache brings the page back. I did notice in the logs the automated cron was run right before it occurred.
We do not have browser language detection enabled.
1. Yes, I have the redirect module enabled
2. I have state caching enabled but I don't think it makes any difference. I received the error and the 404 on my home page before I enabled it. After I enabled it, I received the error once again but not a 404 error on the home page.
Today was the first I became aware of the issue. I checked my logs back to 7/6 and there were no other errors.
Enabling state caching didn't make a difference for me. I just received the same error in the log I received earlier. However, my home page is still ok.
@banoodle Our site is on AWS Linux, not Pantheon.
I encountered this issue today as well. I also have a bilingual website with English as the primary language. The home page would go to a 404 page - "The requested page could not be found". It resolved after I cleared the cache. I am on Drupal version 10.3.1.
The update looks good except I wouldn't update the CDN version until the version of this theme matches. The X social media icon was introduced in USWDS 3.7.0. From the release notes:
Added the X social media icon. We added the X social media icon, but also preserved the legacy Twitter icon to allow teams to make the decision on when to update their social media information. (#5589)
Thanks. I didn't have it checked, so I went ahead and did that. Users can now access /admin, however, "Content" still does not appear in the Secondary toolbar menu or on the /admin page. And "Access Denied' still appears for /admin/content which is the main area they need access for.
I have a dev site with the same permissions that does work as expected. Of course, it's a different environment but I'm thinking it maybe has to do with something outside of permissions. Just not sure where else to look. I'm still digging.
I applied the patch and verified it works. Notice went away.
I am receiving the same notice in my log after I create new media at the same time as creating new content.
Example notice:
The file public://pdfpreview/16498-data-4.png was not deleted because it does not exist.
Steps to reproduce:
- Select Content > Add content
- Select content type that has a media field
- Select Add media
- Choose Files > Upload files > Save and insert
- Save to publish
If I create the media first, then "reference existing media in library" to attach to content, there is no error logged.