Single directory components (SDC) is a new way to theme Drupal. Instead of scattering related files around your theme, they're contained to one directory. The primary issue for SDC is at #3313520: Single directory components in core.
The Demo Umami team has decided that their theme can depend on an experimental module like SDC. This allows us to have the work in this ticket merged even when #3352256: [META] Move code from the experimental SDC module to core is not committed.
#2958241: Impossible to reply to comments: commented entity considered unreferencable because CommentSelection::entityQueryAlter() joins on {node_field_data} table causes a regression when you have a comment reference on a non-comment entity type. Our use case is a contact form allows to report a comment and references that comment. This is a fatal now on 9.5 and worked on 9.4, so I think this is major if not critical, only reason it's not is that it might be a bit an obscure use case.
1. Add a comment field anywhere, for example on a node type
2. create such an entity, reference a comment, save.
Check that the context entity really is a comment. That's more a workaround though, I'm not sure what should happen in such a case, I didn't look into what exactly the purpose of this check even is.
This is part of the CSS modernization initiative.
The stylesheet at https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/claro/css/components/form--select.pcss.css needs to be refactored to make use of modern CSS and Drupal core's PostCSS tooling.
Use CSS Logical Properties where appropriate
Use CSS nesting where appropriate
We need two patches. One for Drupal 9.5.x and one for Drupal 10.0.x
We need a followup issue to refactor this component in Drupal 10.0.x to make use of component-level CSS custom properties and remove IE specific style definitions.
None. There should be no visual differences.
This is part of the CSS modernization initiative.
The stylesheet at https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/claro/css/components/form--checkbox-radio.pcss.css needs to be refactored to make use of modern CSS and Drupal core's PostCSS tooling.
Use CSS Logical Properties where appropriate
Use CSS nesting where appropriate
We need two patches. One for Drupal 9.5.x and one for Drupal 10.0.x
We need a followup issue to refactor this component in Drupal 10.0.x to make use of component-level CSS custom properties and remove IE specific style definitions.
None. There should be no visual differences.
This is part of the CSS modernization initiative.
The stylesheet at https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/claro/css/components/fieldset.pcss.css needs to be refactored to make use of modern CSS and Drupal core's PostCSS tooling.
Use CSS Logical Properties where appropriate
Use CSS nesting where appropriate
We need two patches. One for Drupal 9.5.x and one for Drupal 10.0.x
We need a followup issue to refactor this component in Drupal 10.0.x to make use of component-level CSS custom properties and remove IE specific style definitions.
None. There should be no visual differences.
To evaluate splitbuttons from the MR, enable the splitbutton_test module and go to
/splitbuttons
. You must have
$settings['extension_discovery_scan_tests'] = TRUE;
in your settings.php for this test module to be available.
Since we cannot change the current Dropbutton (and Operations) implementation for BC reasons, the way to move on is:
Create a new Splitbutton element with the required markup, functionality and (accessibility) features.
Splitbutton is a slightly different experience than dropbutton. Dropbutton has a primary item that is always visible. Although it's a primary item, it's semantically part of the the list that is fully visible when the dropbutton is open.Seven Dropbutton Seven no longer in core
Claro Dropbutton
Claro is styled so the primary and list items look different although they are part of the same list. This visually resembles what splitbutton will be doing semantically.
Seven Splitbutton Seven no longer in core
Claro Splitbutton
Uses Claro's existing component styles, applied to this new element.
TBD.
I think that I have discovered a bug or documentation issue in the view mode caching while developing a module that allows users to configure view modes in domain access for individual domains.
Background
The module adds additional view modes per domain per existing view mode. So for the full view mode for the node entity, it creates additional modes "Full (domain a)", "Full (domain b)", etc.
Since this was generating a large number of view modes, I have given the users options to disable certain domains from generating additional domains. When saving these settings, I do a entity_info_cache_clear() and cache_clear_all().
Issue 1: Removing a view mode defined in hook_entity_info_alter() that was enabled.
The view mode correctly no longer appears in "Custom display settings".
Issues:
Issue 2: Re-adding the removed view mode via hook_entity_info_alter().
On the display settings, the re-added view mode appears in the "Custom display settings" again.
Issues:
Resolution
This is the final solution that resolved the issue; Clearing the field, entity, general cache and rebuilding the menu.
/**
* Clears the cached entity info so that the new view modes are updated.
*/
function domain_view_modes_settings_submit($form, &$form_state) {
// Update the entity view modes.
entity_info_cache_clear();
// Clear field caches.
field_cache_clear();
// Clear the caches in case the view modes change these.
cache_clear_all();
// Fix the remaining secondary tabs in case a view mode is deleted.
menu_rebuild();
}
Adding a menu_rebuild(); to entity_info_cache_clear() was going to be my first purposed solution to this issue. but I'm think that simply documenting this in entity_info_cache_clear(); would be enough. Due to the overhead of the first, I would go with the second personally, but I would prefer a core maintainer to make this decision.
Running the former through testbot to see what happens and a stab at the documentation in the other.
Whoops....
This is normal, internal URL:
/drupal7x/node/1
This is alias URL
/drupal7x/test
according to url function, alias is set to FASLE by default, BUT:
(dpm output)
url('node/1') => /drupal7x/test
url('node/1', array('alias' => TRUE)) => /drupal7x/node/1
url('test') => /drupal7x/test
url('test', array('alias' => TRUE)) => /drupal7x/test
Looking back in history:
D5 return TRUE
D6 return TRUE
D7 return TRUE
Core Usages of url [590 occurrentces], seems like it may affect a lot of place and modules.. hope im wrong..
Attached 2 patch, one is fixing the bug, 2nd is turn into TRUE by default.
A "virtual" field is a field that does not exist in the database but is exposed to other systems that call the schema. They are used by Views to support fields such as "link to node". Adding support for them in Schema API is a prerequisite for Views being able to leverage Schema API and reduce a lot of its own code requirements.
We currently have various identifiers for a translatable UI string:
1. The source string itself is used as a key for the lookup.
2. If the source string has an optional context assigned, that is part of the key.
3. Source strings can be put into textgroups, which are also part of the lookup key making strings unique in textgroups. This was implemented to support arbitrary configuration translation but turned out to be a *very bad* idea and is being removed in #1188430: Rip out textgroup support from locale module.
4. Finally, there is a location field that is only used once as a key, when generating JS translation files (for strings used in JS).
Unfortunatelt the location information from 4 is used very inconsistently. It can be one of three things:
A) a file path to the file it was extracted from (for full blown .po file imports)
B) empty (probably most common) for localize.drupal.org sourced .po files
C) .js file name for strings coming from a JS file (this is similar to A but has a very special meaning)
D) a web path where the string was first identified
In practice, people might be interested in either of these to help their translation efforts. However, the inconsistent use of location information makes it pretty hard to rely on the value for location in any meaningful way. Breaking this discussion out of Jose's explanation at http://drupal.org/node/1188430#comment-4626010
The query performed in menu_contextual_links() that fetches all router items (e.g., node/%/edit) for a certain base router path (e.g., node/%) always leads to the same result for a certain path.
It easily can be cached, which further reduces the queries performed when putting 'cache_menu' in a fast cache backend.
The default action on /admin/content is "Delete selected content". It's really easy to push "Apply" button by mistake, thinking it will apply the filter, because of the button title, and because it's positioned at the bottom of the form, typically where people expect to look for submit buttons. (This actually happened to me today, and I've been using Drupal for 8 years)
See screenshots.
Initially, adding a weight to action config entities has been tried. However, as is mentioned in #152, this is not the correct approach as an action (read a config entity) may appear on several views and the site builder may need different sort orders on each view. Read the #152 comment for more background.
None.
Before:
The checkboxes let you select which actions will be available, but you cannot control the order.
After:
The form element used to select the actions is converted from checkboxes to draggable table. The table allows both, actions selection and action reordering.
The actions are reordered for new sites on /admin/content, /admin/content/comment, /admin/content/comment/approval, /admin/content/media with the "Delete" action as last option.
Before:
After:
None.
New actions_order option for Bulk Form handler.
Use drag and drop in Views bulk form field configuration form to define order which will be used to expose the actions in the bulk forms.
Entity types can define now plurals for their labels starting with #1850080: Entity type labels lack plurality, cannot generate UI text based on label if plural is needed. It's possible now to have the variants "content item" (singular) and "content items" (plural) for nodes. We want the same for bundles. We want to be able to have "article" (singular) and "articles" (plural).
It's not the same as for entity types. Entity types can define the label plural variants in the annotation while for bundles the site builder should be able to add such variants. Thus we need to store the variants in the bundle config entity and provide UI for site builders.
Create the foundation that allows bundle config entities to store plural labels and add this ability to the node_type bundle entity as a start.
EntityBundleWithPluralLabelsInterface that defines 6 new methods:
setSingularLabel()getSingularLabel()setPluralLabel()getPluralLabel()setCountLabel()getCountLabel()These are similar to those implemented to entity types.
EntityBundleWithPluralLabelsTrait, to be reused in most of the bundle config entities.bundle_entity_with_plural_labels schema to be used by bundles that want to support plural labels. The new schema contains the new storage keys: label_singular, label_plural, label_count.1 article\x03@count articles.1 article was found\x03@count articles were found. Note that we cannot build this version by deriving from the first one because of the was/were thing.<span>1</span> article\x03<span>@count</span> articles.<div ...> or even is rendered in a different theme hook, just Article\x03Articles, without the count part.Similar with translated strings, were we are able to store contextualised translations and then retrieve them by passing the context identifier, we allow label_count to store multiple versions, identifiable by a context string identifier.
hook_entity_bundle_info(), are able to declare such labels by using the keys: label_singular, label_plural and label_count. This will be documented in entity.api.php [see #108, #109].hook_entity_bundle_info(), are able to process the count label, given a count, by using the new service method entity_type.bundle.info::getBundleCountLabel(). This is a new method exposed by EntityTypeBundleInfoInterface [see #108, #109]NodeTypeInterface extend also EntityBundleWithPluralLabelsInterface.NodeType use the EntityBundleWithPluralLabelsTrait trait.node.type.* schema extend bundle_entity_with_plural_labels.None. The UI changes are split in #2938251: Allow edit of bundle plural labels in the node type form.
New interface \Drupal\Core\Config\Entity\EntityBundleWithPluralLabelsInterface:
setSingularLabel()getSingularLabel()setPluralLabel()getPluralLabel()setCountLabel()getCountLabel()The node type bundle config entity has new keys/values: label_singular, label_plural, label_count.
Postponed on #2998451: Toolbar tray rendering can result "flickering" resizing of content area to accommodate open trays
#2998451: Toolbar tray rendering can result "flickering" resizing of content area to accommodate open trays👈 this issue included the addition of inline JavaScript to <head> so it could load before anything on the page was rendered. This resulted in a less visually jarring toolbar initialization.
The JS is currently added via toolbar_page_attachments(), adding a script tag to $page['#attached']['html_head']. Unlike most Drupal JavaScript, the JS code is not in a dedicated file, but created as a HEREDOC variable. It's not the most elegant DX, but it got the job done. We'd like to find a better approach.
Some things that were tried:
header: true, which was decided against as it adds an additional JS request, even when assets are aggregatedtoolbar_page_attachments(), write the contents to a string, which would ultimately become the content of the newly added script tag. This was decided against as it would result in loading a file from the filesystem on every request. This could potentially be addressed by using FileCacheFactory, but best explored in a dedicated issue such as this instead of blocking the anti-flicker enhancements provided by #2998451When trying to refactor ModuleHandler in #3368812: Hux-style hooks, proof of concept, I noticed that some bugs or changes of behavior introduced into the ModuleHandler did not cause ModuleHandlerTest to fail, while other tests did fail.
This means that Drupal\Tests\Core\Extension\ModuleHandlerTest is incomplete in its coverage of Drupal\Core\ExtensionModuleHandler.
I also noticed a heavy reliance on mocking protected methods. It would be nice to avoid or reduce that.
Look at failed runs in the other issue #3368812.
Add more cases in ModuleHandlerTest.
With #3294720: The attachBehaviors() for document is only called after Big Pipe chunks are processed the Drupal Behaviors are being applied for entire page twice.
This causes, that states' rules are initiated multiple times and this causes that states sometimes works unexpected if BigPipe is available.
Create a form containing complex states logic:
$form['option'] = [
'#type' => 'radios',
'#title' => 'Option',
'#options' => [
'option_1' => 'option_1',
'option_2' => 'option_2',
],
'#default_value' => 'option_1',
'#required' => TRUE,
];
$form['variant'] = [
'#tree' => TRUE,
];
$form['variant']['option_1'] = [
'#type' => 'radios',
'#title' => 'Variant for option_1',
'#options' => [
'variant_1' => 'variant_1',
'variant_2' => 'variant_2',
],
'#default_value' => 'variant_1',
'#required' => TRUE,
'#states' => [
'visible' => [
':input[name="option"]' => ['value' => 'option_1'],
],
],
];
$form['variant']['option_2'] = [
'#type' => 'radios',
'#title' => 'Variant for option_2',
'#options' => [
'variant_1' => 'variant_1',
'variant_2' => 'variant_2',
],
'#default_value' => 'variant_1',
'#required' => TRUE,
'#states' => [
'visible' => [
':input[name="option"]' => ['value' => 'option_2'],
],
],
];
foreach($form['option']['#options'] as $option_key => $option_title) {
foreach($form['variant'][$option_key]['#options'] as $variant_key => $variant_title) {
$key = $option_key . '__' . $variant_key;
$form['info'][$key] = [
'#type' => 'container',
'#states' => [
'visible' => [
':input[name="option"]' => ['value' => $option_key],
':input[name="variant[' . $option_key . ']"]' => ['value' => $variant_key],
],
],
'text' => [
'#markup' => 'info for option ' . $option_title . ' variant ' . $variant_title,
],
];
}
}
And for visitor with BigPipe enabled (f.e logged in) the first click on any radio button will lead that text line will not be visible at all.
Other clicks on any radio will work as expected.
Use `once` to select element with defined states to apply them.
I was surprised to find that the new hooks to act on module status changes (#253569: DX: Add hook_modules to act on other module status changes) live in the main module file.
Would there not be optimization in putting them in the install files?
ack "Implements? hook_modules_" gets me 12 functions in 5 module files.
The tradeoff would be having to load all install files when modules' statuses are changed - slimming everyday actions at the expense of fattening a rare action.
Follow up from #2982949: Introduce CallableResolver to help standardise the DX and error handling for callbacks across various subsystems. We should use CallableResolver for \Drupal\Core\Render\Renderer::doCallback()
When settings a filtered text are marked as disabled. The CKEditor acts as normal.
I have tested this on CKEditor 4 and it acts as expected and the editor is not editible.
Since this is on Drupal 9.5.x we are able to run both CKEditor 4 and 5, so I have duplicated the full html filter to create the ckeditor5 filter. and then I can test both to show the issue.
CKEditor 4 disabled.
CKEditor 5 disabled.
/**
* Implements hook_form_BASE_FORM_ID_alter().
*/
function example_form_node_page_form_alter(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) {
$form["body"]["widget"][0]["#disabled"] = TRUE;
$form["body"]["widget"][0]["#format"] = 'ckeditor5_filter';
}
When adding a new entity to the system, the ability to log a revision message makes very little sense, and in some cases, e.g. media, the visual prominence is overwhelming and takes attention away from the task at hand.
Proposal from @rlnorthcutt: Let's only show this on content/media/etc. edit instead.
Before
After
Before
After
Before
After
