High level summary of meeting

TBD

Meeting recording

https://youtu.be/A2e7SsqWik0

Next steps

Per Mihaela, our work has been evolving into three sorts of tracks:

• Prototype development
• User research and *validation*
• Defining needs for project pages themselves

The specific next steps are:

• Matt and Ron will start an issue and shared document to be put here in Slack for everyone to collaborate on as the MVP/1st Prototype definition
• Ruby, Mihaela, Leslie, Bob, others - will help more formally establish the site builder committee (to validate the prototypes and do other research) - and if that group wants to - define a supplementary call. Plan to let everyone know by next meeting

More generally:

• Please keep capturing ideas and feedback in the shared docs and/or issues.

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.

Problem/Motivation

Follow-up for #2843755-19: EntityResource: Provide comprehensive test coverage for Message entity
Message entities are not stored but access handler use permission access site-wide contact form to grant access to this operations

Proposed resolution

Forbid access for useless operations

Remaining tasks

tbd

User interface changes

no

API changes

no

Data model changes

no

Problem/Motivation

Two problems:

1) Unit test requires a database

Running TestSiteApplicationTest in isolation reveals that it errors out.

That's because it uses the SIMPLETEST_DB environmental variable, which is intended for use by KernelTestBase tests.

$ ./vendor/bin/phpunit -c core/ --testsuite unit --filter TestSiteApplicationTest
PHPUnit 6.5.8 by Sebastian Bergmann and contributors.

Testing 
EEESS.                                                              6 / 6 (100%)

Time: 17.01 seconds, Memory: 136.00MB

There were 3 errors:

1) Drupal\Tests\Scripts\TestSiteApplicationTest::testInstallWithNonExistingFile
InvalidArgumentException: Minimum requirement: driver://host/database

/Users/paulmitchum/projects/drupal8/core/lib/Drupal/Core/Database/Database.php:460
/Users/paulmitchum/projects/drupal8/core/tests/Drupal/Tests/Scripts/TestSiteApplicationTest.php:267
/Users/paulmitchum/projects/drupal8/core/tests/Drupal/Tests/Scripts/TestSiteApplicationTest.php:47

This can be mitigated by setting the SIMPLETEST_DB variable in phpunit.xml, but this ruins the isolation between unit and kernel tests.

2) This test is never run by run-tests.sh

Since it lives in core/tests/Scripts, the test is not discovered when run-tests.sh runs tests.

You can see evidence of this in this recent HEAD test. See the actual tests that were run which does not include TestSiteApplicationTest: https://dispatcher.drupalci.org/job/php7_mysql5.5/5506/artifact/jenkins-...

Versus the test list generated for that same build which lists TestSiteApplicationTest: https://dispatcher.drupalci.org/job/php7_mysql5.5/5506/artifact/jenkins-...

Here's an issue about fixing that discrepancy: #2878269: Modify TestDiscovery so the testbot runs all the tests

Proposed resolution

#2878269: Modify TestDiscovery so the testbot runs all the tests is in, so the test has been running.

Convert the test to the new build test framework. This takes it out of the unit testsuite, which helps avoid the need for a database. Also, this test case is much better suited to a build test which can modify the file system to perform site installs in isolation.

Remaining tasks

User interface changes

API changes

Data model changes

Hi,

I am getting a error when I am clearing a cache or opening module page it's happening on live server not in localhost

Error -

Fatal error: Illegal length modifier specified 'f' in s[np]printf call in /core/lib/Drupal/Component/PhpStorage/MTimeProtectedFastFileStorage.php on line 88

Problem/Motivation

In order to be able to cache the rendered output of views result rows, we need support for it when we render entity operation links, see the https://qa.drupal.org/pifr/test/1022293 test failure.

Proposed resolution

Remaining tasks

User interface changes

API changes

Problem/Motivation

In #2962525: Create a field widget for the Media library module, the media edit/view link was disabled in the field widget and widget view in order to prevent unintended data loss. Long term, we would still like the ability to quickly edit media items from the field widget, without navigating to a new page.

Proposed resolution

Allow media items to be edited in a modal while using the field widget. The Entity Browser module allows for similar functionality.

This has some major UX and possibly a11y implications, since it needs to be crystal clear to users that, if they edit a media item in the library, they are editing that item everywhere it appears.

Remaining tasks

• Write a patch
• Write automated tests
• Get sign-off from the usability team
• Get accessibility review and sign-off
• Review code
• Commit!

User interface changes

Undecided.

API changes

None.

Data model changes

None.

I believe this being a follow up to #2291055: REST resources for anonymous users: register.

I am creating an user with the rest resource, configured not to verify email address, and the register_no_approval_required is not sent.

However, registering the user with the same settings through the drupal UI as an anonymous user does send the notification.

One would expect the same behavior:

./core/modules/user/src/RegisterForm.php

    // No email verification required; log in user immediately.
    elseif (!$admin && !\Drupal::config('user.settings')->get('verify_mail') && $account->isActive()) {
      _user_mail_notify('register_no_approval_required', $account);
      user_login_finalize($account);
      drupal_set_message($this->t('Registration successful. You are now logged in.'));
      $form_state->setRedirect('<front>');
    }

./core/modules/user/src/Plugin/rest/resource/UserRegistrationResource.php:

  protected function sendEmailNotifications(UserInterface $account) {
    $approval_settings = $this->userSettings->get('register');
    // No e-mail verification is required. Activating the user.
    if ($approval_settings == USER_REGISTER_VISITORS) {
      if ($this->userSettings->get('verify_mail')) {
        // No administrator approval required.
        _user_mail_notify('register_no_approval_required', $account);
      }
    }
    // Administrator approval required.
    elseif ($approval_settings == USER_REGISTER_VISITORS_ADMINISTRATIVE_APPROVAL) {
      _user_mail_notify('register_pending_approval', $account);
    }
  }

Problem/Motivation

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.

Proposed resolution

Promote the non-stable statuses in admin/modules page, optionally even visually

Remaining tasks

User interface changes

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

API changes

Data model changes

Release notes snippet

Problem/Motivation

Local task labels are always displayed using the content language, ignoring that users can set their admin language preference (if the site has an admin language preference option set in negotiation). Local task label should honor this config and use the admin interface language. Even if they are in a non-admin pages, they are part of the admin interface.

This is very similar to what is being done in #2313309: Admin toolbar should always be rendered in the admin language (if set), but for local tasks. It's worth to note that in that issue current patches seems to translate Contextual Links as well (if not, probably a new issue should be created).

Proposed resolution

Render local task labels using the admin language config from language negotiation.

Remaining tasks

Implement it.

User interface changes

Local task labels will be in an admin-appropriate language. Optionally, a checkbox can be added to make this behavior optional.

API changes

Likely none.

Problem/Motivation

If people want to tweak existing plugins the only way at the moment is to extend and add a new plugin with a different functionality.
For example:
- It's impossible to tweak the default schema of a field being generated by a core field plug-in.
- It's impossible to tweak UI for such customization.

In the end people are just doing separate field type plugins that result in non-semantic distribution of fields, for example:
- String
- String with index.
- String with unique index.
- Short string.
- ... etc.

It is an awful DX, because once you define a new field type, there is no way to reuse existing widgets and formatters for it. You need to define new ones as well (even if they are dummy ones - empty class bodies).

This can be extended, as we can have more granular and single-purpose decorators for whole plug-in types. Imagine the whole logging related to a plugin hierarchy can be standardized by a single decorator implemented by the module maintainer.

Proposed resolution

It will be awesome to have a mechanism that will allow for concrete plugins to be decorated (somehow) based on the interface they expose. This should work in a similar fashion to the services decoration provided by the container.

Plugin decorators should be also decoratable.

Remaining tasks

Discussion, architectural idea for implementation patches etc...

User interface changes

None expected out o this change.
Contributed code will have better capability to customize core's behaviors.

API changes

API addition on the plug-in system.
I am imagining a standard trait to be added to plug-in managers that will decorate plugins after they are fetched by ID.

Data model changes

TBD.

Problem/Motivation

Why is login called user name and also used for screen display?
Just don't understand why drupal uses a login as a user name, it is not secure.
Secure systems never use login for anything like a screen name because it allows others to easily know the first component to access your account.

Proposed resolution

User name should be renamed to login and add a field named user name.
Also like many have asked, at this time make a radio selection box for
1 allow login with user login or email
2 login only
3 email only (system hides login field)

Remaining tasks

all

User interface changes

update fields in /admin/config/people/accounts/form-display/ & /display/
add login option to /admin/config/people/accounts

API changes

any module using name can continue using it for display. any module using name for login purpose would need to change.

Data model changes

change
user_data_field:name to user_data_field:login
add
user_data_field:name

Original report by [username]

I did search, not sure if anyone else has suggested this. probably.

Problem/Motivation

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.

Steps to reproduce

Proposed resolution

Deprecate file_save_data and replace with a service.

Remaining tasks

User interface changes

API changes

file_save_data, file_move() and file_copy() are replaced with a service and deprecated.

Data model changes

Release notes snippet

Problem/Motivation

#1577902: [META] Remove all usages of drupal_static() & drupal_static_reset() wants us to get rid of drupal_static().

#3015538: [META] Deprecate contents of common.inc wants us to deprecate functions in common.inc.

Thus here we feet two birds with one seed.

Proposed resolution

Move the functionality of drupal_get_updaters() into a static method on Drupal\Core\Updater\Updater. Let's call it getUpdaterRegistry().

Instead of using drupal_static() to cache in memory, we'll add a static property to Drupal\Core\Updater\Updater.

Deprecate drupal_get_updaters() in favor of Updater::getUpdaterRegistry().

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Especially with the growth of Features, and the ability to use update module to add/update themes and modules, it seems like a not entirely safe assumtion that what's in the .info file is safe text.

Also, there are modules that let you write themes, for example, via a starting from an existing theme as a template. In that case, a user with a lesser admin permission might be able to inject XSS.

We should sanitize all the elements of te .info file that may be displayed (or maybe jsut all) as a simple hardening.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

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.

Proposed resolution

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.

Remaining tasks

Review and commit the patch.

Release notes snippet

TBD

Problem/Motivation

\Drupal\views\ViewExecutable::$style_plugin and \Drupal\views\ViewExecutable::$rowPlugin
should have corresponding methods, one could call.

Once we do that, we can also mark the public properties as deprecated

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Steps to reproduce:

1. Go to any content add page with textarea field with ckeditor enabled(even for full html format as admin)
2. Click on image add plugin button from toolbar.
3. Insert some image url there and hit save.
4. Now if you double click on image, the edit modal opens with previously inserted details.
5. Now click on view source and then click on it again to normal wsiwyg mode.
6. double click on the image inserted and now the image edit modal no longer opens.

Cause of Issue:

From what i can debug, the issue is related to ckeditor plugin wrappers around the image getting removed once the view source has been clicked. coming back to wsiwyg mode doesn't add the wrappers back around the image and the ckeditor events to open edit image modal are binded to that wrapper.

Html around the image inserted before Clicking view source and image modal opens up on double click:

<body class="cke_editable cke_editable_themed cke_contents_ltr cke_show_borders"
spellcheck="true" style="height: auto; min-height: auto;" contenteditable="true">
  <p><span tabindex="-1" data-cke-widget-wrapper="1" data-cke-filter="off" class=
  "cke_widget_wrapper cke_widget_inline cke_widget_image cke_image_nocaption"
  data-cke-display-name="Bild" data-cke-widget-id="0" role="region" aria-label=
  "Bild Steuerelement" contenteditable="false"><img alt="" src=
  "http://dab1nmslvvntp.cloudfront.net/wp-content/uploads/2015/04/1428068708logo_drupal.png"
  data-cke-widget-keep-attr="0" data-widget="image" class="cke_widget_element"
  data-cke-widget-data=
  "%7B%22hasCaption%22%3Afalse%2C%22src%22%3A%22http%3A%2F%2Fdab1nmslvvntp.cloudfront.net%2Fwp-content%2Fuploads%2F2015%2F04%2F1428068708logo_drupal.png%22%2C%22alt%22%3A%22%22%2C%22width%22%3A%2250%22%2C%22height%22%3A%2250%22%2C%22lock%22%3Atrue%2C%22align%22%3A%22none%22%2C%22classes%22%3Anull%7D"
  data-cke-saved-src=
  "http://dab1nmslvvntp.cloudfront.net/wp-content/uploads/2015/04/1428068708logo_drupal.png"
  width="50" height="50" /><span class="cke_reset cke_widget_drag_handler_container"
  style=
  "background: rgba(220, 220, 220, 0.5) url(&quot;http://hzd.d8/core/assets/vendor/ckeditor/plugins/widget/images/handle.png&quot;) repeat scroll 0% 0%; top: -15px; left: 0px; display: block;"><img class="cke_reset cke_widget_drag_handler"
  data-cke-widget-drag-handler="1" src=
  "data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw=="
  title="Zum Verschieben anw&#228;hlen und ziehen" role="presentation" draggable="true"
  width="15" height="15" /></span><span class="cke_image_resizer" title=
  "Zum Vergr&#246;&#223;ern ausw&#228;hlen und ziehen">&#8203;</span></span><br /></p>
</body>

After clicking view source , the html around the image:

<body class="cke_editable cke_editable_themed cke_contents_ltr cke_show_borders"
spellcheck="true" style="height: auto; min-height: auto;" contenteditable="true">
  <p><img alt="" data-entity-type="" data-entity-uuid="" data-cke-saved-src=
  "http://dab1nmslvvntp.cloudfront.net/wp-content/uploads/2015/04/1428068708logo_drupal.png"
  src=
  "http://dab1nmslvvntp.cloudfront.net/wp-content/uploads/2015/04/1428068708logo_drupal.png"
  width="50" height="50" /></p>
</body>

Problem/Motivation

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.

Proposed resolution

Change the cor/scripts/dev/commit-code-check.sh so that PHPCS will check all files when core/phpcs.xml.dist is changed.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

Problem/Motivation

Part of #2909364: [meta] Fix 'Drupal.Commenting.VariableComment' coding standard.

See parent issue for instructions.

The sniff refers to @var: Class property data types and Indicating data types in documentation.

Proposed resolution

Fix errors found.

Remaining tasks

Review
Commit