#2934995 was not reverted in the 9.4.x branch. One option is to leave it as is and warn contrib module maintainers to update their modules to be compatible. This issue is to implement another option: only add the new Permissions form if a module adds certain annotations to its entity classes.
Proposed resolution
Replace the route subscriber with a route provider.
Register a new link type.
Add annotations to core classes to use the new link type and route provider.
Modules that define entity types can easily add Permissions forms for their entity types. See the change record https://www.drupal.org/node/3242827 for more information.
#3066512: Add checks for syntax and display of help topic Twig template files added a syntax checker which uses regular expressions to remove front matter and certain Twig syntax from the help topics files. Twig, however, has a much more flexible syntax -- for example {% set is just as good and {% set foo="}%" %} will also break the regular expression.
Proposed resolution
Fight fire with fire: use the Twig to render these things into HTML the way we need it.
The d7_field_formatter_settings migration maps formatters used in full view mode to the default entity view display on the destination. This means that right now, the formatter migration rows of the same field are overriding each other's migrated configuration if the actual field has formatter data for both of these view modes on the source Drupal7 site.
Proposed resolution
Add a test case to the D7 fixture
Change d7_field_formatter_settings migration so that the default view mode is migrated correctly to a default display.
While playing with lazy loading attribute that is coming from Drupal core and our own implementation in #3060605: Support lazy loading of images @sasanikolic noticed that responsive image tag is missing width and height attribute. Why is Drupal core is not setting these attributes for lazy image loading which basically disable lazy loading for all responsive images? The short answer is that responsive images are more complicated. And it still needs to be implemented.
I've read quite a bit of info related to lazy loading and images and responsive images in the next resources:
In short, at least as I understand, the problem with lazy loading and responsive images was that in one moment browsers were not properly supporting width/height attributes when images were lazy-loaded. So the browsers were not able to calculate the aspect ratio of images and show image area while image was still loading - and this resulted in recalculating page layout on image load. However, this should be fixed in most or all browsers now and this combination should work.
Proposed resolution
Add width and height attributes to the responsive image tag.
Add an option to toggle the loading="lazy/eager" option in the picture field formatter. For this, see the great work being done in #3173180: Add UI for 'loading' html attribute to images. We should model a similar result for picture.
A UI toggle is needed in this issue. We've learned a few things since loading="lazy" has started to be heavily used. Mainly, always enabling it negatively affects the page's LCP score. See https://web.dev/lcp-lazy-loading/ for an exhaustive description of the problem.
Remaining tasks
We want to avoid browser reflow if loading=lazy is configured.
From #13:
The HTML spec has very recently been updated to allow for width and height attributes to be set on source elements:
As of Oct 5th, 2021, it looks like FF is the only major browser not currently supporting this. Safari and Chrome already do.
The image dimensions are always provided. The srcset attribute only supports a single set of dimensions. These
dimensions reflect the real size but all images should follow the same
image size ratio. If using sizes and art direction, that might not be true.
For image styles, that is less of a concern because specifying image
density should already require that all images are the same image size
ratio. One could argue that providing wrong dimensions for sizes attribute
is bad for art direction. But having some image size to calculate ratio
is better than providing nothing. Ergo, we provide dimensions in all cases
even though they might be wrong in some edge scenarios.
These image dimensions are used by the browser to calculate the size and render a placeholder. This avoids content shift on page load. If someone decided to use lazy loading and art direction, they should not use sizes attribute. But rather image styles and specify the image dimensions. Because if they don't then they could conceivably experience some content shift issues.
If one enables Responsive Images module, and tries to upgrate a Drupal 7 instance without the picture module's tables being available, an exception is thrown:
Migration failed with source plugin exception: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal_blue.picture_mapping' doesn't exist: SELECT "p".*, "map"."sourceid1" AS "migrate_map_sourceid1", "map"."source_row_status" AS "migrate_map_source_row_status"\n
FROM\n
"picture_mapping" "p"\n
LEFT OUTER JOIN drupal_blue.migrate_map_d7_responsive_image_styles "map" ON machine_name = map.sourceid1\n
WHERE ("map"."sourceid1" IS NULL) OR ("map"."source_row_status" = :db_condition_placeholder_0); Array\n
(\n
[:db_condition_placeholder_0] => 1\n
)\n
in [docroot]/core/lib/Drupal/Core/Database/Driver/mysql/ExceptionHandler.php line 53'
This happens because the ResponsiveImageStyles migrate source plugin extends SqlBase instead of DrupalSqlBase, so the source module requirement aren't checked by Migrate Drupal's MigrationPluginManager.
Proposed resolution
ResponsiveImageStyles source plugin must extend DrupalSqlBase.
Remaining tasks
Patch.
Test.
User interface changes
Nothing.
API changes
ResponsiveImageStyles source plugin extends DrupalSqlBase (following Drupal's Migrate API best practices).
In #2917655: Deprecate or drop PHP 7.3 support in Drupal 9.4, we propose increasing \Drupal::MINIMUM_SUPPORTED_PHP to 7.4 in Drupal 9.4. This results in the following warning being displayed on installation, update, and the site status report:
Your PHP installation is too old. Drupal requires at least PHP 7.4.0. It is recommended to upgrade to PHP version 8.1 or higher for the best ongoing support. See PHP's version support documentation and the PHP requirements page for more information.
However, "the best ongoing support" is unclear, as are the consequences of continuing to use PHP 7.3. The specific consequences of using an old PHP version are explained in #2917655: Deprecate or drop PHP 7.3 support in Drupal 9.4.
Proposed resolution
Explain the consequences of PHP that is "too old" more clearly, either by improving the UI strings and/or adding more specific explanations to the system requirements documentation. See the issue summary of #2917655: Deprecate or drop PHP 7.3 support in Drupal 9.4 for what the consequences might be.
While creating custom basic block through layout builder, form-item description is not visible in Configure dialog box.
Steps to reproduce
1. Home>Administration>Structure>Content types>Article,under layout options check layout builder.
2. Go to the article node, click on layout.
3. Click on Add block, create a custom block>basic block.
4. Title Input field description is not visible.
I expect the visibility of "audio" to change when changing the value of "type". What happens is "audio" remains visible and not required. Simply changing "managed_file" to "file" brings the expected behavior.
When #3124762: Add 'lifecycle' key to .info.yml files is committed, we will have three new non-stable theme states. At present there is a visual affordance to experimental themes at admin/appearance. But nothing at present for obsolete and deprecated.
Proposed resolution
Promote the non-stable statuses in admin/appearance page, optionally even visually
DOM may be updated by various front end, back end or other ajax actions. Currently when an element with the class ".use-ajax" is added after the initial page load it usually isn't initialised. Although it might work for the admin user as the element binding could occur after the inistial DOM update (such as with VueJS or ReactJS).
To reproduce, create a dialog link with the class attribute use-ajax and data-dialog-type="modal", linking to another page. This should work.
Next, dynamically add another link, using either a JS front end or developer tools. Clicking on the link will take you to the page instead of opening a modal.
Proposed resolution
Find a way to delegate the event to a parent element or listen for dynamic updates.
The attached patch is non-compliant, and it doesn't include ES6 changes, but it does show one way to listen for dynamic updates.
There's no handy way to mark some rows as disabled for selection in a tableselect element. The feature is needed when the user should be denied to select certain options, according to a form business logic, but he still need to know that the options exist and might be available in other context.
Proposed resolution
Allow to pass an optional #disabled property in option. When an option has #disabled === TRUE, the corresponding checkbox will be disabled.
Workaround
Without this change there's still possible to disable certain rows:
Add an additional #process callback to the tableselect element. Note that you should add also the original processor:
$form['my_table'] = [
'#type' => 'tableselect',
...
'#process' => [
// This is the original #process callback.
[Tableselect::class, 'processTableselect'],
// Additional #process callback.
[static::class, 'processDisabledRows'],
],
...
];
The additional #process callback:
public static function processDisabledRows(array &$element): array {
foreach (Element::children($element) as $key) {
$element[$key]['#disabled'] = isset($element['#options'][$key]['#disabled']) ? $element['#options'][$key]['#disabled'] : FALSE;
}
return $element;
}
Set the #disabled property to TRUE on the rows that you want to disable:
By adding a #disabled property set to TRUE, it's possible to prevent used by selecting certain options in a tableselect form element.
Initial report
Currently it is not possible to disable an option on a tableselect list.
Can we allow a Tableselect checkbox to be disabled on a specific option, like it currently is possible with the attribute and ajax parameters?
When an oEmbed resource is fetched this message is shown: "The provided URL does not represent a valid oEmbed resource."
This information is usually not enough to figure out the problem without looking at the logs.
Steps to reproduce
Attempt to save an entity that holds a Facebook video without an OAuth token.
Proposed resolution
A better message might be a message that not only explains what happened in the Drupal context but also what happened in the third-party context, and that information is sent in the message included in the response to the fetch request.
This ability to link to a vertical tab was introduced in #376293: Activate current vertical tab from URL fragment and has been merged. You currently can use the case-sensitive vertical tab id as the hash, but without knowing how this works users cannot link to specific tabs.
For example if I wanted to link a user to authoring information I would need to know that in Drupal 8 I would need to add #edit-author to the end of the URL. Ideally when authoring information is clicked the window hash should be updated to reflect the tab that is open.
Proposed resolution
When clicking the vertical tab, the URL in the browser should be updated with the relevant hash of the tab. If this URL is entered in to a new browser said tab should be open by default and brought in to the users view.
Before clicking on the vertical tab link switches the tab pane, but does not change the hash in the URL bar:
Image may be NSFW. Clik here to view.
After clicking on the vertical tab link (including mouse and keydown) switches the tab pane AND changes the hash in the URL bar:
Image may be NSFW. Clik here to view.
After pasting this URL with the preserved hash into a new window highlights the relevant tab and scrolls down to it:
Image may be NSFW. Clik here to view.
Remaining tasks
Backport to 8.2.x (Should be the same patch)
Backport to 7.x potentially based on patch #2 which was created for 7.38
User interface changes
Minimal changes. A page with a hashed URL will be scrolled down, and focused on the relevant vertical tab. If the relevant tab is not the default open tab, the default will be closed and the tab from the hash will be opened.
