The issue is that the image dimensions do not appear in the <img> tag thereby showing up in the reports of GTMetrix.
A solution I could think of is that since fallback image URL is given in the <img> tag, the width and height of the fallback image itself should be provided there.
The only use of AccessCheckInterface::applies in core is in CheckProvider::applies which treats the return value as boolean. Every implementation of this method in core, that being CsrfRequestHeaderAccessCheck::applies happens to return a boolean. AccessManagerTest::testSetChecksWithDynamicAccessChecker has a mock and it returns a boolean. All contrib I can see http://grep.xnddx.ru/search?text=AccessCheckInterface&filename= returns a boolean.
It was a boolean in #1793520: Add access control mechanism for new router system, it was modified to be an array in #2012382: Improve efficiency of access checker matching on routes but it seems to be incorrect there because it was the protected applies method on AccessManager which returned an array not the checkers themselves.
If it quacks like a duck and walks like a duck ... is it a duck?
Change the doxygen to say it's a boolean.
Currently, there's the ability to use the Register form mode (created in core user module) on the /admin/config/people/accounts/form-display page, which when enabled, will be automatically used when viewing the user register form. There isn't any control in what form mode should be used for the user register page and this means that administrators with the permission 'Administer users' are restricted by the same form display.
Add the setting "User register form mode" which allows site builders to define a form mode at /admin/config/people/accounts that will be used for users without the permission 'Administer users' and potentially remove the default to use the Register form mode.
Confirm solution and implement
Original issue:
Atm, there's no way or UI so that one could assign the custom "form mode" to the User Register form.
Is that something already under the radar? I would like to work on this and contribute the same to core!
Dropbuttons in tables are not positioned correctly because of various table cell alignments.
For example: /admin/structure/display-modes/view
We would probably something more like this:
hook_install() allows developers to do programatic things during a module or install profile installation. For example, the standard profile uses hook_install() to create 2 shortcut content entities. This can be problematic because if the install is done during configuration import configuration entities are created after any module installs have been done. This is because it is possible to change a configuration entity and make it depend on things that are yet to be installed.
This problem has affected #2788777: Allow a site-specific profile to be installed from existing config and the Lightning install profile.
Add documentation to hook_install() to make developers aware of the problems of relying on configuration entities during hook_install() and ways in which modules have got around this.
None
None
None
Improper definition of exposedHeaders in sites/default/default.services.yml causes the following watchdog error.
Warning: implode(): Invalid arguments passed in Asm89\Stack\CorsService->addActualRequestHeaders() (line 85 of /my/drupal/vendor/asm89/stack-cors/src/Asm89/Stack/CorsService.php)
#0 /my/drupal/core/includes/bootstrap.inc(566): _drupal_error_handler_real(2, 'implode(): Inva...', '/my/drupal/...', 85, Array)
#1 [internal function]: _drupal_error_handler(2, 'implode(): Inva...', '/my/drupal/...', 85, Array)
#2 /my/drupal/vendor/asm89/stack-cors/src/Asm89/Stack/CorsService.php(85): implode(', ', true)
#3 /my/drupal/vendor/asm89/stack-cors/src/Asm89/Stack/Cors.php(53): Asm89\Stack\CorsService->addActualRequestHeaders(Object(Symfony\Component\HttpFoundation\JsonResponse), Object(Symfony\Component\HttpFoundation\Request))
#4 /my/drupal/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Asm89\Stack\Cors->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#5 /my/drupal/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(50): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#6 /my/drupal/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#7 /my/drupal/core/lib/Drupal/Core/DrupalKernel.php(656): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#8 /my/drupal/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #9 {main}.
This is due to the fact that asm89/stack-cors expects exposedHeaders to either be false, or an array. If you end up setting this to true it tries to implode a boolean and throws an error.
Spin-off from #3087644: Remove Drupal 8 updates up to and including 88**.
Once we've removed older Drupal 8 updates from Drupal 9, it will be necessary for all new updates added to the code base to be tested from a Drupal 8.8.x starting point, since Drupal 9 won't be able to run updates from 8.7.x or earlier databases any more.
Our Drupal 8 test coverage is reliant on database dumps, but we did recently add #3031379: Add a new test type to do real update testing which provides an alternative way to test updates - by installing Drupal then updating the install instead of loading a database dump.
Whichever we use, we need boilerplate test coverage for running updates. Something like the following for basic test coverage:
- both minimal and standard install profiles. (and standard+).
- The source site/database needs to have content created in it (nodes, taxonomy terms, users) so that there's actually something to update in there.
Marking critical because it is going to block either the Drupal 9 beta, or adding new upgrade paths to Drupal 8, depending on whether this issue or the update removal one happens first. Also if we add new updates to 8.8.x using our old testing harness, we'll need to refactor the test coverage for them anyway, so really it should block new updates either way.
When exporting configuration, every config file gets exported, not only the files that have actually changed. This can cause some major unneeded performance drawbacks when having a lot of configuration files.
Proposal: only export the files that have actually changed.
Steps to reproduce:
' values
Make sure the ' (apostrophe) special character is not escaped.
On a layout builder page I am seeing data loss when saving an existing block with source mode enabled in ckeditor. At least the data loss is quite obvious ;)
Steps to reproduce:
Once I changed back to non-source mode before saving the changes are saved properly.
This is a bit more severe with ckeditor_config (on a core 8.7.8 install with a lot modules installed) module enabled.
Steps to reproduce:
startupMode = source to ckeditor_config settings in basic_html(Disclaimer: In the variation I am not 100% sure if it is because of the mentioned ckeditor_config settings, at least I haven't verified on a vanilla drupal install)
For image field, we get two formatters:
<img>But in case of referenced media field : Thumbnail formatter is present to render the media in <img>.
This is a feature request to add URL to media thumbnail for media reference fields which provides functionality similar to URL to image formatter in image field.
As shown in #2699895: Allow configurable date attributes to collect, the Drupal 7 date module allowed the site builder to configure which granularity to collect:
For example, on my personal site, I have a projectNodeType which has a "time range"date field that only cares about year + month granularity. Example: https://wimleers.com/work/project/cdn-far-future-expiration-drupal-7 and https://wimleers.com/work/project/ledgrid.
There are some values like 2008-00-00T00:00 and 2006-10-00T00:00 in the D7 datatabase, which cause a hard failure during migration:
Make \Drupal\migrate\Plugin\migrate\process\FormatDate::transform() detect -00-00T and -00T ISO8601 timestamps and transform to valid values.
This then results in the following DB tables in D8: 
TBD
N/A
N/A
N/A
TBD
Found using Umami profile on Chrome at admin/config/media/image-toolkit
In form-text.css, .form-element with is set to 100% at widths up to 600px. This pushes suffixes to a new line.
Some modules Display Suite and Pathologic both do not remove filter configuration upon uninstall. With this in mind Drupal 7 doesn't show these filter configuration settings for those modules... but it still exists in the database.
Consider adding some logic that will only pull filters from modules that are enabled.
I'd like to request new core functionality to allow site administrator the ability to grant users of certain roles access to another users email address.
Currently access to a user email addresses is restricted to Admin accounts only. IE if a users email address is output in a view it will not show for users other than Admins.
Example for a use case is an Intranet, were one user may want to contact another user via an email link.
Together with hchonov we found a race condition with CSRF token generation.
We can reproduce this in our test with behat and with prefetch_cache module enabled (as it does additional calls to forms). But X-Debug needs to be disabled as timing is crucial here.
What the test does is:
* Login as user
* Go to /user
* Click on edit
* Save profile
This ends up with "The form has become outdated. Copy any unsaved work in the form below and then reload this page".
After some debugging and testing we found the following race condition. If you open a form multiple times without having an form opened before, the CSRF token is generated for each form. Ending up in only a single form having a valid token.
The test with prefetch_cache module just helps here, as prefetch module tries to prefetch the edit form (first form opened) and at the same time the user is already clicking on edit (second form opened).
Now if the second call is faster then your form has token ABCD. Then the first form finishes and your session token is now EFGH. As no CSFR token was set before both set it.
When you click on on save, the form validation fails as ABCD != EFGH.
I can't create a phpunit test for this, as php is not async and the only way to test this is, if we could do two requests at similar times. In our environment this just happens as accident because of the prefetch_cache
Call \Drupal::service('csrf_token')->get(); inside user_login_finalize.
Optimise entity reference autocomplete widget should load referencable entities as little as possible, instead of each time form element is rendered.
Currently \Drupal\Core\Field\Plugin\Field\FieldWidget\EntityReferenceAutocompleteWidget::formElement is called for each field item, but calls $items->referencedEntities() each time. This method loads referencable entities for all field items.
In cases for example where Entity Reference Revisions are used, referencedEntities actually loads revisions, which do not have a cache! (See #2620980: ContentEntityStorageBase::loadRevision() should use the static and the persistent entity cache like ContentEntityStorageBase::load()), so page load time and database queries increase exponentially.
Follow-up of #3089900: Drupal 8.8/8.9/9.0 update test coverage
It's very painful to write update tests for modules that aren't enabled in the filled dump by default.
That issue on purpose kept the filled dump as similar as possible but as discussed in Slack, we should enable new stable modules there as well and also add some content (medias, layouts, drafts..?)
From TermForm::buildEntity:
// Assign parents with proper delta values starting from 0.
$term->parent = array_keys($form_state->getValue('parent'));
With a normal select form element the result in form state usually would be [1 => '1', 5 => '5'] and in this case TermForm::buildEntity will process the values correctly, but if the form element for the parent property is disabled with '#disabled' then the form state value for it would be [0 => '1', 1 => '5'].
It is wrong to assume the keys are the proper field values...
Replace array_keys with array_values to ensure the proper field values are extracted and there will be proper delta order as well.
Do we need tests? It is a pretty simple issue...
none
none
none
Comment storage injects optional entity.last_installed_schema.repository service but does not use it except constructor
As the argument is optional it could be safely removed
patch and commit
not
no, constructor optional argument
no
no