Test for aggregator module are scattered around in other modules. We need to consolidate these tests into the modules directory (core/module/aggregator) and into the modules namespace.
This way it will be easier to move the current Core module almost as-is to the Contrib realm
Move all tests to the aggregator module.
Move all tests to aggregator module.
At narrower screen widths, select form field values can disappear in Claro theme. Example:
Visible values at average width:
At a narrow width, the select element is too narrow and the values are hidden:
Update the CSS to handle narrower widths.
Select form field values will be shown at narrower screen widths.
Drupal.behaviors.verticalTabs and Drupal.verticalTab[.prototype] add some additional classes and wrapper elements to the vertical tabs component. Currently it isn't possible to override the classes or the wrapper elements without duplicating all of the logic inside the function in a theme.
Drupal.behavior.verticalTabs and Drupal.verticalTab object hard-code markup of the tab list and (the outermost) wrapper of the vertical tabs component.Drupal.verticalTab object is built on the same (unprefixed) CSS classes that should be used only for theming the component.Replace hard-coded markup with Drupal.theme functions and adds 'js-' prefixed CSS classes for the JavaScript functionality:
tabList:Drupal.theme.verticalTabsMenuListWrapper = () =>
'<ul class="vertical-tabs__menu"></ul>';Drupal.theme.verticalTabsWrapper = () =>
'<div class="vertical-tabs clearfix"></div>';.js-vertical-tabs-pane to the vertical tabs' details elements and use that CSS class for functionality..js-vertical-tabs-menu-item to the themed output of the vertical tabs menu item (Drupal.theme.verticalTab()) and use that CSS class for functionality..js-vertical-tab-hidden (with vertical-tab-hidden) to the hidden vertical tabs details element and use that CSS class for identifying hidden tabs.@todo
#3227033: [PP-3] Remove quickedit from core is trying to remove quickedit from core. Before we can do that, we need all of its parts moved under the quickedit module, instead of having integrations sprinkled throughout the rest of core. \Drupal\image\Controller\QuickEditImageController needs to move from image to quickedit and be refactored.
Greetings! I am running into an issue porting a module to Drupal 8 that uses the Field API. The issue is that the value my field provides is stored as a string, but at validation time, it is composed of several values that will be coerced into a string during preSave. Since it looks like TypedDataManager places the PrimitiveType constraint on all fields which extend FieldItemBase, it causes PrimitiveTypeConstraintValidator to run against your field, even if you specify a custom constraint in the @FieldType annotation.
I'm attaching a patch that will help to describe the problem by proposing a simplistic solution. I don't know if this is robust enough, but it should at least illustrate the problem a little better. The suggestion is for TypedDataManager::getDefaultConstraints() to not add the PrimitiveType constraint to all primitive types. Rather, let the fields define the constraint themselves.
Thanks!
Per discussion in #2942096: [policy, no patch] Remove old update hooks prior to each major version (Drupal 10 and later), and discuss what to do with \Drupal::CORE_MINIMUM_SCHEMA_VERSION, we should remove all hook_update_N() and hook_post_update_NAME() up until 9.3.0 (i.e., any updates added since 9.3.0 should remain in core).
This will break test coverage, so we'll need to remove tests for specific updates and update the generic update path tests and database dumps to start on a 9.3.0 database (this could be the existing dump(s), updated, then dumped again).
1. Remove all updates and post updates added to core prior to 9.3.0, anything since 9.3.0 stays in.
2. Implement hook_removed_post_updates() and hook_update_last_removed().
3. Update the bare and standard database dumps to 9.3.0 (by loading them on a 9.3.0 site then dumping them again)
4. Remove the 9.0.0 database dump since we don't have two 'base' versions to update from.
6. Removes test coverage and fixtures for all the specific update tests + fixtures (but not any helpers, those can be removed in deprecation removal patches)
#3261629: Database dumps are no longer driver-agnostic needs to land first.
Data updates added prior to 9.3.0 have been removed from Drupal 10.0.x. To update to Drupal 10, you must first ensure your site is running Drupal 9.3.0 or a later release. We recommend updating to the most recent core 9.x release, as well as updating all of your contributed modules to their latest releases, prior to updating to Drupal 10.
When importing existing configuration during site install, importing translated strings is very slow
Drupal\local\Gettest::fileToDatabase generates a call to Drupal\locale\PoDatabaseWriter::importString for each string which is then individually written to the database - in my case, for 6 languages, this caused an additional 51,000+ database writes on install and the installer takes around 10m to complete.
Support adding more than 1 translated string at a time to the database
tbd
tbd
tbd
If page does not have "X-Acquia-Site" header set then Varnish is not able to purge cache for that page on tag invalidation.
So can we create a patch for Dynamic Cache Module so that it will never set "X-drupal-dynamic-cache" header as "UNCACHEABLE" for anonymous user?
diff --git a/core/modules/dynamic_page_cache/src/EventSubscriber/DynamicPageCacheSubscriber.php b/core/modules/dynamic_page_cache/src/EventSubscriber/DynamicPageCacheSubscriber.php
index 22b51b9e..4e961b44 100644
--- a/core/modules/dynamic_page_cache/src/EventSubscriber/DynamicPageCacheSubscriber.php
+++ b/core/modules/dynamic_page_cache/src/EventSubscriber/DynamicPageCacheSubscriber.php
@@ -165,7 +165,8 @@ class DynamicPageCacheSubscriber implements EventSubscriberInterface {
}
// There's no work left to be done if this is an uncacheable response.
- if (!$this->shouldCacheResponse($response)) {
+ // Do not set uncacheable for anonymous user.
+ if (!\Drupal::currentUser()->isAnonymous() && !$this->shouldCacheResponse($response)) {
// The response is uncacheable, mark it as such.
$response->headers->set(self::HEADER, 'UNCACHEABLE');
return;
When using the linkit, it is possible to use linkit also on the link button in CKEditor. In this case, the default link field is replaced with an autocomplete field. The results window has a maximum size; if many results are returned by linkit, a scrollbar is displayed.
This does not work when using Claro as the admin theme, as the scrollbar is hidden. Hence, only the first 8 / 12 results are displayed to users; all the other results are hidden.
The results will be displayed like this:
Remove overflow: hidden in .ui-autocomplete.
The scrollbar will now be displayed also for autocomplete fields.
I've created route with method - POST and full access. When I create request drupal retrieve me 403 forbidden error. maybe someone knows what might be the problem?
siftandpick_payment.default_controller_getValue:
path: '/payment/get'
defaults:
_controller: '\Drupal\siftandpick_payment\Controller\DefaultController::getValue'
_title: 'getValue'
methods: [POST]
requirements:
_access: 'TRUE'As a part of the new Design System for the default administration user interface for Drupal, the Claro theme should be tied to some kind of living Style Guide.
Some questions to solve are:
- Should it be only for Claro or for the whole Design System?
- Should it live in core’s code, an external library/module/app or should it be accessible from the web like https://material.io ? (or several)
Is it reasonable to ask to add support for .FLAC and .AAC audio type of file with HTML 5 audio player?
Is it scheduled? Does it ask a lot of dev?
the problem i face is that i use mediaelement.js as audio player and i can play flac and aac with it on front end. the problem is that in the backend if i render audio file with the native drupal player audio, the player audio display for mp3, wav and ogg, but dont display for flac and aac. i dont want to use the mediaelement.js in the backend.
So \Drupal\Core\Theme\ThemeManager::render() provides the ability to convert 'attributes', 'title_attributes', 'content_attributes' variables into Attribute objects before they get passed into the Twig template:
if (!isset($default_attributes)) {
$default_attributes = new Attribute();
}
foreach ([
'attributes',
'title_attributes',
'content_attributes',
] as $key) {
if (isset($variables[$key]) && !$variables[$key] instanceof Attribute) {
if ($variables[$key]) {
$variables[$key] = new Attribute($variables[$key]);
}
else {
// Create empty attributes.
$variables[$key] = clone $default_attributes;
}
}
}
I'm finding that as I create custom render elements and templates for an organization's design system integration in Drupal, I commonly have a need for additional variables in my templates to be converted from an array to an Attribute object for use in Twig. Right now I have to do this myself:
/**
* Implements hook_theme().
*/
function design_system_theme($existing, $type, $theme, $path) {
return [
'design_system_content_teaser' => [
'render element' => 'element',
'variables' => [
'attributes' => [],
'heading' => NULL,
'heading_attributes' => [],
'intro' => NULL,
'button' => [],
],
],
];
}
/**
* Preprocess variables for design system content teaser templates.
*/
function template_preprocess_design_system_content_teaser(array &$variables) {
$variables['heading_attributes'] = new Attribute($variables['heading_attributes']);
}
I think there are two options:
function design_system_theme($existing, $type, $theme, $path) {
return [
'design_system_content_teaser' => [
'render element' => 'element',
'variables' => [
'attributes' => [],
'heading' => NULL,
'heading_attributes' => [],
'intro' => NULL,
'button' => [],
],
'attribute variables' => [
'heading_attributes',
],
],
];
}
None
This would be a feature-addition to hook_theme().
ContextAwarePluginBase was deprecated in #2273381: Convert ContextAwarePluginBase to traits.
However, only a runtime deprecation was added. The class phpDoc was not updated to include a @deprecated tag. This prevents it from being picked up my PHPStan's deprecation rules or other static analysis tools.
Scan code extending the class using phpstan + phpstan-drupal + phpstan-deprecation-rules (aka drupal-check or upgrade_status). No error about a class extending this base class.
Add @deprecated
If a page using the DraggableListBuilder is empty, we still show the 'Save' button. I was confused because there is nothing to save as there is nothing to re-order.
Having a really long HTML tag (e.g. < img > with src:data/image...) makes preg_split fail and return false. On PHP 7.4 this throws a warning ("Warning: count(): Parameter must be an array or an object that implements Countable in _filter_url() (line 535 of core/modules/filter/filter.module).") and makes the field render empty, on PHP 8.0 this throws a fatal error.
1) Have a node with content like this: https://gist.github.com/kporras07/618b3bf4cd77ff57fcd5034262220e99
2) Visit the node
3) You will get the warning and empty node or the fatal error depending on your PHP version
Wrap the for inside an if to avoid triggering this error.
1) Provide a patch
2) Review the patch
3) Commit :)
None
None
None
Probably not needed
In #2962525: Create a field widget for the Media library module, the media edit/view link was disabled in the field widget and widget view in order to prevent unintended data loss. Long term, we would still like the ability to quickly edit media items from the field widget, without navigating to a new page.
Allow media items to be edited in a modal while using the field widget. The Entity Browser module allows for similar functionality.
This has some major UX and possibly a11y implications, since it needs to be crystal clear to users that, if they edit a media item in the library, they are editing that item everywhere it appears.
Undecided.
None.
None.
When trying to update the database I get the following issue report:
[error] SQLSTATE[42000]: Syntax error or access violation: 1075 Incorrect table definition; there can be only one auto column and it must be defined as a key: ALTER TABLE "users" DROP PRIMARY KEY; Array
[error] Update failed: user_update_9301
[error] Update aborted by: user_update_9301
[error] Finished performing updates.
What can I do to fix this?
In #3192487: Warn about upcoming JSON database support requirement in Drupal 9 we added a requirements check. Here, we are making Drupal installation fail on Drupal 10 is JSON is not supported by the database.
Update the list of checked SQL commands.
TBD
None
None
None
TBD