This appears to be working as the error has gone away
intrafusion → created an issue.
intrafusion → created an issue. See original summary → .
Have you checked the rest of the module for similar depreciations not just these 2 functions?
Also this change requires a merge request rather than an attached patch
intrafusion → made their first commit to this issue’s fork.
intrafusion → created an issue.
This is also affecting us, but locally during development.
In our local logs we found:
NGINX Error: Upstream sent too big header while reading response header from upstream
Further debugging found that one developer altered http.response.debug_cacheability_headers in development.services.yml from true to false, but another developer had to completely disable development.services.yml</code in <code>settings.local.php for these 502 errors to disappear.
Hope this may aid finding where the actual problem lies
intrafusion → created an issue.
intrafusion → created an issue.
intrafusion → changed the visibility of the branch 3362051-cloudflare-php-sdk to hidden.
Zone.php
Endpoints\Zonescalls to https://developers.cloudflare.com/api/resources/zones/methods/list/
CloudFlarePurger.php
I’ve taken a cursorily glance through the code base and it appears the SDK is only called in 2 files:
modules/cloudflarepurger/src/Plugin/Purge/Purger/CloudFlarePurger.phpsrc/Zone.php
So I don’t imagine it’s going to be too much work, I’ll investigate the actual calls and their replacements.
intrafusion → created an issue.
@mably they were fixed in
📌
Fix newly reported phpcs issues in latest pipeline
Active
but I didn't notice as we've had to lock our site to beta2 due to an issue with beta3 and another dependency domain_language
intrafusion → created an issue.
intrafusion → created an issue.
intrafusion → created an issue.
intrafusion → created an issue.
intrafusion → created an issue.
intrafusion → created an issue.
Pacth from #6 converted to MR
We're experiencing the same issue and it's because there are no options for a specific facet hence it's not shown, but the template calls are still firing.
I fully accept that this is probably not the correct solution to the problem, but wanted to to stop these errors being logged
Re-rolled for D11 as code moved into Hook
intrafusion → created an issue.
intrafusion → changed the visibility of the branch 3.0.x to hidden.
intrafusion → changed the visibility of the branch 3.0.x to active.
📌
Coding standards - fix pipeline warnings
Active
- there is no code
📌
Make max_nesting_depth configurable to avoid OOM errors
Active
- needs additional work
If you're introducing new variables there needs to be an update hook to avoid missing data on existing installs
intrafusion → made their first commit to this issue’s fork.
intrafusion → created an issue.
If anyone lands on this issue, I discovered in printable.settings extract_links: '' by changing this to extract_links: 'none' the error went away
I thought I had released the Drupal 11 update, but obviously not!
There aren't any pending MRs at the moment
intrafusion → created an issue.
As per my comment in #5, this has been running for a few weeks on our production system and appears to be working as expected
I’m confused, if this has already been committed the tests passing or failing are irrelevant?
Just need a tagged release to enable the module to be installed
Can we get a tagged release?
It's not possible to upgrade to D11 without one
We have been using this on a production D11 site for approx. 1 month without any obvious issues
@trickfun the patch on it's own is not enough to upgrade, your repositories section of composer.json it should look like:
"repositories": [
{
"type": "composer",
"url": "https://packages.drupal.org/8",
"exclude": [
"drupal/commerce_klarna_payments"
]
},
{
"type": "git",
"url": "https://git.drupalcode.org/issue/commerce_klarna_payments-3506060.git"
}
],
You may have additional repositories so ensure you don't override something else you need. You should then be able to run composer require drupal/commerce_klarna_payments:dev-3506060-support-commerce-3 to install the patched version allowing the upgrade.
Further debugging has discovered a difference between Facets v3 & Better Exposed Filters v7 (required for D11)
After amending 'widget' => '<nowidget>', to 'widget' => ['type' => 'dropdown', 'config' => []], in \Drupal\facets_exposed_filters\Plugin\views\filter\FacetsFilter::getFacet the error is now gone and I can access the settings link against the filter, but it's not possible to change widgets as per https://project.pages.drupalcode.org/facets/exposed_filters/#better-expo...
I get exactly the same error, different line number, when I simply add a facet to the filter criteria. Same error is also generated when I click on settings.
This might be a D11 issue as we've upgraded recently
From looking through the code, \Drupal\schema_metatag\SchemaMetatagManager::encodeJsonld has JSON_PRETTY_PRINT set in the flags for json_encode
Is there any specific reason for this other than for debugging? It would make sense to remove this when caching and/or aggregate CSS/JavaScript is enabled
At this stage I needed this patch to be able to install Drupal 11.
It will be tested further during the next few weeks.
intrafusion → created an issue.
Any chance of a tagged release?
intrafusion → created an issue.
intrafusion → changed the visibility of the branch 3438140-automated-drupal-11 to hidden.
intrafusion → made their first commit to this issue’s fork.
intrafusion → changed the visibility of the branch 8.x-1.x to hidden.
intrafusion → made their first commit to this issue’s fork.
intrafusion → changed the visibility of the branch 3.x to hidden.