I received some feedback out of thread that I investigated. Here's a summary of the feedback:
The header JS renders without issue and consistently; however, the footer JS only renders on the first page load immediately after a Drupal cache rebuild.
The header JS is inserted using hook_page_attachments(), complete with a cache dependency. Simply put, it works as designed. Some wizardry is needed to get the footer JS inserted below other JS. What appears to be happening is that newrelic_get_browser_timing_footer() is getting called multiple times during the same request. If either newrelic_get_browser_timing_header() or newrelic_get_browser_timing_footer() are called more than once during the same request, they'll return an empty string on subsequent requests. I verified this manually.
I'm debating abandoning the service decoration approach and using an event subscriber to alter the DOM directly. I'm also considering modifying ExtensionAdapter::newrelic_get_browser_timing_header() and ExtensionAdapter::newrelic_get_browser_timing_footer() to leverage drupal_static().
Last code push takes a different approach (still using a decorator); however, it uses str_replace() to insert the rendered footer JS into the rendered markup before returning $this->decorated->processAttachments($response). This approach avoids the code duplication issue.
Just pushed code to properly decorate the service. Unfortunately, seven of the methods on the class are protected, so I had to copy/paste them all over to the decorator. (The decorator can't access protected methods on the inner service.) I also added a test to ensure the decorator doesn't break core functionality.
@neclimdul - Drupal's APIs don't provide a way to insert the New Relic footer JS below Javascript inserted by Drupal's Libraries API. NR's docs for manual instrumentation state:
As the very last thing before the closing
</body>tag in the document, or as close to it as possible, insert the return value ofnewrelic_get_browser_timing_footer().
Below is some sample HTML output from a fresh Drupal site. At the very top is where markup is inserted with hook_page_bottom(). At the bottom is code inserted with HtmlResponseAttachmentsProcessorDecorator::processAssetLibraries().
<div>Inserted with hook_page_bottom()</div>
<script type="application/json" data-drupal-selector="drupal-settings-json">{"path":{"baseUrl":"\/","pathPrefix":"","currentPath":"node","currentPathIsAdmin":false,"isFront":true,"currentLanguage":"en"},"pluralDelimiter":"\u0003","suppressDeprecationErrors":true,"ajaxPageState":{"libraries":"eJx9UFuOgzAMvFAgZ9iTVCaZLdaGGNkGltsvRYVqkdqf2PPwKBrKA9ebi5SOND5n6woEeiu1vcxQro7q_237tNPMSWro-H4beUQ8lrCxjl-fqMSs00ilfTFN4fpjny3P-M2kOGRKzjP26yBlW1XiN5BPUGnmOzlLbQxbWCZdT3GUBYrcdGvTFUmvCANp6ptKqrJc2YUzgvWiniY_PnLgYKs5htiRIVxavOIWlmjE16PKMBn0CHvse4sWZsZicX_bQfJU8AduD62d","theme":"olivero","theme_token":null},"ajaxTrustedUrl":{"\/search\/node":true},"bigPipePlaceholderIds":{"callback=Drupal%5CCore%5CRender%5CElement%5CStatusMessages%3A%3ArenderMessages\u0026args%5B0%5D\u0026token=_HAdUpwWmet0TOTe2PSiJuMntExoshbm1kh2wQzzzAA":true,"callback=announcements_feed.lazy_builders%3ArenderAnnouncements\u0026\u0026token=m--BNYDqgTao0j2QoLFf1TwfQN-Bm9xPlckw9QAC1h4":true,"callback=user.toolbar_link_builder%3ArenderToolbarLinks\u0026\u0026token=QPmvukHqpEJJ4rYEzUUFx0ERxrtfmQ9TMOp_hvyLHEk":true,"callback=user.toolbar_link_builder%3ArenderDisplayName\u0026\u0026token=XGROnxBLjNjdNZJ_VcOhVZtenx2tDkIKPfojS_uZFXA":true,"callback=shortcut.lazy_builders%3AlazyLinks\u0026\u0026token=5-XBI-QHgyU_l7Bu0FizHR7YBqK2bTVTBFF8Z0DVTis":true},"toolbar":{"breakpoints":{"toolbar.narrow":"only screen and (min-width: 16.5em)","toolbar.standard":"only screen and (min-width: 38.125em)","toolbar.wide":"only screen and (min-width: 61em)"},"subtreesHash":"DvNlpBZa2F73VL_ZCBelzSCBD08FX9eADzsmGiR_J_o"},"user":{"uid":"1","permissionsHash":"e04100661cd70d74a85410e24e7c918449cfc6bbc6d71bae1bf7fb8fa4d2bd8f"}}</script>
<script src="/core/assets/vendor/jquery/jquery.min.js?v=3.7.1"></script>
<script src="/core/assets/vendor/underscore/underscore-min.js?v=1.13.6"></script>
<script src="/core/assets/vendor/once/once.min.js?v=1.0.1"></script>
<script src="/core/assets/vendor/backbone/backbone-min.js?v=1.5.0"></script>
<script src="/core/misc/drupalSettingsLoader.js?v=10.2.6-dev"></script>
<script src="/core/misc/drupal.js?v=10.2.6-dev"></script>
<script src="/core/misc/drupal.init.js?v=10.2.6-dev"></script>
<script src="/core/modules/contextual/js/contextual.js?v=10.2.6-dev"></script>
<script src="/core/modules/contextual/js/models/StateModel.js?v=10.2.6-dev"></script>
<script src="/core/modules/contextual/js/views/AuralView.js?v=10.2.6-dev"></script>
<script src="/core/modules/contextual/js/views/KeyboardView.js?v=10.2.6-dev"></script>
<script src="/core/modules/contextual/js/views/RegionView.js?v=10.2.6-dev"></script>
<script src="/core/modules/contextual/js/views/VisualView.js?v=10.2.6-dev"></script>
<script src="/core/assets/vendor/tabbable/index.umd.min.js?v=6.2.0"></script>
<script src="/core/misc/progress.js?v=10.2.6-dev"></script>
<script src="/core/assets/vendor/loadjs/loadjs.min.js?v=4.2.0"></script>
<script src="/core/misc/debounce.js?v=10.2.6-dev"></script>
<script src="/core/misc/announce.js?v=10.2.6-dev"></script>
<script src="/core/themes/olivero/js/navigation-utils.js?v=10.2.6-dev"></script>
<script src="/core/themes/olivero/js/checkbox.js?v=10.2.6-dev"></script>
<script src="/core/themes/olivero/js/messages.js?v=10.2.6-dev"></script>
<script src="/core/misc/message.js?v=10.2.6-dev"></script>
<script src="/core/themes/olivero/js/message.theme.js?v=10.2.6-dev"></script>
<script src="/core/misc/ajax.js?v=10.2.6-dev"></script>
<script src="/core/misc/active-link.js?v=10.2.6-dev"></script>
<script src="/core/themes/olivero/js/navigation.js?v=10.2.6-dev"></script>
<script src="/core/themes/olivero/js/second-level-navigation.js?v=10.2.6-dev"></script>
<script src="/core/themes/olivero/js/nav-resize.js?v=10.2.6-dev"></script>
<script src="/core/themes/olivero/js/search.js?v=10.2.6-dev"></script>
<script src="/core/misc/displace.js?v=10.2.6-dev"></script>
<script src="/core/modules/toolbar/js/toolbar.menu.js?v=10.2.6-dev"></script>
<script src="/core/modules/toolbar/js/toolbar.js?v=10.2.6-dev"></script>
<script src="/core/modules/toolbar/js/models/MenuModel.js?v=10.2.6-dev"></script>
<script src="/core/modules/toolbar/js/models/ToolbarModel.js?v=10.2.6-dev"></script>
<script src="/core/modules/toolbar/js/views/BodyVisualView.js?v=10.2.6-dev"></script>
<script src="/core/modules/toolbar/js/views/MenuVisualView.js?v=10.2.6-dev"></script>
<script src="/core/modules/toolbar/js/views/ToolbarAuralView.js?v=10.2.6-dev"></script>
<script src="/core/modules/toolbar/js/views/ToolbarVisualView.js?v=10.2.6-dev"></script>
<script src="/core/misc/tabbingmanager.js?v=10.2.6-dev"></script>
<script src="/core/modules/contextual/js/contextual.toolbar.js?v=10.2.6-dev"></script>
<script src="/core/modules/contextual/js/toolbar/models/StateModel.js?v=10.2.6-dev"></script>
<script src="/core/modules/contextual/js/toolbar/views/AuralView.js?v=10.2.6-dev"></script>
<script src="/core/modules/contextual/js/toolbar/views/VisualView.js?v=10.2.6-dev"></script>
<script src="/modules/contrib/admin_toolbar/js/admin_toolbar.js?sf2suw"></script>
<script src="/modules/contrib/admin_toolbar/js/jquery.hoverIntent.js?sf2suw"></script>
<script src="/modules/contrib/admin_toolbar/js/admin_toolbar.hoverintent.js?sf2suw"></script>
<script src="/core/modules/toolbar/js/escapeAdmin.js?v=10.2.6-dev"></script>
<script src="/core/modules/big_pipe/js/big_pipe.js?v=10.2.6-dev"></script><div id="drupal-live-announce" class="visually-hidden" aria-live="polite" aria-busy="false">Tray "Administration menu" opened.</div>
<script type="text/javascript">console.log("Inserted with HtmlResponseAttachmentsProcessorDecorator::processAssetLibraries()");</script>
Using a decorator preserves the original service and also allows other code to decorate the html_response.attachments_processor, as well.
@jack.minster may wish to weigh in, as well.
@pieterdtt - Thanks for patch #21. I incorporated it into the MR. Based on how New Relic's auto-instrumentation inserts the header JS into <head>, I think the best thing is to always insert the JS there (i.e. no need for placement configuration).
@jack.minster - Could you try out the latest code push to the MR? The header JS is now rendered in <HEAD> near the very top. I also abandoned the library hack for the footer. In HtmlResponseAttachmentsProcessorDecorator, the MR is now modifying the ::processAssetLibraries() method to insert the JS into scripts_bottom, bypassing the #attached types restrictions of ::processAttachments().
@jack.minster - Thanks for that feedback. I'll look into the footer JS insertion issue. I've been doing some work with the test coverage for that piece. One change I've made (but haven't pushed yet) is to execute JS that adds an element to the DOM in the test. The current test results in a false positive.
I do have some work in progress that moves the header JS into <head>.
@jack.minster - Would you mind sending me a DM on my Drupal.org contact form with your contact info and Acquia application docroot?
When I look at a Drupal site where RUM auto-instrumentation is used, I do find the header JS in <head>. I think that's the way to go.
GitLab CI isn't configure for this project yet, so automated tests won't run, but tests are passing locally:
$ ../vendor/phpunit/phpunit/phpunit -c core/ modules/contrib/new_relic_rpm/tests/src/ --verbose
PHPUnit 9.6.15 by Sebastian Bergmann and contributors.
Runtime: PHP 8.1.27
Configuration: /var/www/html/web/core/phpunit.xml.dist
Testing /var/www/html/web/modules/contrib/new_relic_rpm/tests/src
................... 19 / 19 (100%)
Time: 00:04.735, Memory: 8.00 MB
OK (19 tests, 33 assertions)
HTML output was generated
https://d10-lbca.ddev.site/sites/simpletest/browser_output/Drupal_Tests_new_relic_rpm_Functional_AdminUiTest-9-53556339.html
https://d10-lbca.ddev.site/sites/simpletest/browser_output/Drupal_Tests_new_relic_rpm_Functional_AdminUiTest-10-53556339.html
https://d10-lbca.ddev.site/sites/simpletest/browser_output/Drupal_Tests_new_relic_rpm_Functional_AdminUiTest-11-53556339.html
https://d10-lbca.ddev.site/sites/simpletest/browser_output/Drupal_Tests_new_relic_rpm_Functional_AdminUiTest-12-53556339.html
https://d10-lbca.ddev.site/sites/simpletest/browser_output/Drupal_Tests_new_relic_rpm_FunctionalJavascript_InstrumentationTest-5-95610470.html
https://d10-lbca.ddev.site/sites/simpletest/browser_output/Drupal_Tests_new_relic_rpm_FunctionalJavascript_InstrumentationTest-6-95610470.html
Remaining self deprecation notices (3)
1x: user_role_names() is deprecated in drupal:10.2.0 and is removed from drupal:11.0.0. Use \Drupal\user\Entity\Role::loadMultiple() and, if necessary, an inline implementation instead. See https://www.drupal.org/node/3349759
1x in AdminUiTest::testSettingsPage from Drupal\Tests\new_relic_rpm\Functional
1x: user_roles() is deprecated in drupal:10.2.0 and is removed from drupal:11.0.0. Use \Drupal\user\Entity\Role::loadMultiple() and, if necessary, an inline implementation instead. See https://www.drupal.org/node/3349759
1x in AdminUiTest::testSettingsPage from Drupal\Tests\new_relic_rpm\Functional
1x: Method "Symfony\Component\EventDispatcher\EventSubscriberInterface::getSubscribedEvents()" might add "array" as a native return type declaration in the future. Do the same in implementation "Drupal\new_relic_rpm\EventSubscriber\RoutingTransactionNameSubscriber" now to avoid errors or add an explicit @return annotation to suppress this message.
1x in RoutingTransactionNameSubscriberTest::testSetsTransactionNameForAllRoutes from Drupal\Tests\new_relic_rpm\Unit\EventListener
@jack.minster - I'll be interested in feedback you get from your New Relic performance experts.
Re the footer JS, I found that you can control library weights by decorating the html_response.attachments_processor service. I need to clean up my local code, and then I'll push it to the MR.
@jack.minster - Thanks for the feedback! I'm glad to hear the MR code is working for you all.
Re placement of the header JS, I do see that in their documentation, too; however, when I look at their WordPress and Drupal 7 examples, they're calling the newrelic_get_browser_timing_header() inside <body>.
The placement of footer JS is trickier. The MR currently uses hook_page_bottom() to insert the footer JS; however, most JS is loaded after that before the </body> tag. I've tried various methods to address this without success:
1. Call hook_page_attachments() to add a script to scripts_bottom:
function new_relic_rpm_page_attachments(array &$attachments) {
$attachments['#attached']['scripts_bottom'][] = [
[
'#tag' => 'script',
'#attributes' => [
'type' => 'text/javascript',
],
'#value' => 'console.log("test");',
],
'new_relic_rpm_rum_footer',
];
}
This isn't allowed:
LogicException: You are not allowed to use scripts_bottom in #attached. in Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAttachments() (line 150 of core/lib/Drupal/Core/Render/HtmlResponseAttachmentsProcessor.php).
2. Register a library, pass the return value of newrelic_get_browser_timing_footer() via drupalSettings to a JS file, and then pass that value into eval():
new_relic_rpm.libraries.yml:
rum_footer:
js:
js/new-relic-browser-monitoring.js: {}
dependencies:
- core/drupalSettings
new_relic_rpm.module:
function new_relic_rpm_page_attachments(array &$attachments) {
$attachments['#attached']['library'][] = 'new_relic_rpm/rum_footer';
$attachments['#attached']['drupalSettings']['rum_footer']['markup'] = 'console.log("test")';
}
js/new-relic-browser-monitoring.js:
(function (Drupal, drupalSettings) {
Drupal.behaviors.NRRumFooter = {
attach: function (context, settings) {
once('myBehavior', 'html').forEach(function (element) {
eval(drupalSettings.rum_footer.markup);
})
}
};
})(Drupal, drupalSettings);
This executes the JS code in scripts_bottom; however, we can't weight the library with a high value to push the JS insertion to the bottom.
rum_footer:
js:
js/new-relic-browser-monitoring.js:
weight: 999
dependencies:
- core/drupalSettings
Exception:
UnexpectedValueException: The new_relic_rpm/rum_footer library defines a positive weight for 'js/new-relic-browser-monitoring.js'. Only negative weights are allowed (but should be avoided). Instead of a positive weight, specify accurate dependencies for this library. in Drupal\Core\Asset\LibraryDiscoveryParser->buildByExtension() (line 197 of core/lib/Drupal/Core/Asset/LibraryDiscoveryParser.php).
I'm at a bit of a loss. It may not be possible to get that JS code immediately before </body> using Drupal's API. It may be necessary to customize html.twig.html.
That said, if someone could weigh in regarding the placement of the footer JS before/after all of the libraries JS, that would be helpful. It strikes me that we may not get valid browser monitoring results if the footer JS is inserted before the rest of the JS on the page.
Here's a screenshot of the requirements error message, which is added in the MR:
We could run the same compatibility check as in new_relic_rpm_requirements() and return a warning string if the site is configured to allow auto-instrumentation on D10.2.0+.
@neclimdul - Thanks for reviewing this merge request!
1. Are there possibly additional problems with caching with how manual adds adds code? Specifically, is the "header" being added unique to the request? I see the settings tag but should this be a lazy callback or have additional tags to avoid page/render caches?
I'm not aware of any caching-related issues. The two functions, newrelic_get_browser_timing_header() and newrelic_get_browser_timing_footer() are unaware of anything related to the request or the response. In the 7.x branch of this module, they are implemented without any accommodations for caching.
2. In the post update, should it take the Drupal version into account and migrate to manual instead of migrating to a auto that behaves like manual with a not immediately obvious warning? Or maybe it should warn the user during the update? Unsure.
All that the post_update function does is preserve the same behavior following the update. The merge request does add a check to new_relic_rpm_requirements() that alerts site owners about the issue of auto-instrumentation and D10.2.0+.
@vipin.mittal18 - Thank you for your review.
It's not explicitly stated above, but here's the expected behavior for each of the three settings:
Pre 10.2.0
Disable browser monitoring - No JS inserted
Allow auto-instrumentation - JS inserted (assuming auto-instrumentation is enabled on server)
Manual instrumentation - JS inserted
10.2.0+
Disable browser monitoring - No JS inserted
Allow auto-instrumentation - No JS inserted (because auto-instrumentation is incompatible with D10.2.0+)
Manual instrumentation - JS inserted
Is Features configured to export permissions with roles? It sounds like that is the issue.
@Shubham_Kumar - Thanks for testing the module out!
Chris Burge → made their first commit to this issue’s fork.
It sounds like the behavior only presented on existing blocks, which would be the referenced issue; however, the fact that clearing cache and trying a different browser didn't work isn't consistent with prior reports. This module uses core APIs to render the links, so, if there is an issue, it would most probably be a core issue.
I'm wondering if this issue might be the same as #3193067: Manage attributes link not displaying for existing blocks → . @eit2103, can you try the same steps in a fresh browser session (e.g. incognito mode)?
Can you help me understand what you mean by "standard layout builder pages" and by editing "the layout of individual content items"? A screenshot of the latter might be helpful.
@Erik_MC - If your team would be able to test the merge request and report back, that would be helpful in moving the issue forward. The MR is coded based on New Relic's documentation; however, I don't have a New Relic instance to test against myself.
Chris Burge → created an issue.
Chris Burge → created an issue.
Unit tests are passing. The cspell, phpcs, and phpstan failures can be deferred.
Chris Burge → created an issue.
Thanks, @iler!
New Relic updated their docs:
IMPORTANT
Drupal 10.2 introduced a new change → that causes it to set a
content-lengthheader. New Relic PHP agent is unable to auto-inject the browser auto-instrumentation when the HTTP header fieldContent-Lengthis set. To keep using browser monitoring, disable browser auto-instrumentation and manually insert the JavaScript header and footer into your templates.
For manual instrumentation to be enabled, the disable_autorum setting will need to be disabled.
I'm thinking we'd be better off to remove the disable_autorum setting and replace it with a rum_instrumentation settings with three options: disabled, auto, and manual.
I just added config_split as a test dependency to the merge request.
Based on this module's README, it appears that config_split is optional:
When using
config_splitit allows you to dynamically enable and import
configuration from a config split for each of your custom installation
profiles.
@joelpittet - Thanks for trying! I messaged @iler via the user contact form.
Chris Burge → created an issue.
On Acquia Cloud, the soft limit is 60 individual headers and/or a combined total of 23kb of header data. Requests which exceed the soft limit may serve 503 status codes from Varnish and 200 from the Apache backend.
See https://acquia.my.site.com/s/article/360005396494-Varnish-header-limits-.... In this case, there appears to be an underlying application issue.
Let's work from a new issue: ✨ Allow for RUM Manual Instrumentation Needs review .
Chris Burge → created an issue.
@SomebodySysop are you seeing anything in the logs?
Just looking through the code, TextExtractorPluginBase::getRealpath() is of interest to me:
/**
* Helper method to get the real path from an uri.
*
* @param string $uri
* The URI of the file, e.g. public://directory/file.jpg.
*
* @return mixed
* The real path to the file if it is a local file. An URL otherwise.
*/
public function getRealpath($uri) {
$wrapper = $this->streamWrapperManager->getViaUri($uri);
if($wrapper != FALSE){
$scheme = $this->streamWrapperManager->getScheme($uri);
$local_wrappers = $this->streamWrapperManager->getWrappers(StreamWrapperInterface::LOCAL);
if (in_array($scheme, array_keys($local_wrappers))) {
return $wrapper->realpath();
}
else {
return $wrapper->getExternalUrl();
}
}
}
I'm wondering if the method is failing to return a usable value here.
Note: Test coverage passes locally; however, since acquia/cohesion is hosted on GitHub (i.e. not on D.O.), I expect that tests will fail on GitLab CI.
Chris Burge → created an issue.
Chris Burge → created an issue.
Moving to critical. Site builders cannot create or edit text formats. There is no workaround. MR 29 resolves the issue.
Without MR:
- Navigate to https://mysite.localhost/admin/config/content/formats
- Click on Add Text Format
- Observe fatal error
- Navigate to https://mysite.localhost/admin/config/content/formats
- Attempt to configure any text format
- Observe fatal error
With MR:
- Navigate to https://mysite.localhost/admin/config/content/formats
- Click on Add Text Format
- Observe page loads as expected
- Navigate to https://mysite.localhost/admin/config/content/formats
- Attempt to configure any text format
- Observe page loads as expected
It looks like we need to check if $third_party_settings['sections'] is set?
// Loop through entity view displays, sections, and components.
foreach ($view_displays as $display) {
if (!$display instanceof LayoutBuilderEntityViewDisplay) {
continue;
}
if ($display->isLayoutBuilderEnabled()) {
$third_party_settings = $display->getThirdPartySettings('layout_builder');
// Only track the entity type if overrides are enabled.
if ($display->isOverridable()) {
$lb_entity_types[] = $display->getTargetEntityTypeId();
}
foreach ($third_party_settings['sections'] as $section) { // <-- HERE
$components = $section->getComponents();
foreach ($components as $component) {
// Remove 'component_attributes' from 'additional'.
$additional = $component->get('additional');
unset($additional['component_attributes']);
$component->set('additional', $additional);
}
}
$display
->setThirdPartySetting('layout_builder', 'sections', $third_party_settings['sections'])
->save();
}
}
I need to test out the uninstall process due to a change in _layout_builder_component_attributes_uninstall_process_entity_or_revision().
Chris Burge → created an issue.
Chris Burge → created an issue.
Chris Burge → created an issue.
While we're in here, let's address deprecations, too:
Remaining self deprecation notices (195)
45x: The definition for the 'twig_ui.template.node.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
4x in TemplateManagerTest::testGetTemplates from Drupal\Tests\twig_ui\Functional
4x in TemplateManagerTest::testGetTemplatesByTheme from Drupal\Tests\twig_ui\Functional
4x in TemplateManagerTest::testGetTemplate from Drupal\Tests\twig_ui\Functional
4x in TemplateManagerTest::testTemplateExists from Drupal\Tests\twig_ui\Functional
4x in TemplateManagerTest::testSyncTemplateFiles from Drupal\Tests\twig_ui\Functional
...
22x: The definition for the 'twig_ui.template.node_page.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
4x in RenderTest::testRender from Drupal\Tests\twig_ui\Functional
2x in TemplateManagerTest::testGetTemplates from Drupal\Tests\twig_ui\Functional
2x in TemplateManagerTest::testGetTemplatesByTheme from Drupal\Tests\twig_ui\Functional
2x in TemplateManagerTest::testGetTemplate from Drupal\Tests\twig_ui\Functional
2x in TemplateManagerTest::testTemplateExists from Drupal\Tests\twig_ui\Functional
...
21x: assertFileNotExists() is deprecated and will be removed in PHPUnit 10. Refactor your code to use assertFileDoesNotExist() instead.
16x in TemplateManagerTest::testSyncTemplateFiles from Drupal\Tests\twig_ui\Functional
5x in TemplateManagerTest::testDeleteTemplateFiles from Drupal\Tests\twig_ui\Functional
20x: The definition for the 'twig_ui.template.node_event.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
4x in TemplateManagerTest::testSyncTemplateFiles from Drupal\Tests\twig_ui\Functional
2x in TemplateManagerTest::testGetTemplates from Drupal\Tests\twig_ui\Functional
2x in TemplateManagerTest::testGetTemplatesByTheme from Drupal\Tests\twig_ui\Functional
2x in TemplateManagerTest::testGetTemplate from Drupal\Tests\twig_ui\Functional
2x in TemplateManagerTest::testTemplateExists from Drupal\Tests\twig_ui\Functional
...
8x: The definition for the 'twig_ui.template.page.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
4x in InstallTest::testUpdate8101 from Drupal\Tests\twig_ui\Kernel
2x in ImmutableRegistryTest::testGet from Drupal\Tests\twig_ui\Kernel
2x in RegistryTest::testRegistry from Drupal\Tests\twig_ui\Kernel
4x: The definition for the 'twig_ui.template.node_aa.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
4x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
4x: The definition for the 'twig_ui.template.node_ab.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
4x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
3x: The definition for the 'twig_ui.template.test_template.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TemplateFormTest::testForm from Drupal\Tests\twig_ui\Functional
1x in SettingsTest::testDefaultSelectedThemesImplementation from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_a.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_b.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_c.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_d.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_e.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_f.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_g.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_h.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_i.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_j.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_k.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_l.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_m.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_n.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_o.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_p.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_q.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_r.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_s.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_t.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_u.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_v.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_w.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_x.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_y.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_z.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_ac.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_ad.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_ae.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_af.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
2x: The definition for the 'twig_ui.template.node_abc.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
2x in TwigTemplateListFormTest::testForm from Drupal\Tests\twig_ui\Functional
1x: The definition for the 'twig_ui.template.node_duplicate.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
1x in TemplateFormTest::testForm from Drupal\Tests\twig_ui\Functional
1x: The definition for the 'twig_ui.template.disabled_template.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
1x in TemplateFormTest::testForm from Drupal\Tests\twig_ui\Functional
1x: The definition for the 'twig_ui.template.another_template.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
1x in TemplateFormTest::testForm from Drupal\Tests\twig_ui\Functional
1x: The definition for the 'twig_ui.template.clone_node.themes' sequence declares the type of its items in a way that is deprecated in drupal:8.0.0 and is removed from drupal:11.0.0. See https://www.drupal.org/node/2442603
1x in TemplateFormTest::testForm from Drupal\Tests\twig_ui\Functional
1x: assertDirectoryNotIsWritable() is deprecated and will be removed in PHPUnit 10. Refactor your code to use assertDirectoryIsNotWritable() instead.
1x in TemplateManagerTest::testPrepareTemplatesDirectory from Drupal\Tests\twig_ui\Functional
1x: assertDirectoryNotExists() is deprecated and will be removed in PHPUnit 10. Refactor your code to use assertDirectoryDoesNotExist() instead.
1x in InstallTest::testUninstallation from Drupal\Tests\twig_ui\Kernel
Chris Burge → created an issue.
I can confirm that patch #2 addresses the issue. The behavior is reproducible when trying to add a new View field to a bundle.
+1 for cutting a release.
This MR adds tests, and GitLab automated tests aren't configured for this project. Locally, they pass, but only after I install the config_split module:
$ ../vendor/phpunit/phpunit/phpunit -c core/ modules/contrib/profile_split_enable/ --verbose
PHPUnit 9.6.15 by Sebastian Bergmann and contributors.
Runtime: PHP 8.1.16
Configuration: /var/www/html/web/core/phpunit.xml.dist
Testing /var/www/html/web/modules/contrib/profile_split_enable
.... 4 / 4 (100%)
Time: 00:05.004, Memory: 4.00 MB
OK (4 tests, 5 assertions)
Without config_split:
$ ../vendor/phpunit/phpunit/phpunit -c core/ modules/contrib/profile_split_enable/ --verbose
PHP Fatal error: Trait "Drupal\Tests\config_split\Kernel\SplitTestTrait" not found in /var/www/html/web/modules/contrib/profile_split_enable/tests/src/Kernel/Config/StatusOverrideTest.php on line 9
Fatal error: Trait "Drupal\Tests\config_split\Kernel\SplitTestTrait" not found in /var/www/html/web/modules/contrib/profile_split_enable/tests/src/Kernel/Config/StatusOverrideTest.php on line 9
Is config_split just a missing dev dependency or is a hard dependency for this module?
@elber Thanks for opening this issue!
We needed to add the 'administer block content' permission. Also, the route for editing routes changed in D10.1, so to avoid a deprecation notice, that path was updated, too.
With 'field_ui' added as a module dependency for the test, I'm now seeing the following test failure:
$ ../vendor/phpunit/phpunit/phpunit -c core modules/contrib/block_form_alter/ --verbose
PHPUnit 9.6.15 by Sebastian Bergmann and contributors.
Runtime: PHP 8.1.11
Configuration: /var/www/html/web/core/phpunit.xml.dist
Testing /var/www/html/web/modules/contrib/block_form_alter
E 1 / 1 (100%)
Time: 00:12.400, Memory: 4.00 MB
There was 1 error:
1) Drupal\Tests\block_form_alter\Functional\BlockFormAlterTest::testBlockFormAlter
Behat\Mink\Exception\ElementNotFoundException: Form field with id|name|label|value "body[0][value]" not found.
/var/www/html/vendor/behat/mink/src/WebAssert.php:662
/var/www/html/vendor/behat/mink/src/WebAssert.php:695
/var/www/html/web/modules/contrib/block_form_alter/tests/src/Functional/BlockFormAlterTest.php:98
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
ERRORS!
Tests: 1, Assertions: 9, Errors: 1.
@lazzyvn You're welcome to post a patch; however, as I mentioned, this falls outside the scope of this module, so it won't be committed.
That's an interesting use case; however, it falls outside the scope of this module. If you wanted to implement with custom code, you should be able to accomplish that using hook_form_alter() and hook_preprocess_block().
Chris Burge → created an issue.
Since this code won't be committed, I'm going to close as "won't fix", but the issue will still show up in search. It can also be linked from the issue over in Block Class for other looking to make the switch.
@freelock - Thanks for sharing!
All that layout_builder_component_attributes_requirements() does is check if the CssLint\Linter class exists:
/**
* Implements hook_requirements().
*/
function layout_builder_component_attributes_requirements($phase) {
$requirements = [];
if (!class_exists('CssLint\Linter')) {
$requirements['lbca_php_css_lint']['title'] = t('Layout Builder Component Attributes');
$requirements['lbca_php_css_lint']['description'] = t('The neilime/php-css-lint library is required. See README.md.');
$requirements['lbca_php_css_lint']['severity'] = REQUIREMENT_ERROR;
}
return $requirements;
}
You've confirmed the package is correctly downloaded, so the Layout Builder Component Attributes module has done it's part with ludwig.json. It appears that Ludwig may be failing to register the project with the autoloader.
Have you tried clearing Drupal cache?
@cindytwilliams, can you double check the steps to reproduce? When I add a YouTube video, the media entity is created without error.
Here's the code in question:
/**
* {@inheritdoc}
*
* Add timestamp query parameter to derivative images.
*/
public function buildUrl($path, $clean_urls = NULL) {
$file_url = parent::buildUrl($path, $clean_urls);
// Get the file object from its path.
/** @var \Drupal\file\FileInterface[] $files */
$files = \Drupal::entityTypeManager()
->getStorage('file')
->loadByProperties(['uri' => $path]);
/** @var \Drupal\file\FileInterface$file */
$file = reset($files);
$changed = $file->getChangedTime();
$timestamp_query = _static_asset_cache_buster_get_cache_buster_query($changed);
$file_url .= (strpos($file_url, '?') !== FALSE ? '&' : '?') . UrlHelper::buildQuery($timestamp_query);
return $file_url;
}
reset($files) would return FALSE if ->loadByProperties returns an empty array, but that would only happen if the image file doesn't exist in the first place, which shouldn't be possible if code execution has made it this far.
On a related note, this issue introduced a bug, 🐛 ImageStyleDownloadController::deliver() infers source image when generating derivatives with image format conversion Active , which would need to be addressed if we wanted to solve for replacing an image file extension instead of appending it when converting.
@bendale - That's an excellent question. The source of the issue is potential namespace conflicts. Let's say you have image.jpg and image.png. If both are converted to webp, then you have an problem. I've dug into this very issue over the past week and should probably open a new issue against core. I don't have a solution, but I think it deserves its own issue for discussion.
Chris Burge → created an issue.
I just had a customer run into this. Immediately upon upgrading to Drupal 10.1.7, we observed CPU maxed out at 100%, which crashed their hosting stack. The following errors were showing up in the logs:
[20-Dec-2023 12:08:07 America/Los_Angeles] PHP Fatal error: Maximum execution time of 300 seconds exceeded in /mnt/www/html/[omitted]/docroot/modules/contrib/az_blob_fs/src/StreamWrapper/AzBlobFsStream.php on line 592 request_id="v-c9248472-9f72-11ee-9656-cb202b0e421b"
[20-Dec-2023 14:38:51 America/Los_Angeles] PHP Fatal error: Maximum execution time of 300 seconds exceeded in /mnt/www/html/[omitted]/docroot/modules/contrib/az_blob_fs/src/StreamWrapper/AzBlobFsStream.php on line 410 request_id="v-d824acee-9f87-11ee-a31c-4bdba48a437c"
Since the method checking end of file never returns true, it looks like the process just hangs until it eventually times out at 300 seconds (5 minutes). That can quickly lead to proc exhaustion.
Following deployment of patch #2, the errors ceased and application performance returned to normal.
I'm also upgrading the status to critical since this bug has been observed causing application downtime.
Actually.. yes - We're adding a new route, so the cache will need to be rebuilt. Typically, the way I've seen this handled is to add an empty post_update function. Thoughts?
@Anybody - It's all good. The three issues in .install were already there. They're all minor changes. Plus, now there's one less thing to worry about when switching to GitLab CI (which checks coding standards).
While there weren't any coding standards issues with this MR, there were a handful in code:
$ phpcs --standard=Drupal,DrupalPractice web/modules/contrib/fences/ --extensions=php,yml,install,module,twig
FILE: /var/www/html/web/modules/contrib/fences/fences.install
--------------------------------------------------------------------------------
FOUND 1 ERROR AND 2 WARNINGS AFFECTING 3 LINES
--------------------------------------------------------------------------------
83 | ERROR | Doc comment short description must be on a single line, further
| | text should be a separate paragraph
93 | WARNING | Line exceeds 80 characters; contains 90 characters
97 | WARNING | Line exceeds 80 characters; contains 94 characters
--------------------------------------------------------------------------------
FILE: /var/www/html/web/modules/contrib/fences/fences.links.menu.yml
----------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
----------------------------------------------------------------------
4 | ERROR | [x] Expected 1 newline at end of file; 2 found
----------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
----------------------------------------------------------------------
FILE: /var/www/html/web/modules/contrib/fences/fences.module
--------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
--------------------------------------------------------------------------------
10 | ERROR | [x] Use statements should be sorted alphabetically. The first
| | wrong one is Drupal\Core\Field\FormatterInterface.
--------------------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
--------------------------------------------------------------------------------
FILE: /var/www/html/web/modules/contrib/fences/src/TagManager.php
--------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
--------------------------------------------------------------------------------
6 | ERROR | [x] Use statements should be sorted alphabetically. The first
| | wrong one is Drupal\Core\Extension\ModuleHandlerInterface.
--------------------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
--------------------------------------------------------------------------------
FILE: ...r/www/html/web/modules/contrib/fences/tests/src/Kernel/FieldOutputTest.php
--------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
--------------------------------------------------------------------------------
8 | ERROR | [x] Use statements should be sorted alphabetically. The first
| | wrong one is Drupal\entity_test\Entity\EntityTest.
--------------------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
--------------------------------------------------------------------------------
Time: 592ms; Memory: 6MB
Pushed a commit to correct them.
Went ahead and wrote test coverage.
Just pushed fences_requirements(). I'd like to add test coverage in the next few days.
Turns out there is already a issue for the README: #3303084: Add proper documentation for all versions on the module page & README.md → .
Re README.md, there's no README. (Kinda surprised no one has tried to credit farm that yet.) What do you think about opening a new issue for adding a README? We could reference this issue to make sure the new template override behavior is documented in the event the README gets committed after this MR is merged.
Proposed README language re this issue:
## Configuration
By default, the Fences module only overrides the field template (field.html.twig) for core themes. When the 'Override the field template for all themes' setting is enabled, Fences will override the field template for all themes (both core and config).
Re the status warning, what do you think about this?
- Load all active themes.
- For each active theme, search the list of available templates for anything starting with 'field-'.
- List any such templates in a warning returned in
hook_requirements().
This module extends the provider-side of core's oEmbed functionality. If an issue does exist, it's a core issue. Please feel free to open an issue against Drupal core.
Since New Stream doesn't support oEmbed, I'm going to close this ticket as "works as designed'.
@inst - Thanks for reporting back. That's unfortunate that Bandcamp doesn't support oEmbed. I'm going to go ahead and close this one as 'works as designed'.
@kruser - Thanks for reporting back. That is an odd one. I'm going to go ahead and close this one as 'works as designed'.
Grepping Drupal core, I'm finding 98 instances of private properties on test classes and 10,198 instances of protected properties. I understand that test classes aren't considered part of Drupal's public API, but if Drupal actually wanted to enforce this, they'd declare test classes as final. I plan to open a core MR requesting the properties on ProviderRepositoryTest be changed to protected.
Based on §3.2.2 of RFC-3986, the inferred minimum character limit does appear to be 1 (not 2). I'm agreeable to fixing that here, but it makes me wonder if there's a bug in core's Drupal\Component\Utility\UrlHelper::isValid().
This project has moved from Drupal CI to GitLab CI, so we can't run tests on patch files anymore. @_m - Could you open a MR?
The link should appear if the following conditions are met:
- the bundle is Layout Builder-enabled
- overrides are allowed
- user has necessary permissions
The module uses the 'access_manager' services to check access to the layout_builder.overrides.$entity_type_id.view route. If the access check passes, then the operation link is rendered.
This feels like a duplicate of #2989338: SchemaMetatagManager::encodeJsonld Should Allow for HTML → .
Based on the endpoint URL and asset URL, the following request should return an oEmbed resource: https://oembed.bandcamp.com/oembed?url=https://smallville-records.bandca...
It returns a 404. @inst Can you confirm Bandcamp.com support oEmbed?
Chris Burge → created an issue.