Account created on 20 May 2005, over 19 years ago
#

Merge Requests

Recent comments

🇹🇹Trinidad and Tobago xamount

Changed to fixed, as patch in this issue is still needed.

🇹🇹Trinidad and Tobago xamount

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.

🇹🇹Trinidad and Tobago xamount

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.

🇹🇹Trinidad and Tobago xamount

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).

🇹🇹Trinidad and Tobago xamount

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.

🇹🇹Trinidad and Tobago xamount

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.

🇹🇹Trinidad and Tobago xamount

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.

🇹🇹Trinidad and Tobago xamount

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.

🇹🇹Trinidad and Tobago xamount

xamount made their first commit to this issue’s fork.

🇹🇹Trinidad and Tobago xamount

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).

🇹🇹Trinidad and Tobago xamount

Thank you, MR 7 also solved this issue for me. Would be great to get this merged into the next stable release!

🇹🇹Trinidad and Tobago xamount

Forgot to attach the first screenshot to my last message.

🇹🇹Trinidad and Tobago xamount

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).

🇹🇹Trinidad and Tobago xamount

updating summary to reflect it includes upgrading

🇹🇹Trinidad and Tobago xamount

Adding upgrade steps

🇹🇹Trinidad and Tobago xamount

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:

  1. composer require drupal/config_sync
  2. drush en config_sync -y
  3. drush cr
  4. composer update drupal/schemadotorg --with-all-dependencies
  5. drush updb -y
  6. drush cr
  7. Go to /admin/config/development/distro and import the new config
  8. drush pmu config_sync
  9. drush pmu config_update
  10. drush pmu config_snapshot
  11. drush pmu config_provider
  12. drush pmu config_filter (this will also uninstall config_filter, config_distro_filter, config_normalizer)
  13. drush pmu config_merge
  14. drush pmu config_distro
  15. composer remove drupal/config_sync
  16. 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)
  17. 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.

🇹🇹Trinidad and Tobago xamount

Confirming that I am also getting this on CivicTheme 1.7.1. Subscribing.

🇹🇹Trinidad and Tobago xamount

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?

🇹🇹Trinidad and Tobago xamount

Additionally, the "add to dictionary" button is missing.

🇹🇹Trinidad and Tobago xamount

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.

🇹🇹Trinidad and Tobago xamount

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.

🇹🇹Trinidad and Tobago xamount

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.

https://www.drupal.org/project/index_now

🇹🇹Trinidad and Tobago xamount

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.

🇹🇹Trinidad and Tobago xamount

Adding a call-to-action for donations. This lowers the bar for companies to financially contribute.

🇹🇹Trinidad and Tobago xamount

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?

🇹🇹Trinidad and Tobago xamount

The patch at #5 fixes the issue for me. Thanks!

🇹🇹Trinidad and Tobago xamount

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".

🇹🇹Trinidad and Tobago 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.

🇹🇹Trinidad and Tobago xamount

Attaching patch that builds on comment #1 and also adds the config

🇹🇹Trinidad and Tobago xamount

Previous patch is missing the date_modified config

🇹🇹Trinidad and Tobago 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.

🇹🇹Trinidad and Tobago 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)

🇹🇹Trinidad and Tobago xamount

I've tested the patch at #67 and it's working for me on D10.1.6

🇹🇹Trinidad and Tobago xamount

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...

🇹🇹Trinidad and Tobago xamount

@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.

🇹🇹Trinidad and Tobago xamount

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.

🇹🇹Trinidad and Tobago xamount

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.

🇹🇹Trinidad and Tobago xamount

I have replicated it with 1.6.0. Setting status back to active.

🇹🇹Trinidad and Tobago xamount

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

🇹🇹Trinidad and Tobago xamount

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.

🇹🇹Trinidad and Tobago xamount

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.

🇹🇹Trinidad and Tobago 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
🇹🇹Trinidad and Tobago xamount

Just fixing a php code sniffer error.

Attached is the updated patch.

🇹🇹Trinidad and Tobago xamount

Or at least create a variable for it so we don't need to call $this->jsCollectionRenderer->render($js_assets) twice.

🇹🇹Trinidad and Tobago xamount

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.

🇹🇹Trinidad and Tobago xamount

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>
🇹🇹Trinidad and Tobago 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.

🇹🇹Trinidad and Tobago xamount

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

🇹🇹Trinidad and Tobago xamount

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.

🇹🇹Trinidad and Tobago 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.

🇹🇹Trinidad and Tobago xamount

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.

🇹🇹Trinidad and Tobago xamount

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

🇹🇹Trinidad and Tobago xamount

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?

🇹🇹Trinidad and Tobago xamount

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.

🇹🇹Trinidad and Tobago 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

Production build 0.71.5 2024