Currently file_save_data depends on a number of services and calls logging and flash messages. We should deprecate it, and move it to a service so it can be better tested, throw exceptions and let calling code handle the logging and flash messages.
Deprecate file_save_data and replace with a service.
file_save_data, file_move() and file_copy() are replaced with a service and deprecated.
Trying to create a Mega Menu using Menu Items Extra (https://www.drupal.org/project/menu_item_extras ) and Layout Builder.
Custom blocks created through the Layout Builder UI are only visible to users with the 'Administer menus and menu items' permission.
Tim Plunkett's suggestion on Slack:
My best guess is that inline blocks are inheriting the wrong access from the parent entity
While using private files to create image styles, thumbnail images are broken.
Thumbnails are being created on the server, but Drupal can't seem to find them to display.
To replicate the issue, Change the file system like below
Configuration->Media->File system -> Default download method (Set to private)
and then go to Configuration->Media->Image Styles->Edit style (Any style).
The system successfully writes the thumbnail file to the private folder, and I can download and view the file. (Attempting to access the private path in the browser gives a "page not found" result).
System says that private file path is writeable and is also not the problem with .htaccess.
I have tried to fix the issue with the below patch. please let me know if this works or someone has a better solution.
This has been reported here as well
https://www.drupal.org/forum/support/post-installation/2020-01-15/image-...
When importing configuration from one site to another, the shortcut set UUID causes the import to fail.
Some steps to reproduce:
1) Export all config
2) Create a new site with drush site-install
3) Find the site UUID of the original site, and set the site UUID of the new site to be the same with drush config-set "system.site" uuid
4) drush config-import
[error] Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization.
Entities exist of type <em class="placeholder">Shortcut link</em> and <em class="placeholder">Shortcut set</em> <em class="placeholder">Default</em>. These entities need to be deleted before importing. in Drupal\Core\Config\ConfigImporter->validate() (line 748 of /var/www/web/core/lib/Drupal/Core/Config/ConfigImporter.php).
In ConfigImportCommands.php line 357:
The import failed due to the following reasons:
Entities exist of type <em class="placeholder">Shortcut link</em> and <em class="placeholder">Shortcut set</em> <em class="placeholder">Default</em>. These entities need to be deleted before importing.Workarounds:
shortcut.set.default.yml from the target site into the config being importeddrush ev '\Drupal::entityManager()->getStorage("shortcut_set")->load("default")->delete();'Hello team,
I recently used views to build my search page, and added a Global Result summary block in the header. I see few tokens are available. I used the token "@total" along with I need to display "item" OR "items" based on number of results. I could not find any way of doing it via the UI.
I had to do alter and make the text plural.
I was told that, tokens can be help here.
Can you please look into this tiny thing, where it support plural, and also support its translation.
Happy to provide any further info and help.
Thanks.
In #2551549: Deprecate per-table prefixing we have decided that per-table prefixing will be deprecated before 9.0.
We have stated that would be the case. The functionality is still there in 9.0.x-dev and it should be removed.
A problem is that the SQLite driver uses the $this->prefixes for something else and that functionality should be preserved.
None
EntityViewsDataTest tests the behaviour of the EntityViewsData class.
However, because it's a unit test, the test is very close to the implementation. All the services the class expects have to be mocked very precisely.
This means that issues that need to fix problems in EntityViewsData which would require a change to either which services are injected, or what is called on those services, are stuck, because these changes to EntityViewsData have knock-on effects on the test. It's a very complicated class, and a very big test (~1200 lines!), with LOTS of mocking, and so it's a pretty horrendous task. Also, having to change both the SUT and the test at the same time is not a good thing -- because it pretty much invalidates the tests, as they can't tell you whether you've broken anything.
Some of the issues stuck by this include:
- #2930736: EntityViewsData assumes BaseFieldDefinitions where it should use FieldDefinitionInterface
- #2898635: [PP-1] bundleFieldDefinitions() are not added in EntityViewsData
I propose that we rewrite EntityViewsDataTest as a kernel test. This would mean we remove all the mocking. We define entity types, and let the entity system pass that to EntityViewsData, and test the output. We then have a test that isn't tied to the implementation details of the class.
When I create a REST EXPORT in Views, all the fields in the result JSON are Strings, including integers and booleans. I was expecting them to be ints, bools etc whenever appropriate. I've read that this is an old issue that has long been fixed ( https://www.drupal.org/node/2837696 ) prior to Drupal 9.
It looks like the fields are serialized properly in other areas via JSON API (directly through their node), but in Views, all the fields are serialized as Strings...
Create a Rest Export in View, add some Int fields like Content ID or User ID. The fields in that JSON result are all Strings.
After downloading a thumbnail for a remote oEmbed resource, certain operations (e.g., applying an image style to the thumbnail) can fail if the thumbnail had no file extension, with errors like:
Could not apply Medium (220×220) image style to public://oembed_thumbnails/5qPKeF_Fcn22-QFyRf6_CK8IX1YMBi4xeeLOjBrlWtY. because the style does not support it.
This has recently broken our support for Vimeo, which no longer supplies file extensions in its thumbnail URLs. As an example, see https://vimeo.com/api/oembed.json?url=https://vimeo.com/347119375. Note that the response has a thumbnail_url field, but it has no file extension.
If no file extension is present in the thumbnail URL, then use the MIME type of the thumbnail to add a file extension to the local copy of the thumbnail.
Review and commit the patch.
TBD
PHP 8.1 support will require some updates to our dependencies: #3220021: [meta] Ensure compatibility of Drupal 9 with PHP 8.1 (as it evolves)
Not all dependencies are fully updated yet, but at least Symfony, masterminds/html5 and mikey179/vfsstream have recent point releases that include PHP 8.1 compatibility fixes.
$ composer update --with=phpunit/phpunit:^8
h2 tags seem too small in Olivero theme.
In fact it's slightly smaller than h3 tags.
Here's a screenshot:
I looked into computed size for each heading tag and here's the result:
h1: 60px
h2: 21px
h3: 21.06px
h4: 18px
h5: 14.94px
h6: 12.06px
h2& h3 are pretty much the same except that h2 has bigger letter spacing and a slightly darker color.
Also, the size difference between h1& h2 is jarring. Out of the box in chrome the h2 (1.5em) is 3/4th the size of h1 (2em).
Here, it is 1/3rd the size of h1.
Incease the size of h2 tag. 28-32 pixels looked good to me, but I'll defer the decision to design team for Olivero.
Yes, h2 gets bigger if this is implemented.
AccountInterface::id()'s typehint states it returns an integer, but this is not true in many (all?) cases. Weakly typed as PHP is, uids stored on AccountProxy, UserSession, UserInterface may return the uid as a string. This prevents strongly typed comparison, e.g. $currentUser->id() === $ownerIdAsInteger, if one is represented as an integer and the other a string. Or, it will fail strict type enforcement if passed to a method which expects an integer.
Make sure Drupal 9 keeps being compatible with PHP 8.1. Work with dependencies as needed. See #3109885: [meta] Ensure compatibility of Drupal 9 with PHP 8.0 (as it evolves) for how we did it with PHP 8.0. PHP 8.1-alpha1 is now released, see https://www.php.net/archive/2021.php#2021-06-10-1
Figure out what breaks. Itemize and resolve one by one.
To produce a list of dependencies that are blocking PHP 8.1 support, you can do the following. Make sure you use PHP 8 to run it.
$ git clone --branch 9.3.x https://git.drupalcode.org/project/drupal.git whynotphp81
$ cd whynotphp81/
$ composer install
$ composer update
$ composer why-not php:8.1List of upstream updates in progress
List of upstream dependencies that are likely to lack PHP 8.1 support
Upstream fixes that are merged but need a release:
Released but waiting composer update:
List of issues TBD
TBD
The fix in #2716019: View titles in breadcrumb and metatag title don't get properly translated introduced a small bug that creates an empty breadcrumb menu item because the frontpage view has no title.
The result:
1. Create a Basic Page with the title "Home" and path /home
2. Set the default front page to /home
3. Visit node/add/article
Add a default title to the view, suggestion 'Promoted content' as in essence that's what it is
Add a test for this displaying in breadcrumbs per the steps to reproduce
There are at least two ways a site administrator can work around the problem:
When #3124762: Add 'lifecycle' key to .info.yml files is committed, we will have three new non-stable module states. At present there is a visual affordance to experimental modules at admin/modules. But nothing at present for obsolete and deprecated.
Promote the non-stable statuses in admin/modules page, optionally even visually
The experimental modules confirm page now has title 'Are you sure you want to install non-stable modules?' and lists both experimental and deprecated modules
The Permissions form (/admin/people/permissions) is a usability nightmare. With a checkbox for each combination of permission and role, it can be a performance problem as well.
Let's not try to solve the problem all at once, but try to provide an alternative to using the catch-all Permissions form. We already have a version of the form for a single role, such as /admin/people/permissions/anonymous. Let's also provide a version of the form that applies to just a selected list of modules.
The module-specific Permissions form will be useful in at least these situations:
/admin/modules). Currently those links go to the appropriate anchor on the full Permissions form.Provide a form at /admin/people/permissions/module/%, where the parameter can be a single module name or a comma-separated list of module names.
Add a custom access checker for the new form. Deny access unless at least one of the requested modules defines at least one permission. This way, code that provides a link to the new form can check access before adding the link.
Provide a link to the new form after enabling one or more modules. This requires changes to both ModulesListForm and ModulesListConfirmForm, so add a trait for code that is shared by those two classes.
Add follow-up issues:
help_topics module and implementations of hook_help(). Replace links to /admin/people/permissions#module-module_name with /admin/people/permissions/module/module_name.Existing links on /admin/modules will go to instances of the new form.
The message after installing a module (or more than one) will include a link to the new form. Here is a screenshot of the message after enabling the Content Moderation and Workflows module:
Here is a screenshot of the form showing permissions for those two modules:
None
None
Site administrators can view and edit permissions for a single module or a list of modules. The Permissions links on the Extend page (/admin/modules) now go to these pages. When a site administrator enables one or more module from the Extend page, and at least one module provides permissions, the confirmation message includes a link to the page for the newly enabled module(s).
This meeting takes place every Friday at 10:00am ET (7:00am PT, currently 14:00 UTC). See Time.is to see what that is in your timezone.
The meetings are held using Zoom, and a link is posted in the #ux Slack channel 10 minutes before the meeting. Agenda is first come, first serve and set by attendees. Use the Needs usability review issue tag for issues that need review and/or suggest issues in comments here.
Recording of this week's meeting: TODO
We discussed the following issues: TODO
NR and RTBC issues marked Needs usability review.
In Version 9.2, dropdown menus do not work at all when more than 2 levels of menu selected.
second-level-navigation.js?v=9.2.0:21 Uncaught TypeError: Cannot read property 'classList' of null
at second-level-navigation.js?v=9.2.0:21
at NodeList.forEach (<anonymous>)
at toggleSubNav (second-level-navigation.js?v=9.2.0:19)
at HTMLLIElement.<anonymous> (second-level-navigation.js?v=9.2.0:62)Create a main menu of three or more levels. In admin/structure/block/manage/olivero_main_menu set to display 4 menu levels and expand all menu links.
Rewrite second-level-navigation.js so that it can cater for more than two levels of menu. This was possible in the javascript for the 9.1 version of Olivero (albeit with some tweaking of the js)
Somehow, somewhere, an incorrect indentation slipped into /core/modules/tour/src/TourViewBuilder.php which now results in any change in that file being rejected by TestBot.
FILE: /var/www/html/core/modules/tour/src/TourViewBuilder.php
----------------------------------------------------------------------
FOUND 2 ERRORS AFFECTING 2 LINES
----------------------------------------------------------------------
74 | ERROR | Comment indentation error, expected only 1 spaces
| | (Drupal.Commenting.InlineComment.SpacingBefore)
78 | ERROR | Comment indentation error, expected only 1 spaces
| | (Drupal.Commenting.InlineComment.SpacingBefore)
----------------------------------------------------------------------
This was first spotted by @quietone here and confirmed by @daffie here.
- Change something in /core/modules/tour/src/TourViewBuilder.php
- Create a patch/MR with that change
- See TestBot reject the patch in the Custom Commands phase
Attached MR should fix the indentation problems.
- Review
- Commit
- Rejoice
The testbot does not run PHPCS on all files when core/phpcs.xml.dist is changed. Therefor the testbot passes, when there are files that break on the rule change and the testbot should fail.
Change the cor/scripts/dev/commit-code-check.sh so that PHPCS will check all files when core/phpcs.xml.dist is changed.
None
None
None
None