Currently the Secondary tabs are using the wrong size, spacing and font-size, taking too much vertical space:
Correct secondary tabs styles according to the design system. Full specs can be checked on Figma, and here's an screenshot:
Font size will be reduced and vertical spacing will be smaller
- /admin/content
- /admin/people
We have a workaround for the details focus effect to make it more consistent with Chrome. However, this makes the details element focus inconsistent with some other elements on the same browser. Since this is presumably expected behavior in Firefox (on OS X) and not a bug, we should consider whether we want to have this workaround or not.
The motivation is to make the focus effect behavior consistent across websites visited with the same browsers .
There aren't any macOS system settings that make a difference.
/admin/config/system/site-information'.<summary> element in browsers, but not in Firefox on OS X operating system. With Claro theme, you will see the focus effect.<summary> element with every browser.Remove Claro's details summary workaround and rely on Firefox's default behavior when it comes to details focus effects.
Users using Firefox on OS X operating system won't see the focus effect of details summary if they are using their pointer device for collapsing or expanding the <details> element.
Nothing.
Nothing.
The word "Second" used in views sorting date plugin requires a translation context as now it is always translated in a single way (for example I see "second" translated for the meaning of "2nd", not as a time unit in views sorting area).
I'm not sure which component this relates to, so I just put other. Someone please feel free to update if you know the offending component.
For the sake of a simple example, lets say we have a view 'people/owners/%' with default title "Profile" and a Contextual Filter on field "last_name". The Contextual Filter has configuration "Override Title" checked with override value of "{{ title }}". The view is configured so that going to "/people/owners" returns 404, for no results. So, the default "Profile" title should always be overriden, as the view only works when a valid last_name is provided. When we go to /people/owners/johnson, the title is accurately overridden to say "Jeffrey Johnson" on the page. However, the breadcrumb shows "People / Owners / Profile" instead of "People / Owners / Jeffrey Johnson". I've tried changing the Default title from "Profile" to "{{ title }}", but this doesn't work, as I don't believe that field accepts twig input.
I've checked configurations on the Breadcrumb block, as well as the breadcrumb settings in bootstrap sub-theme's COMPONENT >> BREADCRUMBS sections, and don't see anything pertaining to title overrides.
I've searched for similar issues, but haven't found any. If this is a duplicate, I apologize, I must have missed something and would greatly appreciate someone pointing me in the right direction. Or, if this sounds like it's not a core issue, but rather a theme issue, just let me know and we can close this and I'll open a new issue on Bootstrap theme.
We've forked jQuery UI components into core, but for now have left the version numbers unchanged.
See brief discussion at #3087685-43: Remove deprecated jQuery UI components and fork remaining source code into core and #3087685-44: Remove deprecated jQuery UI components and fork remaining source code into core.
Keep the jQuery version as 1.12.1 until we introduce a change to the source. Whenever we make a change to the sources, add an extra suffix string to the version:
Add a version string postfix starting with zero (to indicate non-release status), and increment the patch, minor, or major version as appropriate under semver depending on the types of changes needed to jQuery UI. Examples: 1.12.1+0.0.1, 1.12.1+0.1.0
Since the release of Drupal 8.8.0, I haven't been able to run tests in my module CI environments (for an example, see this Honeypot failure).
I used to run the CI tests with the following structure:
composer install --devcomposer run-script drupal-phpunit-upgradecore/scripts/run-tests.sh for my moduleBut now, when I do that, I get the following error on the drupal-phpunit-upgrade script:
[InvalidArgumentException]
Script "drupal-phpunit-upgrade" is not defined in this package
So I dropped that line, and then ran composer require phpunit/phpunit prior to running run-tests.sh. When I did run-tests.sh again, this resulted in the error:
ERROR: PHPUnit testing framework version 7 or greater is required when running on PHP 7.3 or greater. Run the command 'composer run-script drupal-phpunit-upgrade' in order to fix this.
So... it's kind of a circular problem. I can't upgrade PHPUnit because the drupal-phpunit-upgrade script is missing completely. How are we to run PHPUnit tests in Drupal now?
Adding some probably-related issues.
Relying on the provider_name property from an oembed response can result in exceptions.
We should not be trusting a oembed provider to provide the same provider name as found in oembed.com/providers.json, two independent parties.
In various places, we already validate a URL by checking that a provider responds to a URL, then for some reason that provider is effectively discarded when we fetch the oembed resource, relying on the oembed resource to provide us a valid provider name in our system.
Take \Drupal\media\Plugin\Validation\Constraint\OEmbedResourceConstraintValidator::validate, which validates we have a provider for a URL by running $this->urlResolver->getProviderByUrl($url). Later in the method $this->resourceFetcher->fetchResource($resource_url); is executed. fetchResource calls createResource, which results in this behaviour.
Example
URL: https://www.reddit.com/r/aww/comments/get9f5/guess_youre_about_to_buy_every_toy_in_the_store/.
In the case of Reddit, in providers.json the provider_name is "Reddit", versus a response from Reddit itself has provider_name = 'reddit'. I dont think a reasonable fix is to simply lowercase everything.
Proposed solution: We should either be passing $provider down the stack, or re-running getProviderByUrl from within createResource.
Another similar but not exactly the same example of this is Sound Cloud. provider.json has a provider_name of SoundCloud, but resources returned from SoundCloud do not return a provider name. Supplying a provider_name in a resource response is also optional. In this case we have a provider already! But createResource currently isnt matching it up to the known provider. Retrieving a SoundCloud resource doesn't result in an exception, like Reddit resources, because the property is not present in the first place; NULL is set as the provider to \Drupal\media\OEmbed\Resource objects.
#3108006: Replace assertInternalType() calls with dedicated methods removes usages of the assertInternalType() function from core in D9. It might be useful for contrib projects trying to maintain both 8.x and 9.x compatibility to have the new methods available in 8.9.x, or even 8.8.x.
This is a D8 only issue.
field_test_field_attach_delete_bundle() is actually not needed, because everything is handled in field_test_field_storage_delete_instance().
Also, code does not work anyway due to $bundle_old being uninitialized.
This code produces error on PHP7.4: Trying to access array offset on value of type null.
In #3045216: Asset paths pointing to core/misc folder assume Claro is installed in core/themes the images/core directory was created for containing copies of core icons used by Claro. These copies existed because Claro was a contrib module and it's location relative to /core was not consistent.
images/core has a readme that states
Icons in this folder are copied from Drupal core. This folder with its content
should be removed before moving Claro to Drupal coreClaro is now in Drupal core, so this change can happen.
Part of meta-issue #2571965: [meta] Fix coding standards in core
Open the file core/phpcs.xml.dist and add a line for the sniff of this ticket. The sniff name is in the issue title. Make sure your patch will include the addition of this line.
Install PHP CodeSniffer and the ruleset from the Coder module:
$ composer install
$ ./vendor/bin/phpcs --config-set installed_paths ../../drupal/coder/coder_sniffer
Once you have installed the phpcs package, you can list all the sniffs available to you like this:
$ ./vendor/bin/phpcs --standard=Drupal -e
This will give you a big list of sniffs, and the Drupal-based ones should be present.
To speed up the testing you should make a copy of the file phpcs.xml.dist (in the core/ folder) and save it as phpcs.xml. This is the configuration file for PHP CodeSniffer.
We only want this phpcs.xml file to specify the sniff we're interested in. So we need to remove all the rule items, and add only our own sniff's rule. Rule items look like this:
<rule ref="PSR2.Namespaces.UseDeclaration.UseAfterNamespace"/>
Remove all of them, and add only the sniff from this issue title. This will make sure that our tests run quickly, and are not going to contain any output from unrelated sniffs.
Now you are ready to run the test! From within the core/ folder, run the following command to launch the test:
$ cd core/
$ ../vendor/bin/phpcs -p
This takes a couple of minutes. The -p flag shows the progress, so you have a bunch of nice dots to look at while it is running.
When the test is complete it will present you a list of all the files that contain violations of your sniff, and the line numbers where the violations occur. You could fix all of these manually, but thankfully phpcbf can fix many of them. You can call phpcbf like this:
$ ../vendor/bin/phpcbf
This will fix the errors in place. You can then make a diff of the changes using git. You can also re-run the test with phpcs and determine if that fixed all of them.
Language switcher block stills shows English after changing the language name from English to En in /admin/config/regional/language/edit/en
Use case
Clean install of Drupal 8.1.9
Choose German as the site language
Go to admin/config/regional/language and add English as a second language
Go to /admin/config/regional/language/edit/de and change the language name from German to De
Go to /admin/config/regional/language/edit/en and change the language name from English to En
Place language switcher block via block layout in a region
The language switcher labels show De and English although we changed the language name to En
The language switcher block should show De and En but shows De and English. See the attached screenshots.
Go to admin/config/regional/language and add English (https://www.evernote.com/l/ARDRm56TRP5MRIaZ1oPB-r5YHrzSvsgCZfw)
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.
In order to avoid mistakes like #3126784: \Drupal\ban\Plugin\migrate\destination\BlockedIP is not identical with its filename BlockedIp.php, field #3126781: Add a sniff to fix class name or interface name not identical with the filename, but found out there is a sniffer/rule existed already. It's called: Drupal.Classes.ClassFileName
Demo:
$ mv core/lib/Drupal/Component/Annotation/AnnotationInterface.php core/lib/Drupal/Component/Annotation/AnnotationInterfacE.php
$ composer run phpcs core/lib/Drupal/Component/Annotation/AnnotationInterfacE.php -- -s
> phpcs --standard=core/phpcs.xml.dist --runtime-set installed_paths $($COMPOSER_BINARY config vendor-dir)/drupal/coder/coder_sniffer -- 'core/lib/Drupal/Component/Annotation/AnnotationInterfacE.php''-s'
FILE: .../core/lib/Drupal/Component/Annotation/AnnotationInterfacE.php
----------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
----------------------------------------------------------------------
8 | ERROR | Interface name doesn't match filename; expected
| | "interface AnnotationInterfacE"
| | (Drupal.Classes.ClassFileName.NoMatch)
----------------------------------------------------------------------
$ mv core/lib/Drupal/Component/Annotation/Plugin/Discovery/AnnotatedClassDiscovery.php core/lib/Drupal/Component/Annotation/Plugin/Discovery/AnnotatedClassDiscoverY.php
$ composer run phpcs -- -s core/lib/Drupal/Component/Annotation/Plugin/Discovery/AnnotatedClassDiscoverY.php
> phpcs --standard=core/phpcs.xml.dist --runtime-set installed_paths $($COMPOSER_BINARY config vendor-dir)/drupal/coder/coder_sniffer -- '-s''core/lib/Drupal/Component/Annotation/Plugin/Discovery/AnnotatedClassDiscoverY.php'
FILE: ...omponent/Annotation/Plugin/Discovery/AnnotatedClassDiscoverY.php
----------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
----------------------------------------------------------------------
18 | ERROR | Class name doesn't match filename; expected "class
| | AnnotatedClassDiscoverY"
| | (Drupal.Classes.ClassFileName.NoMatch)
----------------------------------------------------------------------
Just enable it.
Needs review
RTBC
Commit
Hello,
In an aegir (BOA head current with php 7.3.16) multisite on a drupal 8 platform, when updating from 8.8.4 to 8.8.5, we encounter the following error when trying to run a db update. (there is no module schema_article that we know of) - I believe this error to be in the core update. This is with drush 9.7.2. the same result is given with drush 8.3.2-dev
drush9 updb
In Process.php line 235:
The command "/opt/tools/drush/9/drush/vendor/drush/drush/drush updatedb:status --no-entity-updates --uri=example.com --root=/data/
disk/fast2/static/8a" failed.
Exit Code: 1(General error)
Working directory:
Output:
================
Error Output:
================
In ExtensionList.php line 265:
The module schema_article does not exist.
running the drush command with drush 8.3.2-dev gives the same error - more or less:
fast2.ftp:[example.com]$ drush updb
Drupal\Core\Extension\Exception\UnknownExtensionException: The module schema_article does[error]
not exist. in
/data/disk/fast2/static/8a/core/lib/Drupal/Core/Extension/ExtensionList.php:265
Stack trace:
#0 /data/disk/fast2/static/8a/core/lib/Drupal/Core/Extension/ExtensionList.php(579):
Drupal\Core\Extension\ExtensionList->get('schema_article')
#1 /data/disk/fast2/static/8a/core/includes/update.inc(318):
Drupal\Core\Extension\ExtensionList->checkIncompatibility('schema_article')
#2 /opt/tools/drush/8/drush/commands/core/drupal/update.inc(146):
update_get_update_list()
#3 /opt/tools/drush/8/drush/commands/core/core.drush.inc(466): update_main()
#4 /opt/tools/drush/8/drush/includes/command.inc(422): drush_core_updatedb()
#5 /opt/tools/drush/8/drush/includes/command.inc(231): _drush_invoke_hooks(Array, Array)
#6 /opt/tools/drush/8/drush/includes/command.inc(199): drush_command()
#7 /opt/tools/drush/8/drush/lib/Drush/Boot/BaseBoot.php(67): drush_dispatch(Array)
#8 /opt/tools/drush/8/drush/includes/preflight.inc(67):
Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#9 /opt/tools/drush/8/drush/drush.php(12): drush_main()
#10 {main}
This IS an error in the core, isn't it?
I don't think we need to tag the tests for migrate, migrate_drupal and migrate_drupal_ui any longer with @group legacy
Remove the annotation.
This is a followup to #2936365: Migrate UI - allow modules to declare the state of their migrations that is the result of a UX meeting about the Review Page, See2936365-#101.
This is simple and straightforward. How do we all miss it? The Review page should use the human readable module name not the module machine name.
Change the Review form to have three columns in each list of modules: 'Drupal 7 module name', 'Drupal 7 machine name', and 'Drupal 8'. Sort by the first column.
The history
The original plan was to use the human readable module name in the UI but in #22 Gábor Hojtsy pointed out that some of the names don't 'match' the module_name, for example, "Views translation" is i18nviews. That will make it harder for people to find the source module. In that comment it was suggested to either
(1) add the project name from the module's info data in parenthesis or as a tooltip
(2) add the machine name of the module in parenthesis or as a tooltip
Option 2 is implemented as per #54. The option with the tooltip is used because the form "i18nviews (Views translation)" was a lot of text on the page and distracting. Unfortunately, there is not a screenshot of that version.
And that changed at DrupalSouth 2019 to adding a third column with the machine name. See #76. The result is three columns, 'Drupal 7 module name', 'Drupal 7 machine name', and 'Drupal 8'.
Yes, a 'nicer' Review page:
Before
After
The term name argument validator has an option to convert dashes to spaces in the argument value, which means that you can have a URL like 'myview/term-name-with-spaces'.
The argument validator handles this correctly, but the query that is run with this by the term name argument is incorrect. With a simple view of article nodes and the tags field that comes OOTB with core, I get this clause in the query:
WHERE (( (taxonomy_term_field_data_node__field_tags.name = 'has-spaces') )AND(( (node_field_data.status = '1') )))
ORDER BY node_field_data_created DESCArgument validator plugins only return a boolean from validateArgument(), but on D7 the equivalent function views_plugin_argument_validate_taxonomy_term::validate_argument() doctored the argument value on the argument handler like this:
if ($term && (empty($vocabularies) || !empty($vocabularies[$term->machine_name]))) {
if ($type == 'convert') {
$this->argument->argument = $term->tid;
}
There doesn't seem to be any provision for this in D8 -- argument validator plugins don't seem to be able to influence the argument value that the rest of the view uses.
Currently, Javascript tests have animations disabled by default, which was implemented in #2901792: Disable all animations in Javascript testing, this was a very good change that addressed many random test failures. This is done via rules added by css_disable_transitions_test.module
These rules include the following:
-o-transform: none !important;
-moz-transform: none !important;
-ms-transform: none !important;
-webkit-transform: none !important;
transform: none !important;
The transform: rule isn't related to transitions or animation, it is a static repositioning of an element from its default position.
Having this does not benefit FunctionalJavascript tests, but it does break PopperJS. This means that animations can't be disabled on any test using PopperJS, and those happen to be tests that would particularly benefit from disabling animations.
Remove transform:, we don't needed
Address @todos
Review and commit.
N/A
Potential change to WebDriverTestBase
N/A
Field UI allows you to select multiple target bundles for a field.
When you get to the views UI though you can select just a single vocabulary. For some usecases this is a problem
Allow to set multiple vocabularies
