Problem/Motivation

Discovered while writing test coverage for #2830326: Broken link to 'Put your site into maintenance mode' on update.php results in WSOD.
Update.php provides a (currently broken, hopefully soon working) link to:

2. Put your site into maintenance mode.

However, that page requires 'administer site configuration', unlike update.php itself. So it's possible (although probably unlikely) that an admin user could access update.php without permission to click that link.

This would also come up for sites that have $settings['update_free_access'] = TRUE; in their settings(.local)?.php file.

Proposed resolution

Expand the permissions required to access /admin/config/development/maintenance so that users with either 'administer site configuration' (current) OR 'administer software updates' (new) are allowed.

Remaining tasks

1. Expand test coverage to reveal the problem.
2. Fix the bug.
3. Reviews.
4. RTBC.
5. Commit.

User interface changes

Not really. A link that used to be 403 (denied) will now work (200) for a certain (rare) class of admin users visiting update.php.

API changes

N/A

Data model changes

N/A

Release notes snippet

TBD.

I set an action to unpublish all comments that contain casino keyword automatically.....but it does not happen..the spammy comments still can be seen published......
I am missing something=

Problem/Motivation

Some blocks, like user login, should be shown on 403/404 pages.
Others, like the help block, should not.

Proposed resolution

Add a visibility setting to blocks that shows them on 403/404 pages.
Default this to TRUE.

Remaining tasks

Write tests

User interface changes

API changes

Drupal Installation done with:

composer create-project drupal-composer/drupal-project:8.x-dev my_site_name_dir --no-interaction

Standard Installation, Installed with German translation

Problem: If you remove the body field of a content type, the following problem occurs. This will effect all Drupal 8 Installations!

Drupal\Core\Entity\EntityStorageException: Field body is unknown. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 847 of /var/www/datacentric/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

InvalidArgumentException: Field body is unknown. in Drupal\Core\Entity\ContentEntityBase->getTranslatedField() (line 587 of /var/www/datacentric/web/core/lib/Drupal/Core/Entity/ContentEntityBase.php).

Since 8.7.0, EntityViewBuilder::__construct() takes an optional fifth argument (non-optional after 9.0.0), which is an EntityDisplayRepositoryInterface implementation.

It then checks whether that argument was indeed passed and triggers a warning if it wasn't. However the message in the warning is incorrect: it mentions Calling EntityViewBuilder::__construct() with the $entity_repository argument [...], but:

• there is already an EntityRepositoryInterface implementation as the second argument
• the warning should actually refer to the fifth argument which is an EntityDisplayRepositoryInterface instead of EntityRepositoryInterface.

Fix: change the wording to Calling EntityViewBuilder::__construct() with the $entity_display_repository argument [...].

After I added youtube video via Media in body I have error:

drupal.js?v=8.8.0:13 Uncaught Error: Quick Edit could not associate the rendered entity field markup (with [data-quickedit-field-id="media/1/field_media_oembed_video/ru/layout_builder-default-0-0c29f75e_13d0_444c_aefb_2c3b13f4fbe1-1-821bf6e4e7b3c8e5fe4cd1b8c9814931c07b28e62a0ce7bb3d6c817b05b2938b"]) with the corresponding rendered entity markup: no parent DOM node found with [data-quickedit-entity-id="media/1"]. This is typically caused by the theme's template for this entity type forgetting to print the attributes.
at processField (quickedit.js?v=8.8.0:181)
at HTMLDivElement. (quickedit.js?v=8.8.0:298)
at Function.each (jquery.min.js?v=3.4.1:2)
at k.fn.init.each (jquery.min.js?v=3.4.1:2)
at Object.attach (quickedit.js?v=8.8.0:297)
at drupal.js?v=8.8.0:25
at Array.forEach ()
at Object.Drupal.attachBehaviors (drupal.js?v=8.8.0:22)
at drupal.init.js?v=8.8.0:28
at HTMLDocument.listener (drupal.init.js?v=8.8.0:20)

The value in the body field:

<drupal-media data-align="center" data-entity-type="media" data-entity-uuid="93e995e5-cc9f-49d7-8121-9321207ee4d6"></drupal-media>

The rendered HTML of the field:

<div class="align-center">
    <div class="layout layout--onecol">
        <div class="layout__region layout__region--content">
            <section class="block block-layout-builder block-field-blockmediaremote-videofield-media-oembed-video clearfix">
                <div data-quickedit-field-id="media/1/field_media_oembed_video/ru/layout_builder-default-0-0c29f75e_13d0_444c_aefb_2c3b13f4fbe1-1-821bf6e4e7b3c8e5fe4cd1b8c9814931c07b28e62a0ce7bb3d6c817b05b2938b"
                     class="field--formatter-oembed field field--name-field-media-oembed-video field--type-string field--label-hidden field--item">
                    <iframe src="/media/oembed?url=https%3A//www.youtube.com/watch%3Fv%3DM_sUWFIo-m0&amp;max_width=0&amp;max_height=0&amp;hash=u7UUh_ENYKBtQigY1AFxxvq6wkT1PbHIGv4NbIQipaA"
                            frameborder="0" allowtransparency="" width="480"
                            height="270" class="media-oembed-content"
                            title="Корректировка показаний весов, обман весов, автомобильные весы"></iframe>
                </div>
            </section>
        </div>
    </div>
</div>

Patch #15 in Custom blocks break layout builder module - Quick Edit could not associate the rendered entity field markup not helped.

Interesting that I don't use Layout builder for this view mode at all.

Problem/Motivation

Lets remove usage of "blacklist" and "whitelist" in Filter module.

They are:

• An historic bad labelling of people
• Provide no context: "what is listed in them"?

Proposed resolution

TBD

Remaining tasks

1. Come up with replacement names.
2. Decide what needs BC + deprecation and what can be changed directly.
3. Fix everything:
   • core/modules/filter/tests/src/Kernel/FilterKernelTest.php
   • core/modules/filter/filter.module
   • core/modules/filter/src/Entity/FilterFormat.php
   • core/modules/filter/src/Plugin/Filter/FilterHtml.php
   • core/modules/filter/src/Element/TextFormat.php
   • core/modules/filter/src/FilterFormatInterface.php
4. Reviews / improvements.
5. RTBC.
6. Commit.

User interface changes

None

API changes

@todo

Data model changes

@todo

Release notes snippet

@todo

Elements inside a form-item can cause unwanted overflow to happen (see screenshot).
Path: admin/content
Patch follows.

Updated in #95

Problem/Motivation

Let's say I have computed field with the string value which shows the current time of the request. Right now there is no way to set cachebality metadata for computed fields so jsonapi shows the time of serialization instead of current time in the response.

Proposed resolution

Proposal 1

Allow computed field item list class to provide cacheable metadata. Using CacheableDependencyTrait. See JsonApiComputedFieldItemList in #37.

Proposal 2

Allow PrimitiveDataNormalizer to set the cacheable metadata. Using RefinableCacheableDependencyTrait and PrimitiveDataNormalizer should bubble it. See the patch in #75

Remaining tasks

• Implemented purposal #2.
• Review
• Commit
• Rejoice

User interface changes

None

API changes

API addition so that computed fields/properties based on PrimitiveData can bubble the cacheable metadata.

Data model changes

PrimitiveDataNormalizer can bubble cacheability metadata.

Problem/Motivation

Currently, when a new user registers for a Drupal account the details are sent to the users supplied email address. This provides a basic mechanism that confirms the user is at that email address. However, once registered, users are permitted to change their email address without further confirming that the user is in fact at that email address.

Possible implications

• A user can change their email address to be that of an unsuspecting third party as no confirmation of change is required. Using a second Drupal account (with it's email address also faked using the same method) the first user is then able to send anonymous malicious messages to the unsuspecting third party
• A slow method for sending spam but exploitable none the less

Proposed resolution

Add a mechanism (similar to reset password) that:

1. Sends an E-mail to the new address requiring the verification of the new address (similar to register confirmation).
2. Sends a notification E-mail to the old address.
3. Allow the site builder to customise both messages at admin/config/people/accounts
4. Provides an update path to set the default behaviour and messages content.
5. Write tests.

This new mechanism is bypassed if the e-mail address is changed by an administrator.

Remaining tasks

1. #279.1: Fix AccountForm->function flagViolations() to avoid hard-coded reference to 'administer users' permissions using code in #284
2. #279.2: Seems to be fixed as well as possible right now given limitations of other issues. Raise a follow-on issue to tidy up once other issues have been fixed.
3. #279.6: Add a test - see further explanation in #284
4. Release note snippet for IS.
5. Security review.
6. Follow-up questions from usability review in #270 and #272.

User interface changes

New UI additions to admin/config/people/accounts:

New confirmation message (warning) when user changes e-mail address:

Default text of the generated e-mail (some elements will vary):

alice,

A request to change your email address has been made at Drupal Usability. You
need to verify the change by clicking on the link below or copying and
pasting it in your browser:

http://drupalux.lndo.site/user/mail-change/2/alice%40example.org/1542687...

This is a one-time URL, so it can be used only once. It expires after one
day. If not used, your email address at Drupal Usability will not change.

After using the one-time link, the user is redirected to the site's home page, with the message (info)

Your email address has been changed to alice@example.org.

API changes

New controller used for mail changing: \Drupal\user\Controller\MailChangeController

Data model changes

New schema for configs user.settings and user.mail.

Release notes snippet

@todo

Problem/Motivation

Currently both the ContentEntityStorageBase and ContentEntityBase is responsible for creating a new translation object:

ContentEntityBase::addTranslation -> 
  ContentEntityStorageBase::createTranslation -> 
  ContentEntityBase::getTranslation

  ...

State is stored and initialised on the content entity, and the storage uses public API to construct translation object with the correct values, this has introduced some difficulties in i.e #2862574: Add ability to track an entity object's dirty fields when you need better control of the construction.

Since creating an object is not coupled to how its stored, I'm wondering if we should decouple that responsibility from ContentEntityStorageBase and let ContentEntityBase alone be responsible for creating the object. This would also become a bit more clean, where the classes don't need to rely on each other.

Proposed resolution

Tbd.

Remaining tasks

Tbd.

User interface changes

API changes

Tbd.

Data model changes

Tbd.

Release notes snippet

When adding aliases through the admin interface, there is a validation check (function aliasExists) to make sure you are not reusing an existing alias. Strangely the function does not prevent you from making a duplicate alias.

To reproduce, go to /admin/config/search/path/add and add an alias with a source. Then do it again (same alias, same source).

If you use different sources you will be stopped from reusing an alias, but nothing stops you from adding a duplicate. Why allow that?

Problem/Motivation

I see a lot of 'a' uses in comments instead of 'an'.

Ex:

• a entity
• a alt
• a author
• a image
• ...

Proposed resolution

Many modules and core files are concerned. I suggest to make all changes here instead of one issue per module since it's only minor documentation issue.

Additional context

Keep in mind:

The choice of a vs. an is actually based on the phonetics of the start of a word, not the orthographic representation.

• “A” vs. “An” in writing vs. pronunciation
• Is it supposed to be a HTML or an HTML

Notes

Note: .js and .css files should be generated from .es6 and .pcss.css files by run

$ cd core
$ npm run build:js
$ npm run build:css

Not touch them directly

We are having an issue where image style are not being applied through CKEditor. To reproduce this:

1. In the WYSIWYG, add an image with the media browser
2. Add a style to the image from the Styles dropdown menu

The markup for the image show:

<drupal-entity alt="maureen-gopher.jpg" data-embed-button="media_browser" data-entity-embed-display="media_image" data-entity-embed-display-settings="{&quot;image_style&quot;:&quot;&quot;,&quot;image_link&quot;:&quot;&quot;}" data-entity-type="media" data-entity-uuid="df35ac51-3c4f-4b95-b934-050cfd25f213" data-langcode="en" title="maureen-gopher.jpg" data-cke-widget-data=......data-cke-widget-keep-attr="0" data-widget="drupalentity" class="cke_widget_element img-circle">
  <div alt="maureen-gopher.jpg" data-embed-button="media_browser" data-entity-embed-display="media_image" data-entity-type="media" data-entity-uuid="df35ac51-3c4f-4b95-b934-050cfd25f213" data-langcode="en" title="maureen-gopher.jpg" class="embedded-entity">  
    <img src="/sites/default/files/maureen-gopher.jpg" alt="maureen-gopher.jpg" title="maureen-gopher.jpg" typeof="foaf:Image">
  </div>
</drupal-entity>

However, when you save, the element, which contains the styles is removed.

This is similar to https://www.drupal.org/project/drupal/issues/2642808 but the behavior seems to be different.

Problem/Motivation

The minimum required version of PostgreSQL is 10. In the Connection class of the PostgreSQL driver we have the following code:

  public function upsert($table, array $options = []) {
    // Use the (faster) native Upsert implementation for PostgreSQL >= 9.5.
    if (version_compare($this->version(), '9.5', '>=')) {
      $class = $this->getDriverClass('NativeUpsert');
    }
    else {
      $class = $this->getDriverClass('Upsert');
    }

    return new $class($this, $table, $options);
  }

The method is no longer necessary.

Proposed resolution

1. Remove the method Drupal\Core\Database\Driver\pgsql\Connection::upsert().
2. Then remove the class Drupal\Core\Database\Driver\pgsql\Upsert.
3. After that rename the class Drupal\Core\Database\Driver\pgsql\NativeUpsert to Drupal\Core\Database\Driver\pgsql\Upsert.
4. In the renamed class, change the class name from "NativeUpsert" to "Upsert" and remove the link to http://www.postgresql.org/docs/9.5/static/sql-insert.html#SQL-ON-CONFLICT.
5. The file "core/modules/system/tests/modules/driver_test/src/Driver/Database/DrivertestPgsql/NativeUpsert.php" can also be removed.

Remaining tasks

TBD

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

TBD

Over in this wiki there's some documentation about monitoring composer libraries for security.

I think the roave/security-advisories project is a great solution to that problem. What if we just relied on that?

Just crash testing patches

Problem/Motivation

@todo

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Follow-up to #1342054: [META] Overhaul Bartik's code.

Problem/Motivation

1. Bartik's template files need to be assessed and cleaned up of redundant markup, bad formatting and ID's.
2. Bartik's CSS files need to follow Drupal's CSS Coding Standards.

Proposed resolution

For this issue we take "sidebar.css" within Bartik in css/components/sidebar.css plus any template file associated with the CSS and clean them up.

CSS formatting tasks to do

1. Remove blank lines where necessary - guidelines are here.
2. The CSS file needs to have the correct File comment at the top of the page - see guidelines here and also reference other fixed Bartik CSS files for wording guidelines.

CSS architecture tasks to do

1. Replace any ID's with classes in the CSS files and Twig files associated with it - see guidelines here.
2. Replace references of HTML elements, for eg H2 with useful classes - see guidelines here.
3. Make sure any layout styles (so widths, margins, floats) are being referenced by a "layout-..." selector rather than just "sidebar".

CSS file structure tasks

1. Move any selectors that do not start with "sidebar" to another appropriate CSS file that starts with the name of the first selector. For eg. "layout-..." styles should be moved to the layout.css file

Remaining tasks

• Write a patch containing as much as the above as possible.
• Post a patch with screenshots.
• Visual review of a patch - check the Sidebar visually with and without patch applied. Take screenshots.
• Code review of a patch - check the code follows coding standards, suggest improvements if needed in a comment.
• Produce a new patch with improvements if needed.

User interface changes

None

API changes

None

Data model changes

None

Beta phase evaluation

Problem/Motivation

Follow up to #2710407: Option for 'Transform dashes in URL to spaces in term name filter values' on term arguments doesn't affect the query

If you have a term "co-worker" and you enable 'Transform dashes in URL to spaces in term name filter values', no matches will be found because the dash will be removed.

So we need to figure out how to handle the case where you have both terms with spaces and terms with dashes, since now it only works with one or the other.

Also need to figure out how to handle this when you have both "co worker" and "co-worker" as terms.

Proposed resolution

If the 'Transform dashes in URL to spaces in term name filter values' checkbox is set, search for terms that match either a space or a dash for any dashes in the argument value.

If multiple terms match, use the most recently created term.

Remaining tasks

1. UX review of '#description' => $this->t('You can have both terms with spaces and terms with dashes like "co worker" and "co-worker". Then only the last created term will be matched.'),
   • Is that the behavior we want? Should it be "last" term, "first" term, other?
   • Is that description text good?
2. Other reviews / refinements.
3. RTBC.
4. Commit.

User interface changes

Adds this description to the 'Transform dashes in URL to spaces in term name filter values' checkbox on the TermName views argument validator options form:

You can have both terms with spaces and terms with dashes like "co worker" and "co-worker". Then only the last created term will be matched.

API changes

None.

Data model changes

None.

Release notes snippet

TBD.