When creating the image style and hover on the anchor instead of hovering over the particular box it is showing a hover effect on the whole row.
Steps to Reproduce
For example Hovering on A11 Brings hover effect on A12 and A13 also
Fix CSS.
Browser tests
minimal, better spacing when breadcrumb block is disabled on admin pages
none
none
See #2746541-400: Migrate D6 and D7 node revision translations to D8
#2746541-403: Migrate D6 and D7 node revision translations to D8
#2746541-405: Migrate D6 and D7 node revision translations to D8
It is possible that this happens with draft revisions, for example when workbench moderation is used.
Discovered at #2972224: Add .cspell.json to automate spellchecking in Drupal core, and pointed by @xjm in https://www.drupal.org/project/drupal/issues/3122088#comment-13628724
+++ b/core/.cspell.json
@@ -0,0 +1,1288 @@
+ "Deduplicates",
...
+ "Reimplement",
...
+ "Reparenting",
...
+ "Rerender",
+ "Resaving",
+ "Rethrown",
+ "Reuploading",
...
+ "Unassigns",
...
+ "Unclickable",
+ "Ungroupable",
+ "Ungrouped",
+ "Unhide",
...
+ "Unknow",
...
+ "Unpad",
...
+ "Unprefix",
...
+ "Unrouted",
...
+ "deprioritize",
...
+ "reimplementing",
+ "reindex",
+ "reindexing",
+ "reinitializes",
+ "reinject",
...
+ "renormalize",
+ "reparenting",
...
+ "rerender",
+ "rerendered",
+ "rerendering",
+ "resaved",
+ "resaving",
...
+ "rethrown",
...
+ "undecorate",
...
+ "ungroup",
+ "ungroupable",
+ "ungrouped",
+ "unhashed",
+ "unhide",
+ "unindented",
+ "unindexed",
...
+ "unitalicize",
+ "unkeyed",
...
+ "unpermissioned",
...
+ "unrendered",
...
+ "unshortened",
+ "unsanitized"
+
@xjm:Should be hyphenated (un-assign, de-prioritize, re-render, etc.)
There's an interesting question of where to draw the line for these. Generally in English these prefixes are morphologically productive with a hyphen, and get de-hyphenated when the word is adopted into common usage. "Denormalize", "Unsanitized", "Uninstantiated" etc. are all obviously in common usage in programming. "Unsticky", "Unrevisionable", and the like are Drupal terminology, and I'm surprised that "unpublish" and friends aren't already in the main dictionary.
As title and see the change record https://www.drupal.org/node/3122084 for how to work with cspell.
Pick out all applicable words from #2972224: Add .cspell.json to automate spellchecking in Drupal core and fix them.
In a fresh install of Drupal 8.8.5, when adding an exposed filter using the criteria of "Has taxonomy term", the field is twice as wide as all other fields that are exposed. I have attached images. The default character length in most text based fields is 30 but in "has taxonomy term" it is set at 60. This makes the filter region look like ... you know.
I know I have to find a way to make a sub theme just to fix that one little item, but the more I thought about it is a minor bug and one that is easily fixed in Core.
See attached files
To reproduce this issue, view the html in #9 in IE11.
In IE11, any element set to display: flex; can receive focus by being clicked. This has been narrowed down to an IE bug, but one that has very little evidence of it existing online because it is only noticeable if stylesheets include rules that provide focus outlines to non-interactive elements. This is the case with Claro's :focus styles, as they are are applied as *:focus, impacting all elements. This can result in the green focus ring appearing in unexpected places.
The bug does not result in making these elements tabbable via tab navigation, but clicking on one of these non-interactive-but-focusable elements will take focus away from another element .
Any number of CSS rules could address the problem.
The @todo refers to the issue #2076085: Resolve the need for a 'title callback' using the route. Its resolution was fixed:
Remove the @todo
None.
None.
None.
Neither EntityFormDisplay nor EntityViewDisplay have a label key, and as such their ::label() method returns NULL.
Implement ::label(), returning a string indicating which entity type, bundle, and view mode are represented.
Decide on the string to present and then use it in the Field UI.
Steps to check the label with the Layout builder module installed first:
Node:【Structure】->【Content types】->【Article】->【Manage Display】->【Default】/【Teaser】mode ->【 Use Layout Builder】->【Manage Layout】
User:【Configuration】->【Account Settings】->【Manage Display】->【Default】mode ->【 Use Layout Builder】->【Manage Layout】
Elements inside a form-item can cause unwanted overflow to happen (see screenshot).
Path: admin/content
Patch follows.
Sample entity value generation generates long strings for text fields. This can cause the layout to break, as noted in #3016507: Break long text strings in layout edit
Rather than use \Drupal\Component\Utility\Random::word, which often generates very long words, use \Drupal\Component\Utility\Random::paragraphs, which uses words from a selection of shorter words.
Write a patch.
None-ish.
None
None
Drupal 9 still has a bunch of legacies includes files. See the previous meta #2999721: [META] Deprecate the legacy include files before Drupal 9
Here is the tracking of the deprecation status of the legacy include files in the core modules and core/includes directory:
bootstrap.incDone:
common.incschema.incmodule.inctheme.incmenu.incfile.incform.incerrors.incinstall.core.incinstall.incbatch.inctheme.maintenance.incupdate.incutility.inclocale moduleIf you have a term "co-worker" and you enable 'Transform dashes in URL to spaces in term name filter values', no matches will be found because the dash will be removed.
So we need to figure out how to handle the case where you have both terms with spaces and terms with dashes, since now it only works with one or the other.
Also need to figure out how to handle this when you have both "co worker" and "co-worker" as terms.
If the 'Transform dashes in URL to spaces in term name filter values' checkbox is set, search for terms that match either a space or a dash for any dashes in the argument value.
If multiple terms match, use the most recently created term.
Adds this description to the 'Transform dashes in URL to spaces in term name filter values' checkbox on the TermName views argument validator options form:
You can have both terms with spaces and terms with dashes like "co worker" and "co-worker". Then only the last created term will be matched.
None.
None.
TBD.
Follow-up to #2687843: Add back incremental migrations through the UI
Follow-up to #2683421: Remove incremental and rollback options from the UI (and add them back when they are more stable) which removes both the rollback and incremental options since they were untested and had several significant bugs. Unlike the incremental migration feature, rollback can probably be considered an additional feature and not necessarily block a stable Migrate UI.
Add back rollback migration support to the UI, with test coverage.
Use the phrase 'incremental upgrade' instead of 'Rerun' as shown in the now dated screenshot. See #32
Documentation to the handbook will be covered in a follow-up issue #2947498: Document Migrate Drupal UI rollbacks.
Documentation to the handbook will be covered in a follow-up issue #2947498: Document Migrate Drupal UI rollbacks.
In #2683421: Remove incremental and rollback options from the UI (and add them back when they are more stable), the UI disallows both incremental migrations and rollbacks. Here is what it looked like before that:
We might want to either reimplement that, or change it.
Depends on the solution.
None
The @todo refers to the issue #2999549: Allow button tag in LinkGenerator for better accessibility. Its resolution was fixed:
Remove the @todo
None.
None.
Since #2972224: Add .cspell.json to automate spellchecking in Drupal core Drupal core ships with a spell check dictionary stored as plain text file (dictionary.txt). That file could be used as custom dictionary in PhpStorm as well. Unfortunately PhpStorm only accepts files with "dic" extension.
https://www.jetbrains.com/help/phpstorm/spellchecking.html#configure-the...
Given that cspell can accept any file extensions we can configure it to use "dic" file instead of "txt". That will make possible to use the same dictionary file in PhpStorm and cspell.
We are in the process of deprecating jQuery UI in core. jQueryUI dialog is among the components that need to be removed/replaced.
As mentioned in the parent issue: #3067261: [Plan] Remove jQuery UI components used by Drupal core and replace with a set of supported solutions
The OpenJS Foundation lists jQuery UI as an Emeritus project in https://openjsf.org/projects/ which is described as:
Emeritus projects are those which the maintainers feel have reached or are nearing end-of-life
This issue was originally proposed as specifically looking for a polyfill, with the following explanation:
dialog.js always aimed at using the HTML5 dialog spec. Chrome just added experimental support for dialogs in it's dev branch: http://demo.agektmr.com/dialog/
We should let chrome use native dialogs when needed, it actually solves a bunch of messy issues, two of which are:
#2072037: Drupal dialog modal background z-index is set too low to reliably occlude core UI components
#1836392: In the Views UI, the interaction pattern of “All displays”/ “Override this display” is confusing
The problems mentioned above should absolutely be considered wile investigating what to use in place of jQueryUI dialog, but the options should be expanded to include different libraries - whatever option can best facilitate removing jQuery UI.
Refactor dialog JS to allow use of Native dialogs when available, and do so in a way that provides a consistent user experience regardless of browser. This will double as an effective way to swap libraries in the future, as it requires removing the library-specific assumptions of the current implementation.
Implement the replacement(s) so the dialogs have the same structure/classes as the current jQueryUI implementation. This will allow core to continue using jQueryUI's CSS styles and reduce the overall number of changes that result from this change (desired changes to the styling/structure of dialogs can obviously be done later, it just won't happen here to keep the issue's already-huge scope from getting huger.
Refactor JS to provide conditional use of native dialogs -- this implementation should hopefully make it relatively easy to add the replacement library once one is found.
(Chrome native dialogs have been tested and confirmed as meeting these requirements)
The best candidate is currently https://github.com/GoogleChrome/dialog-polyfill -- this meets all the requirements, is actively supported and initial tests/prototypes are promising.
If we are fortunate enough to find multiple libraries that meet these requirements, they should be compared using criteria such as: Code Style, Maturity, Responsiveness, Accessibility, UX, UI, Modularity, etc.
.
Add additional tests for important dialog use cases that aren't part of existing coverage. Before doing this review Layout Builder's test coverage as it indirectly tests a wide variety of Dialog use cases.
Yes, TBD.
TBD.
Attached is the patched used to make the following work (minus the scrolling element, that's hardcoded CSS).
What needs to be done is making sure our API can handle native dialogs when available and that pretty much means we need to not use jQuery UI or in a very different way than today to avoid wildly different UX between native and polyfill.
Following #3055198: [Symfony 5] Symfony/Component/EventDispatcher/Event is deprecated in Symfony 4.3 use Symfony/Contracts/EventDispatcher/Event instead and #3055194: [Symfony 5] The signature of the "Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher::dispatch()" method should be updated to "dispatch($event, string $eventName = null)", not doing so is deprecated since Symfony 4.3. Drupal core will no longer have an explicit dependency on the Symfony EventDispatcher Event class which was deprecated in Symfony 4 and replaced by an identical class in the Symfony/Contracts namespace.
However, Symfony Event's own classes (like GenericEvent) still inherit from the deprecated class, and some of Drupal's classes like EntityTypeEvent inherit from GenericEvent.
Because GenericEvent is going to stay in EventDispatcher in Symfony 5 (with the use statement updated), there is no need for any classes inheriting from GenericEvent to do anything - they'll get 'auto-updated' when we update to Symfony 5.
However, this presents a twofold problem:
1. We are currently suppressing Symfony's deprecation message, and there is no way to un-suppress this while the Symfony/EventDispatcher version is in use.
2. This means we're not able to inform people about the bridge Event class added in #3055198: [Symfony 5] Symfony/Component/EventDispatcher/Event is deprecated in Symfony 4.3 use Symfony/Contracts/EventDispatcher/Event instead until at least both of those issues are complete.
It should be possible to add a drupal check/rector rule looking for explicit references to the deprecated Event class in use statements.
We might be able to check the inheritance chain in Drupal's ContainerAwareEventDispatcher::dispatch(), and for example trigger deprecation errors for classes that directly inherit from the deprecated class - however this will also depend on Symfony's own Event classes.
Another option is to replace classes via the classloader so that we can customize the deprecation messages.
To stick to the design system approach for claro the implementation for components should stick to predefined variants.
Since Add support for Dropbutton variants (3057581) is moved forward claro can rely on it.
- Test patch - Figure out how to solve views display settings: https://git.drupalcode.org/project/claro/blob/8.x-1.x/claro.theme#L435 (addressing in #1899236: Add new Splitbutton render element to eventually replace Dropbutton)
Hi all,
Could someone pls help me to fix this.
The image style module was creating the images before upgrading to drupal 7.72. The thumbnail images and other image style images are or not created after upgrading to drupal 7.72 version. It started working after downgrading to drupal 7.70 version.
Any help is much appreciated
Regards,
Suganya M