Quantcast
Channel: Issues for Drupal core
Viewing all 297295 articles
Browse latest View live

Include 'composer' directory in phpcs scans

$
0
0

Problem/Motivation

Recently, a new top-level directory composer was introduced. This directory holds sources for code that does not need to be packaged in the drupal/core subtree split, and therefore should not be in the core directory. However, only things in the core directory are being tested with phpcs, leading to a growing collection of coding violations in the composer location.

Proposed resolution

We should ensure that the composer directory is also sniffed for conformance with the Drupal coding standards. We could do this either by copying the phpcs configuration from the core directory, or by making a relative path from within the phpcs configuration file to the composer directory. Neither option is great, but the relative path is probably preferable to the duplicated configuration.

Remaining tasks

  • Start code-sniffing the composer directory.
  • Correct the existing coding standard violations. There are many, but phpcbf can help with most of them.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

n/a


Let modules opt in to the bundle-specific permissions form

$
0
0

Problem/Motivation

#2934995: Add a "Manage permissions" tab for each bundle that has associated permissions applied to all entity types that have bundles and set field_ui_base_route in the entity annotation. That issue was originally fixed in 9.3.x, then reverted because it conflicted with existing admin paths for at least one contrib module.

#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.

Remaining tasks

User interface changes

To be determined.

If we enable the Permissions form for all the core entity types affected by #2934995: Add a "Manage permissions" tab for each bundle that has associated permissions, then there will be no changes. We might decide not to enable it for some entity types.

API changes

Replace Drupal\user\Routing\RouteSubscriber, which was added in #2934995: Add a "Manage permissions" tab for each bundle that has associated permissions, with Drupal\user\Entity\UserPermissionsRouteProvider.

Data model changes

None

Release notes snippet

todo

Deprecate the "entity_upcast" operation specified in EntityConverter

$
0
0

Problem/Motivation

TODO

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Remove loading from the Drupal\Drivers namespace from drupal_get_database_types()

$
0
0

Problem/Motivation

The loading of database drivers from the namespace Drupal\Drivers has been deprecated in D9 and can be removed in D10. That happens in the function drupal_get_database_types() in the file core/includes/install.inc.

Proposed resolution

The code that can be removed is:

  // Find drivers in the Drupal\Driver namespace.
  // @todo remove discovering in the Drupal\Driver namespace in D10.

and

  $files = [];
  if (is_dir(DRUPAL_ROOT . '/drivers/lib/Drupal/Driver/Database')) {
    $files = $file_system->scanDirectory(DRUPAL_ROOT . '/drivers/lib/Drupal/Driver/Database/', $mask, ['recurse' => FALSE]);
  }
  foreach ($files as $file) {
    if (file_exists($file->uri . '/Install/Tasks.php')) {
      // The namespace doesn't need to be added here, because
      // db_installer_object() will find it.
      $drivers[$file->filename] = NULL;
    }
  }

Remaining tasks

TBD

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

PHP 8.1 ComputedItemListTrait::offsetExists deprecation

$
0
0

Problem/Motivation

When a class uses ComputedItemListTrait, a PHP 8.1 deprecation is trigger on offsetExists because return is not typed as bool.

Steps to reproduce

For example the profile module uses this trait in the class Drupal\profile\Plugin\Field\ProfileEntityFieldItemList. Displaying the login pane in a commerce checkout displays this error.

Proposed resolution

As for the others deprecated functions of this trait we could simply add #[\ReturnTypeWillChange] to suppress the deprecation.

Content: Has taxonomy term ID (with depth) query performance

$
0
0

Updated: Has taxonomy term ID (with depth) query performance

Problem/Motivation

When using views + taxonomy term id with depth, either as view argument or view filter, the MySQL query can have quite few subqueries and joins, sorting, which is very slow, specially when MySQL cannot cache these subqueries. MySQL will use temporary tables, wich can be really slow writing on the disk for large databases.

In the example below, this is the resulting query of a view using taxonomy term id with depth 3 as argument:

SELECT node.sticky                                                AS node_sticky
       ,
       nodequeue_nodes_node.position                              AS
       nodequeue_nodes_node_position,
       field_data_field_published_date.field_published_date_value AS
       field_data_field_published_date_field_published_date_value,
       node.nid                                                   AS nid
FROM   node node
       LEFT JOIN nodequeue_nodes nodequeue_nodes_node
              ON node.nid = nodequeue_nodes_node.nid
                 AND nodequeue_nodes_node.qid = '1'
       LEFT JOIN field_data_field_published_date field_data_field_published_date
              ON node.nid = field_data_field_published_date.entity_id
                 AND ( field_data_field_published_date.entity_type = 'node'
                       AND field_data_field_published_date.deleted = '0' )
WHERE  (( ( node.status = '1' )
          AND ( node.nid IN (SELECT tn.nid AS nid
                             FROM   taxonomy_index tn
                                    LEFT OUTER JOIN taxonomy_term_hierarchy th
                                                 ON th.tid = tn.tid
                                    LEFT OUTER JOIN taxonomy_term_hierarchy th1
                                                 ON th.parent = th1.tid
                                    LEFT OUTER JOIN taxonomy_term_hierarchy th2
                                                 ON th1.parent = th2.tid
                                    LEFT OUTER JOIN taxonomy_term_hierarchy th3
                                                 ON th2.parent = th3.tid
                             WHERE  ( ( tn.tid = '37' )
                                       OR ( th1.tid = '37' )
                                       OR ( th2.tid = '37' )
                                       OR ( th3.tid = '37' ) )) ) ))
ORDER  BY node_sticky DESC,
          nodequeue_nodes_node_position DESC,
          field_data_field_published_date_field_published_date_value DESC
LIMIT  10 offset 0;

The problem here is the sub query that is finding the nids to show on this index. In my sites database this query returns 5425 records in 1 second. It is slow because it is joining 5 tables, taxonomy index is one of them and has 103k records. Depth is terribly inefficient in databases that store hierarchy with parent references; the nested set model would be much better but that is something that would require a huge rewrite of drupal.

Proposed resolution

I believe the depth query can be achieved with no extra joins, but with a few other queries and some php. I suggest the tree of terms is loaded and we check the tid is in a set of taxonomy terms, such as:

SELECT node.sticky                                                AS node_sticky
       ,
       nodequeue_nodes_node.position                              AS
       nodequeue_nodes_node_position,
       field_data_field_published_date.field_published_date_value AS
       field_data_field_published_date_field_published_date_value,
       node.nid                                                   AS nid
FROM   node node
       LEFT JOIN nodequeue_nodes nodequeue_nodes_node
              ON node.nid = nodequeue_nodes_node.nid
                 AND nodequeue_nodes_node.qid = '1'
       LEFT JOIN field_data_field_published_date field_data_field_published_date
              ON node.nid = field_data_field_published_date.entity_id
                 AND ( field_data_field_published_date.entity_type = 'node'
                       AND field_data_field_published_date.deleted = '0' )
        INNER JOIN taxonomy_index ON node.nid = taxonomy_index.nid AND taxonomy_index.tid IN ( '37', '38', '39', '40',
                                                   '41', '42', '43', '44',
                                                   '45', '46', '47', '48',
                                                   '49', '50', '51', '52',
                                                   '35524', '53', '54', '56',
                                                   '57', '58', '59')
WHERE  (( ( node.status = '1' ) ))
ORDER  BY node_sticky DESC,
          nodequeue_nodes_node_position DESC,
          field_data_field_published_date_field_published_date_value DESC
LIMIT  10 offset 0; 

This query is much more efficient and as far as I can work out, will return exactly the same results.

Remaining tasks

Patch views_handler_argument_term_node_tid_depth.inc
Patch views_handler_filter_term_node_tid_depth.inc

Original report by jamiecuthill

I have a view emulates the taxonomy index page but uses depth to pull in nodes assigned to children of the current term (set to 3 in this case). This view also has some complex ordering based on sticky, nodequeue position and a date field.

The generated query looks something like this
SELECT node.sticky AS node_sticky, nodequeue_nodes_node.position AS nodequeue_nodes_node_position, field_data_field_published_date.field_published_date_value AS field_data_field_published_date_field_published_date_value, node.nid AS nid FROM node node LEFT JOIN nodequeue_nodes nodequeue_nodes_node ON node.nid = nodequeue_nodes_node.nid AND nodequeue_nodes_node.qid = '1' LEFT JOIN field_data_field_published_date field_data_field_published_date ON node.nid = field_data_field_published_date.entity_id AND (field_data_field_published_date.entity_type = 'node' AND field_data_field_published_date.deleted = '0') WHERE (( (node.status = '1') AND (node.nid IN (SELECT tn.nid AS nid FROM taxonomy_index tn LEFT OUTER JOIN taxonomy_term_hierarchy th ON th.tid = tn.tid LEFT OUTER JOIN taxonomy_term_hierarchy th1 ON th.parent = th1.tid LEFT OUTER JOIN taxonomy_term_hierarchy th2 ON th1.parent = th2.tid LEFT OUTER JOIN taxonomy_term_hierarchy th3 ON th2.parent = th3.tid WHERE ( (tn.tid = '37') OR (th1.tid = '37') OR (th2.tid = '37') OR (th3.tid = '37') ))) )) ORDER BY node_sticky DESC, nodequeue_nodes_node_position DESC, field_data_field_published_date_field_published_date_value DESC LIMIT 10 OFFSET 0;

The problem here is the sub query that is finding the nids to show on this index. In my sites database this query returns 5425 records in 1 second. It is slow because it is joining 5 tables, taxonomy index is one of them and has 103k records. Depth is terribly inefficient in databases that store hierarchy with parent references; the nested set model would be much better but that is something that would require a huge rewrite of drupal.

Now I believe the depth query can be achieved with no extra joins, but with a few other queries and some php. I suggest the tree of terms is loaded and we check the tid is in a set of taxonomy terms, such as:
SELECT node.sticky AS node_sticky, nodequeue_nodes_node.position AS nodequeue_nodes_node_position, field_data_field_published_date.field_published_date_value AS field_data_field_published_date_field_published_date_value, node.nid AS nid FROM node node LEFT JOIN nodequeue_nodes nodequeue_nodes_node ON node.nid = nodequeue_nodes_node.nid AND nodequeue_nodes_node.qid = '1' LEFT JOIN field_data_field_published_date field_data_field_published_date ON node.nid = field_data_field_published_date.entity_id AND (field_data_field_published_date.entity_type = 'node' AND field_data_field_published_date.deleted = '0') WHERE (( (node.status = '1') AND (node.nid IN (SELECT tn.nid AS nid FROM taxonomy_index tn WHERE ( (tn.tid IN ('37', '38', '39', '40', '41', '42', '43', '44', '45', '46', '47', '48', '49', '50', '51', '52', '35524', '53', '54', '56', '57', '58', '59')) ))) )) ORDER BY node_sticky DESC, nodequeue_nodes_node_position DESC, field_data_field_published_date_field_published_date_value DESC LIMIT 10 OFFSET 0;

This query is much more efficient and as far as I can work out, will return exactly the same results.

I have attached a patch with my code changes for this and I would really like some feedback as to whether it's worth considering.

Allow image fields to use any extensions the current image toolkit supports (instead of hard-coding jpg, png and gif only)

$
0
0

I found that it's possible to upload SVG images to Drupal 7 (7.38) and they can even be rendered as the original image, but any image styles don't work (obviously since gd doesn't support SVG). Of course there is the imagemagick module that one could try to use and possibly patch, but it didn't seem to work out of box either. I thought that it would be great to add basic SVG support to Drupal core since many browsers support them and they are great for todays world with different screen sizes etc. By basic support I mean that the SVG images would work with styles, not applying the ones that can't be done without gd or similar image manipulation tool, but simply bypassing the styles and applying for example width and height to the img tag directly when theming the images.

Use PHP attributes instead of doctrine annotations

$
0
0

Problem/Motivation

We use Doctrine's annotations to add metadata to our classes. For example, Block's use annotations to set the block ID and admin label. PHP 8.0 introduced a new language feature PHP attributes to support such metadata.

Proposed resolution

  • Add support for PHP attributes
  • Deprecate doctrine annotations for removal in Drupal 11.

Here's an example of a block annotation:

/**
 * @Block(
 *   id = "system_powered_by_block",
 *   admin_label = @Translation("Powered by Drupal")
 * )
 */
class SystemPoweredByBlock extends BlockBase {
  // ...
}

PHP attributes options

Use named arguments
#[Block(
  id: "system_powered_by_block",
  admin_label: "Powered by Drupal"
)]
class SystemPoweredByBlock extends BlockBase {
  // ...
}
Use arrays
#[Block(array(
  "id" => "system_powered_by_block",
  "admin_label" => "Powered by Drupal",
))]
class SystemPoweredByBlock extends BlockBase {
  // ...
}
Use individual attributes
[#BlockId("system_powered_by_block")]
[#BlockAdminLabel("Powered by Drupal")]
class SystemPoweredByBlock extends BlockBase {
  // ...
}

Problems to solve

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


Migrating reference fields: target_bundles may never be empty array

$
0
0

Problem/Motivation

Discovered via #2814953: Migrate Drupal 7 node/user reference fields, but is a long pre-existing bug.

#2814953-96: Migrate Drupal 7 node/user reference fields contains:

+++ b/core/modules/field/src/Plugin/migrate/process/d7/FieldInstanceSettings.php
@@ -65,6 +65,43 @@ public function transform($value, MigrateExecutableInterface $migrate_executable
+        'target_bundles' => array_filter($field_data['settings']['referenceable_types'] ?? []),

Yet … field_field_config_presave() does this:

  // In case we removed all the target bundles allowed by the field in
  // EntityReferenceItem::onDependencyRemoval() or field_entity_bundle_delete()
  // we have to log a critical message because the field will not function
  // correctly anymore.
  $handler_settings = $field->getSetting('handler_settings');
  if (isset($handler_settings['target_bundles']) && $handler_settings['target_bundles'] === []) {
    \Drupal::logger('entity_reference')->critical('The %field_name entity reference field (entity_type: %entity_type, bundle: %bundle) no longer has any valid bundle it can reference. The field is not working correctly anymore and has to be adjusted.', [
      '%field_name' => $field->getName(),
      '%entity_type' => $field->getTargetEntityTypeId(),
      '%bundle' => $field->getTargetBundle(),
    ]);
  }

IOW, target_bundles must either be NULL or if it's an array, it must be non-empty. Otherwise all references will be refused!

Steps to reproduce

node_reference field without referenceable_types setting triggers something like this during the migration:

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Allow preferred language selection for link field

$
0
0

Problem/Motivation

In multilingual sites it's currently not possible to select a specific translation for internal path's when creating links. For instance, I have a Dutch/English site:

  • Node 1 is the homepage and has a translation for both languages.
  • Node 2 is a Dutch node with a link field set to link to node 1.
  • When showing the link on node 2, I want the link to go to the English translation of Node 1.

I ran into this while trying to find a solution for #2845245: Allow Redirecting to another language.

This seems to be related to the following issues:
#2462279: Language prefix for custom menu link paths are saved but not used - The menu link doesn't use the entered language prefix, having a seperate language selection field will make the destination language explicit.

#2466553: Untranslated menu items are displayed in menus - Menu links can have a language and it would be nice to only habe Dutch menu links show up in the Dutch menu. When you can have a Dutch menu link but link it to a English translation, this will allow for more flexibility.

#2144377: Entity reference autocomplete lists entity labels only in current content language - The entity_autocomplete form shows available entity titles in the translation of the current interface language. This doesn't mean you will actually get a link to that specific translation. It would help to explicitly choose the preferred language of the destination.

Proposed resolution

Allow a preferred language for link fields.

Remaining tasks

User interface changes

Optionally added select list for 'Preferred language' to link fields.

API changes

None

Data model changes

None

AJAX call can detach all behaviors

$
0
0

Situation: An AJAX calls returns, amongst others, an "insert" command with incorrect selector, and/or ajax.wrapper isn't set on the AJAX object.
Result: On line 1056 of ajax.js (latest 8.4.x-dev) $wrapper will contain no elements, Drupal.detachBehaviors() will get null/undefined as the first argument and that in turn will let it default to document as the context – removing/detaching all behaviors from the complete page. Even if this requires an incorrect AJAX response, I don't think this is reasonable behavior. Especially, it also contradicts the comment a bit further down that "this if statement allows `#ajax['wrapper']` to be optional".

\Drupal\views\Plugin\views\area\Entity is missing config dependency on view mode

$
0
0

Problem/Motivation

When using the Views entity area plugin by adding the output of an entity to the footer or header of a view you can select the view mode the entity will be displayed in.

The config object this view mode depends on is not added to the list of depndencies of the view.

Proposed resolution

Add the view mode config to the list of dependencies in \Drupal\views\Plugin\views\area\Entity::calculateDependencies().

Auto-placeholdering for #lazy_builder with bubbling of max-age

$
0
0

Problem/Motivation

Split off from #2543334: Auto-placeholdering for #lazy_builder with bubbling of contexts and tags to make that one more easily reviewable. Details to follow.

Proposed resolution

Details to follow.

Remaining tasks

Details to follow.

User interface changes

None.

API changes

None.

Data model changes

None.

Why this should be an RC target

From #10:

Without this, max-age=0 blocks will not be placeholdered automatically, which means that any page with uncacheable blocks will not be able to use Dynamic Page Cache.

This would therefore IMO be a great RC target.

Allow form redirects to ignore ?destination query parameter

$
0
0

Problem/Motivation

In #2767857: Add destination to edit, delete, enable, disable links in entity list builders we added destination query parameters to config entity lists and operations in Views. This unearthed the fact that some of our forms are not destination query compatible - we broke the image style user interface unexpectedly. See #2940165: [regression] Cannot add effects to image style via the UI.

The problem is that the destination param is set to win regardless of what a user does in the form. This means that any Drupal form can be redirected to somewhere using it.

As discussed in #2950759: Revert 2767857, right now, it is necessary to alter the global request object to disable a destination query arg based redirect override. That's complicated to understand and we shouldn't be doing something like that.

Older related issues are:
#579366: How many ways are there to redirect after form submission?
#1627654: drupal_redirect_form() should state that it is overridden by a destination in the request
#2325463: Destination URL breaks preview

Proposed resolution

We need a way to set a higher priority redirect on a form. So the developer can say actually regardless of the destination parameter go here because obeying the redirect makes no sense. The fix however shouldn't be tied to the forms system so the patch at the moment adds a new IgnoreDestinationRedirectReponse and the RedirectResponseSubscriber checks and doesn't apply the ?destination override if it is.

However since 90% of the redirects we are interested are from Forms the patch also adds helpers to FormState to make redirects behave like this.
FormStateInterface::getIgnoreDestination()
FormStateInterface::ignoreDestination($status)

Remaining tasks

Add more tests. One is currently provided by core/modules/image/src/Tests/ImageAdminStylesTest.php which proves this fixes #2940165: [regression] Cannot add effects to image style via the UI whilst bringing back the nice consistent UI behaviour of #2767857: Add destination to edit, delete, enable, disable links in entity list builders for Image Styles.

User interface changes

API changes

Data model changes

Use Fibers to offload discovery builds

$
0
0

Problem/Motivation

After a full cache clear, Drupal has to build up various caches before it can serve a request. Router, menu links, various plugin registries, twig templates, CSS assets (#1014086: Race conditions, stampedes and cold cache performance issues with css/js aggregation) etc.

In development, this can mean a lot of waiting seconds for pages to load.

On production, potentially the same with the added risk of stampedes.

Steps to reproduce

drush cr, load a heavy-ish page, watch that spinny wheel.

Proposed resolution

PHP 8.1 adds Fibers https://php.watch/versions/8.1/fibers / https://php.watch/versions/8.1/fibers

This allows very simple async concurrency, and it might allow us to offload some work.

General idea looks like this:

1. Somewhere early in a request, detect that we're going to have to do some rebuilds later in the request.

Possible spots:

DrupalKernel::initializeContainer() (the earliest point in the request where it's likely we'll have lots of work to do later).

Router::rebuildNeeded() (this would be in the request triggering the cache clear)

drupal_flush_all_caches() (as would this)

From there, start a Fiber, the Fiber's sole job is request various caches that are needed for most requests - the module list, plugins etc. Its job will be to call various methods (module list, plugin discovery etc.) that will trigger cache misses and rebuilds.

The hope is that the Fiber hits all these missing caches before any external requests do. All other requests have to deal with routing, whereas the Fiber won't, meaning some chance that it can get its work done before the other requests reach the same point. If it gets a cache hit from one service, it can move onto the next.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


Run automated cron in a Fiber

$
0
0

Problem/Motivation

Since we added automated cron to core, we've tried various methods to get it to run in the background.

See discussion in #566494: Running cron in a shutdown function breaks the site, #331611: Add a poormanscron-like feature to core and other issues.

Steps to reproduce

Proposed resolution

Run cron in a Fiber, this should completely offload it from the current request. We may also be able to make the default for automated cron a bit more frequent if this works well.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Add an 'instant' queue runner with Fibers

$
0
0

Problem/Motivation

Drupal has two ways to handle long-running tasks:

1. Queue API, by default queues are run on cron, often sites run queues via jenkins on different schedules, there are projects like 'waiting queue' which aim to minimise the time before queue items are picked up.

2. Batch API - designed for the browser, although drush can also run batches, completely blocks the user's interaction with the site while it's running. Batches are user-specific so if one gets interrupted, that's pretty much it. Provides feedback, you know when it's finished.

From personal experience, the Queue API is great to work with and expectations are very clear. Batch API is hard to work with and debug.

In the UI, Batch API always blocking isn't necessarily optimal. Bulk operations on entities for example could be put into a queue, and there could be a progress bar in a block somewhere which runs down the queue, but allows the user to click around the rest of the site while that's happening. There are cases though like updates from the UI where things really do need to block and require strict ordering.

Proposed resolution

Add a browser queue runner. Will need a route that takes a queue name, fetches items and runs them (will need to set the current user to anonymous to match drush/cron) then reports back. Then a proof of concept UI widget with some feedback that's activated by a $_SESSION flag. Not sure what the non-js fallback would be, although a 1px gif might be enough.

Remaining tasks

User interface changes

API changes

Data model changes

Cron jobs fall into a couple of main categories:

- things that have to be run periodically and don't care about site events - mainly garbage collection like session and cache.
- batch processing of things - search indexing of new nodes, purging of deleted stuff.

For the latter case, these are increasingly moving to the queue API, although it's not 100% consistent in core.

Issues like #943772: field_delete_field() and others fail for inactive fields, and the one I can't find about indexing nodes for searching immediately, might be helped by a poor mans queue runner.

Drupal 7 has a poor mans cron. Currently the implementation is very basic - 1px gif/xhr requests were causing Drupal to be bootstrapped twice each request, and at one point there was a proposal to do ob_flush() during a shutdown function but this didn't take on, so we ended up just running cron inline instead, which is sucky but I argued for that in the end.

With the queue runner, it'd be more a case of setting $_SESSION['run_queues'] after a form submit, check that on the next page, if it's set, add the 1px gif or whatever to that page, which hits /queue_run with a token. This would only ever be triggered by form submissions so it'd not have the page caching issues of cron runs.

Things it could be useful for:

- field deletion
- mass deletes of other stuff
- operations that trigger menu rebuilds or similar expensive operations, that don't necessarily have to happen inline with the request - just very shortly afterwards.
- indexing nodes in the core search module immediately after posting instead of waiting for cron.

Modules cannot grant access using hook_file_download()

$
0
0

from FileDownloadController:

If one or more modules returned headers the download will start with the returned headers. If a module returns -1 an AccessDeniedHttpException will be thrown.

This does not appear to be the case. In the code we have:

$headers = $this->moduleHandler()->invokeAll('file_download', array($uri));

foreach ($headers as $result) {
  if ($result == -1) {
    throw new AccessDeniedHttpException();
  }
}

With my custom module invoking hook_file_download, my $headers array looks something like

(
    [Content-Type] => application/pdf
    [Content-Length] => 76130
    [Cache-Control] => private
    [0] => -1
)

So my module does provide headers (which implicitly grants access), BUT since another module disallows access with the -1, the access denied is thrown.

Possible solutions

  1. Update the $headers foreach to account for module A granting access which module B denies.
  2. Update the docs to read "If any module returns -1 an AccessDeniedHttpException will be thrown." and provide recommendations on the correct way to override an existing access controller.

My guess is that we'll end up with #2, especially in light of the progress on #2148353: File access (hook_file_download) does not use an EntityAccessController.

[PHP 8.1] Fibers

Fix spelling for words used once, beginning with 'q' -> 's', inclusive

$
0
0

Problem/Motivation

Limit this to one line easy fixes, avoid any possible controversy, or any change that would better fit with other words, such as doing chien and chiens in the same patch.

The list of words beginning with q -> s, inclusive, that are used once in one file and the name of the file.

Proposed resolution

Exclude words covered in #3210125: Fix spelling in core.* yml files

Remove the following from dictionary.txt
1 -querystrings
2 -rawurlencoding
3 -reimplementing
4 -reinitializes
5 -rescan
6 -reuploading
7 -robo
8 -routename
9 -rowtest
10 -rrggbb
11 -rxpq
12 -safed
13 -sapere
14 -scaffol
15 -screenreader
16 -searchpages
17 -shortnames
18 -someclass
19 -somefile
20 -sometext
21 -soofy
22 -startpunt
23 -stringis
24 -subpatterns

Remaining tasks

Review
Commit

User interface changes

API changes

Data model changes

Release notes snippet

Viewing all 297295 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>