Changed to fixed, as patch in this issue is still needed.
Just providing an update here (as we had some offline communications in Slack).
We have discovered the root cause. Long story short, we have a custom hook_page_attachments_alter() that uses the build() function.
However the build() function changed from alpha27+. So we need to update our code. If we did a straight copy/paste of most of your code in build() from alpha27+, it works.
But instead of doing it like this, we are trying to use one of the hooks like hook_schemadotorg_jsonld_alter() instead as this is the recommended way to achieve our customisations.
Apologies for this long issue which ended up being our custom code.
I discovered that disabling Internal Page Cache resolves the issue. However, this is not a feasible long term solution.
Keep in mind, this issue only surfaced from alpha27 and going forward.
I've tried clearing caches as you mentioned. Still getting this issue. Our site is not using memcache/redis.
Importantly, I can replicate this issue on the master site, dev site and also locally (using ddev). So I'm 99.9% sure it's not environment specific.
I'm wondering if this is a Drupal core issue..? I've looked at your BubbleableMetadata implementation. It seems ok, but I'm not an expert in using Bubblemetadata.
To me it seems the problem is coming from the build() function and using Bubblemetadata. My latest conclusion at this point is that it works when not using BubbleableMetadata (like in alpha26).
I have made a little more progress on this.
I applied the patch from this issues queue and also 📌 Ensure the variation cache is cleared for JSON-LD. Active and I am using alpha29. I am still getting this caching issue.
I took a deeper dive into the code.
This line of code in particular is causing the issue:
$data = $builder->build($route_match, $bubbleable_metadata);
If I commented that line out and manually provided $data, then it works.
The key difference between my manual $data and the $data provided by the build function lies in the structure of the recipeIngredient and recipeInstructions properties. In the build function $data, these properties start with an indexed array, meaning they have an initial key of 0, whereas in my manual $data, these are directly embedded without an index.
Re-opening as I was able to make some progress on this.
(Sorry but this is a tricky and challenging issue to resolve coupled with the fact that it was also during a holiday period)
I took a look at the code from line 61 to 96 of schemadotorg_jsonld.module
If I commented out that code and applied the patch and used alpha29, it works. So I think the bug lies somewhere between line 61-96. Something related to caching but I cannot figure it out.
Thanks a whole bunch for helping on this, I really appreciate it.
I've tested the patch from #18 on alpha27 and alpha29
On alpha27 and alpha29 - I get the same results which are:
- it works, but I need to clear the cache each time I visit a node page with the structured data. If I visit another node page, the fields that use paragraphs in the structured data are entirely missing. I then clear the cache and I can see it works upon a refresh. When I say it "works", I mean I can see all the structured data as it should be (like if I was viewing it on alpha26).
I thought this might be a local caching issue or something, but then I tried alpha26 (with no patch) and it works flawlessly without having to clear cache. So I don't think it's a local caching issue.
Updating priority as this blocks us from upgrading past alpha26. Let us know if you need any more details or in what way we can help.
Just building on top of #5, if you are unable to run drush on a live environment, an alternative is to use a hook_update_N in a custom module:
function MODULENAME_update_N(&$sandbox) {
/** @var \Consolidation\SiteAlias\SiteAliasManager $alias_manager */
$alias_manager = Drush::service('site.alias.manager');
$selfRecord = $alias_manager->getSelf();
$your_queue = ['bundle' => 'YOUR_QUEUE_MACHINE_NAME'];
Drush::processManager()->drush($selfRecord, 'entity:delete', ['entity_subqueue'], $your_queue)->mustRun();
}
Just ensure in your deployment that drush updb
is fired before drush cim
(which is usually the case).
Thank you, MR 7 also solved this issue for me. Would be great to get this merged into the next stable release!
Forgot to attach the first screenshot to my last message.
I part that I cannot do is:
Manually change recipeIngredients from 'Text (plain)' to 'Paragraphs' (not 'Entity reference revisions')
When I try to manually map recipeIngredient, I only get the choice of Entity reference revisions (there are no Paragraphs, ever for other Paragraphs). I only see Entity reference revisions for all the paragraphs. (see attached screenshot)
My Ingredients Paragraph looks like the 2nd screenshot.
What field type are you using? 'Paragraphs' or 'Entity reference revisions'
In the Recipe content type, for the Ingredients field, it's:
Entity reference revisions
Reference type: Paragraph
Paragraph type: Ingredients
Just an fyi, my Recipe content type existed before I started using the Schema.org Blueprint module, so I did not create Recipe Schema.org type as in your second bullet point (although I don't think this has anything to do with it).
gargsuchi → credited xamount → .
gargsuchi → credited xamount → .
updating summary to reflect it includes upgrading
Thanks @jrockowitz
That worked and you were exactly right!
These are the steps I have been following since using this module a few months now:
- composer require drupal/config_sync
- drush en config_sync -y
- drush cr
- composer update drupal/schemadotorg --with-all-dependencies
- drush updb -y
- drush cr
- Go to /admin/config/development/distro and import the new config
- drush pmu config_sync
- drush pmu config_update
- drush pmu config_snapshot
- drush pmu config_provider
- drush pmu config_filter (this will also uninstall config_filter, config_distro_filter, config_normalizer)
- drush pmu config_merge
- drush pmu config_distro
- composer remove drupal/config_sync
- ddev drush cex -y (this is a new step I introduced as a result of this issue. I wasn't doing this before which is why I got the error)
- drush cr
It would save others numerous hours if you can correctly refine this and consider posting it on the module's page until a stable release.
gargsuchi → credited xamount → .
gargsuchi → credited xamount → .
gargsuchi → credited xamount → .
thejimbirch → credited xamount → .
Confirming that I am also getting this on CivicTheme 1.7.1. Subscribing.
Thank you so much! @salmonek
I tested the latest MR in 1.2.8 and 1.2.9 and all works as expected now.
I'll use the patch until this is merged. Do you know the ETA on 1.3.0?
gargsuchi → credited xamount → .
Additionally, the "add to dictionary" button is missing.
I tested the patch and I can see the new config and it's working.
I realised that with this patch, 2 specific functionalities have gone missing. I have highlighted them in the screenshot below.
The one on the left "Ignore all" is most important. Without this, a user cannot manually ignore a word.
Thanks @salmonek
I create an issue fork that includes your patch and also:
- fixed a few typos
- fixed a php deprecation notice.
I tested and everything works for far, but the main request of this ticket is still missing which is to disable to "toggle" functionality.
Thanks for explanation @danflanagan8
Let's leave this issue open then.
The IndexNow module has a more integrated approach with config split. Hopefully, this module can do it in such a way eventually.
Ah I see thanks for the explanation. Yes you might be right about the local browser cache. Lowering the priority to Normal then.
I guess what's needed here is a drupal permission to disallow users from being able to access the settings area when they click on the wproofreader text checker button. Is this possible?
In my case, spell checking is mandatory and I do not want to allow site editors to be able to enable/disable it. I wrote a hook_form_alter to block the node edit form from saving if there are wproofreader detected errors. If site editors can then disable the wproofreader, then it defeats the purpose of the hook_form_alter validation check.
xamount → created an issue.
Adding a call-to-action for donations. This lowers the bar for companies to financially contribute.
Thanks for this great module! I really appreciate the efforts here! Is there a link to financially donate towards a stable release? Maybe put it on the module's homepage?
The patch at #5 fixes the issue for me. Thanks!
I can confirm that @sonnykt 's solution has resolved this issue for me.
In our case, the cache tables were missing COLLATE ascii_bin
. Without this, there is case insensitivity which resulted in a redirect loop as described in the ticket description.
As using the standard Drupal cache table definitions solves this issue I am going to mark this as "Closed works as designed".
gargsuchi → credited xamount → .
gargsuchi → credited xamount → .
1. Previous patch was missing config so I added that.
2. I updated the text "REQUIRED BY GOOGLE" to "Not required BY GOOGLE but recommended otherwise" as publisher is not actually required by Google.
Attaching new patch.
Attaching patch that builds on comment #1 and also adds the config
Previous patch is missing the date_modified config
gargsuchi → credited xamount → .
Just adding my notes...maybe it might be valuable and some recommendations can be made so we can join our efforts.
I have a D10 site but I still have to use CK4 due to ckeditor_scayt not being available for ck5.
I'm also using the paid version of Webspellchecker on this site. For this I have written a custom webspellchecker module which works on D10, using ck4 and this current module.
The webspellchekcer module basically uses a hook_form_alter to hook into node_add and node_edit forms and blocks the form from submission if there are detected grammar/spelling errors in text and textarea fields, including nested paragraph fields. These are the requirements of the client. It also add an admin config form to Change the serviceID and on what content types this module will be used on.
The serviceID is the unique ID you get when you purchase the paid webspellchecker.
I'm unable to upgrade this module due to it only working on ck4. I read there is a Webspellchecker for ck5, but I have not gotten around to upgrading this custom module as yet (this is where help is needed).
I did contact the Webspellchecker company about 2 years ago to see if paid sponsorship can be achieved and I would put the custom module up here:
https://www.drupal.org/project/webspellchecker →
But that never happened. It seems Drupal and Webspellchecker has low demand.
This explains my comment at #4.
What's the best way to proceed here? Ideally, I would want to achieve almost the same requirements but using ck5.
gargsuchi → credited xamount → .
gargsuchi → credited xamount → .
I can also confirm the patch at #7 fixes the issue. (same issue as described in #10 but using PHP 8.1 and Drupal 10.1.7)
I've tested the patch at #67 and it's working for me on D10.1.6
For anyone who got the error in the issue description, were you using the LiteSpeed Cache module for Drupal?
For me, I upgraded to D10, then some pages worked fine and some didn't. For the pages that didn't, the css/jss were not loaded and I saw the error in the Drupal logs (same error as this issue description).
After uninstalling the LiteSpeed Cache module, everything worked fine. Not sure if it's just me or what...
@miiimooo
Are you using the LiteSpeed Cache module by chance?
I just upgraded to D10 and I am getting this same error. Some pages, load fine and some load but the css/jss files don't load which makes the pages style-less.
After uninstalling the LiteSpeed Cache module, everything works fine.
Hi, just checking if there is any ETA on this? This particular issue is the last piece of the puzzle for a D10 upgrade for me.
Ah yes you are right.
I was initially looking at the "recommended" section on the module homepage. Minor issue then but I guess the maintainer can update that.
I have replicated it with 1.6.0. Setting status back to active.
Seems this is a core issue.
Temporary solution is to use this patch: https://www.drupal.org/project/drupal/issues/3204271#comment-15151776 🐛 Layout builder cannot recover on missing layout Needs work
Although the suggestion at #24 does indeed work, keep in mind there is a security risk here if your site was using private files. That is, your temporarily uploaded private images will be placed in the public files folder (and probably just left there I suppose).
If your site is not using private files, it should be fine to do #24 as a workaround. However, it's not a permanent solution (for e.g let's say your site were to use private files in the future, then you should revert the change).
The root issue should be fixed in this module as the permanent solution.
I've reviewed and tested the patch. It works as expected.
After applying the patch and adding the video schema tags, I can see the video structured data in the Recipe schema in the html source code. It also validates when I tested using the Google Rich Result tool.
gargsuchi → credited xamount → .
gargsuchi → credited xamount → .
gargsuchi → credited xamount → .
gargsuchi → credited xamount → .
This code is only applicable if you use the mentioned effects (fixed header, parallax effect etc).
For sites using Bootstrap Barrio that do not use those effects, this code is 100% unused AND hinders browser performance.
(Read up on layout thrashing. This code hurts the Interaction to Next Paint (INP) core web vitals metric, especially on low-end mobiles).
It would have been better to have a enable/disable theme setting which would then load/not load this js if needed. For this reason, I am setting the status back to "Active". If you feel this issue is not important, then revert the status.
As of right now, it's loaded unconditionally.
Anyways, for the rest of us who choose not to use this code and would like to improve their INP metric slightly, you can ignore it like this.
In YOURTHEME.info.yml
libraries-override:
bootstrap_barrio/global-styling:
js:
js/barrio.js: false
gargsuchi → credited xamount → .
gargsuchi → credited xamount → .
Just fixing a php code sniffer error.
Attached is the updated patch.
Or at least create a variable for it so we don't need to call $this->jsCollectionRenderer->render($js_assets) twice.
Thank you @prudloff
Almost works now.
You just need to update the last return statement to:
return $this->jsCollectionRenderer->render($js_assets);
Otherwise the other JS on the page will be excluded from being rendered.
Hi @prudloff
Yes you are absolutely right: "JS in the head without an async or defer attribute is render blocking".
However, I tested your patch and here is what happens.
<html>
<head>....</head>
<body>
<script src="somecode.js">...</script>. //this non-critical JS gets pushed even though it's not in the <head>.
</body>
</html>
gargsuchi → credited xamount → .
Thank you very much @Abhinand Gokhala K
Great work! I tested the latest patch and all the issues have been resolved and it works as expected now.
Also, it will be better to set the path correctly to add it to the Development menu at admin/config/development. Right now, users will need to manually type in the config settings form path
Thanks Abhinand,
I have done an initial review.
For users that already have this module enabled, if we were to introduce this patch, they will get this error upon drush cr:
$ drush cr
[warning] Trying to access array offset on value of type bool Http2ServerPushServiceProvider.php:34
So I believe you need to take care of the case where this setting has not been set initially (provide a default value of FALSE ?).
After I enabled the setting "exclude js", I can see that the JS is excluded. But when I disabled the setting, the JS is still excluded. I believe you need to revise the if() logic.
gargsuchi → credited xamount → .
gargsuchi → credited xamount → .
Coming to thinking of it, proposed resolution #1 is not really optimal.
Example of a js defined library:
mycustomjslibrary:
header: true
js:
dist/js/brands.min.js: { attributes: { defer: true }}
If you server pushed this js, then the defer option is kinda irrelevant.
Just an FYI, Cloudflare automatically does this by default. (not sure about other CDNs, but probably..)
See here: https://blog.cloudflare.com/early-hints/. (See section "Now: Turning 200 OK Link: headers into 103 Early Hints")
To summarise: Cloudflare will read your Link headers and push that through early hints via HTTP 103.
As said in #11, I am also still experiencing this error message. I have confirmed this twice.
In my case, I am using Sendgrid to send Drupal Commerce emails for order confirmations. Apart from sending the emails to the person (1 recipient), I am using Blind Carbon Copy → so now it's 2 recipients and it's breaking Sendgrid.
When I turn off the Blind Carbon Copy, it works (sending to 1 recipient).
So it seems there is something still wrong with sending to multiple email addresses.
This issue is highly critical for me as it's blocking Drupal Commerce orders from going through. I have to turn off Blind Carbon Copy in the meantime. Hence I am raising the priority to "Major" as I have a temporary workaround and hope that the maintainer will re-open this issue.
My exact error message is:
SendGrid\Exception\TypeException: "$emailAddress" must be a valid email address. Got: xxx@xxx.com in SendGrid\Helper\Assert::email() (line 68 of /code/vendor/fastglass/sendgrid/src/Helper/Assert.php).
xxx@xxx.com is the 2nd recipient (the email that I have for bcc).
Drupal 9.54
PHP 8.0.27
One important thing I noticed is that some themes (core themes included) are using libraries-override to override some of the css in the system/base library. I don't think it will break anything, but the css it will try to find will not exist.
For e.g. in claro.info.yml:
libraries-override:
system/base:
css:
component:
css/components/ajax-progress.module.css: css/components/ajax-progress.module.css
css/components/autocomplete-loading.module.css: css/components/autocomplete-loading.module.css
css/components/system-status-counter.css: css/components/system-status-counter.css
css/components/system-status-report-counters.css: css/components/system-status-report-counters.css
css/components/system-status-report-general-info.css: css/components/system-status-report-general-info.css
css/components/tabledrag.module.css: css/components/tabledrag.css
In the above code, all of the source system-status-...css will be missing if this MR were to be merged.
What should we do about these kinds of cases?
I took a stab at it and refactored most of the css that should be refactored. The remainder of css were not specific to any templates and/or were too broad and used in multiple areas of Drupal.
gargsuchi → credited xamount → .
I've seen this happen before on a production site. It was because the header size of the page was too big. (I'm not saying this is the issue specifically for you, but mentioning it here in case it might help)
Is this problem happening on just specific pages or across the entire website?
If yes to specific pages, are those pages very long?
In our case, it was because we were using a View without pagination and the page was trying to generate hundreds of results. So paginating the view helped.
You can check header size of a page by doing:
curl -s -w \%{size_header} -o /dev/null https://your-domain.com/you-page
Kristen Pol → credited xamount → .
Kristen Pol → credited xamount → .