Problem/Motivation

Follow-up from comments #80 and #97 in #2834729-87: [META] Create an MVP for adding and re-using Media.

We might want to allow users to toggle between the media library grid, and the old table-based list.

Misc benefits...

• Offering users a choice of tools is a recognized principle of inclusive design. If you find one interface awkward, try the other.
• Keeping the familiar interface available while they're still leaning the new one, a good strategy to support users with cognitive/learning impairments.
• Reduce frustration for users who might otherwise be annoyed that you took their old tool away, when it worked just fine.
• Many screen readers provide some power tools for navigating table content. Users who are confident with these can save a lot of time with things like "jump to end of row", or quickly going down the title column while ignoring the other fields.
• Sorting the list can easier to understand with a table.
• Reviewing selections (before running bulk-operations) might be easier with a table, too.
• You can fit more items in the viewport with a table than with a card grid. Less scrolling needed for speech control users.

Proposed resolution

Provide a way to swap between the table and card-grid views of the media library.

MVP could just be a pair of views displays configured using the secondary tabs functionality.
A more advanced approach could preserve filters and bulk-operations selections when switching displays.

Remaining tasks

TBD.

User interface changes

The admin/content/media listing would provide a choice between table-based list, or a card-grid interface.

API changes

TBD.

Data model changes

TBD.

Problem/Motivation

For Drupal 8.6, we want to ship with a media library that:

1. Provides a nice visual interface for browsing through all the media items in your site
2. Can be opened from a node form (or similar author-facing context) in order to visually select media items to reference in a field
3. Provides a way to upload several media assets into Drupal, quickly enter metadata for them, and reference them in a field -- all without having to leave the page you're on

Proposed resolution

Implement an MVP media library, based on the user stories and design from #2796001: [prototype] Create design for a Media Library.

This was discussed at DrupalCon Nashville, and we have come up with a plan to land the functionality in three issues, each of which is targeted for 8.6 and blocks the one after it:

1. A Media Library view and associated display mode, with no integration with the Field API, and no dependencies on other issues. This will keep the patch reasonably small, and let reviewers focus on styling and usability. This will essentially be a re-roll of #60, and is happening in #2962110: Add the Media Library module to Drupal core.
2. A field widget for re-using media items from a node form (or other authoring context). This will be done in #2962525: [PP-1] Create a field widget for the Media library module.
3. An addition to the field widget to create new media, probably based on the patches from #2938116: [PP-2] Add a bulk upload form for media. The work will happen in that issue.

All of this will be implemented in an experimental module, called Media Library. Ideally we will be able to merge this module into the main Media module before 8.6. If we manage to implement all three of the issues above on time, we can merge Media Library into Media before 8.6 reaches beta.

User interface changes

This is a new UI, so no existing user interfaces will be affected by this change.

API changes

We may be implementing new APIs for implementing Views-based entity selection, but they will live in the experimental Media Library module. At some point in the future we may decide to port these APIs into Views, but that's not currently part of the scope.

Data model changes

None.

Road-map triage

Must-have

Some already done, e.g. media entity in core

• #2962110: Add the Media Library module to Drupal core
• #2962525: [PP-1] Create a field widget for the Media library module
• #2956368: MediaThumbnailFormatter produces unhelpful text alternative for image media items.
• #2973124: Improve accessibility of EntityOperation views plugin drop-buttons

... and more TBD

Should-have

TBD.

Could-have

• #2973162: allow users to toggle between the media library grid and the old table-based list

... and more TBD.

Problem/Motivation

Using datetime views filter and filtering with an invalid date, there is no validation and fatal error occured.

To reproduce:

• Add a datetime field in an entity bundle.
• Create a view to list this entities and add a filter on this datetime field
• Search for a date with wrong format or for example day in french: lun 2018-04-27. The following error occur:
  

  <em class="placeholder">Exception</em>: DateTime object not set. in <em class="placeholder">Drupal\Component\Datetime\DateTimePlus-&gt;__call()</em> (line <em class="placeholder">355</em> of <em class="placeholder">core/lib/Drupal/Component/Datetime/DateTimePlus.php</em>). <pre class="backtrace">Drupal\datetime\Plugin\views\filter\Date-&gt;opSimple(&#039;sesame_quota_option__field_sesame_opt_date.field_sesame_opt_date_value&#039;) (Line: 314)
  Drupal\views\Plugin\views\filter\NumericFilter-&gt;query() (Line: 1370)
  Drupal\views\ViewExecutable-&gt;_build(&#039;filter&#039;) (Line: 1259)
  Drupal\views\ViewExecutable-&gt;build() (Line: 390)
  Drupal\views\Plugin\views\display\PathPluginBase-&gt;execute() (Line: 180)
  Drupal\views\Plugin\views\display\Page-&gt;execute() (Line: 1627)
  Drupal\views\ViewExecutable-&gt;executeDisplay(&#039;page_1&#039;, Array) (Line: 77)
  Drupal\views\Element\View::preRenderViewElement(Array)
  call_user_func(Array, Array) (Line: 378)
  Drupal\Core\Render\Renderer-&gt;doRender(Array, ) (Line: 195)
  Drupal\Core\Render\Renderer-&gt;render(Array, ) (Line: 226)
  Drupal\Core\Render\MainContent\HtmlRenderer-&gt;Drupal\Core\Render\MainContent\{closure}() (Line: 582)
  Drupal\Core\Render\Renderer-&gt;executeInRenderContext(Object, Object) (Line: 227)
  Drupal\Core\Render\MainContent\HtmlRenderer-&gt;prepare(Array, Object, Object) (Line: 117)
  Drupal\Core\Render\MainContent\HtmlRenderer-&gt;renderResponse(Array, Object, Object) (Line: 90)
  Drupal\Core\EventSubscriber\MainContentViewSubscriber-&gt;onViewRenderArray(Object, &#039;kernel.view&#039;, Object) (Line: 76)
  Drupal\webprofiler\EventDispatcher\TraceableEventDispatcher-&gt;dispatch(&#039;kernel.view&#039;, Object) (Line: 156)
  Symfony\Component\HttpKernel\HttpKernel-&gt;handleRaw(Object, 1) (Line: 68)
  Symfony\Component\HttpKernel\HttpKernel-&gt;handle(Object, 1, 1) (Line: 57)
  Drupal\Core\StackMiddleware\Session-&gt;handle(Object, 1, 1) (Line: 47)
  Drupal\Core\StackMiddleware\KernelPreHandle-&gt;handle(Object, 1, 1) (Line: 99)
  Drupal\page_cache\StackMiddleware\PageCache-&gt;pass(Object, 1, 1) (Line: 78)
  Drupal\page_cache\StackMiddleware\PageCache-&gt;handle(Object, 1, 1) (Line: 47)
  Drupal\Core\StackMiddleware\ReverseProxyMiddleware-&gt;handle(Object, 1, 1) (Line: 38)
  Drupal\webprofiler\StackMiddleware\WebprofilerMiddleware-&gt;handle(Object, 1, 1) (Line: 50)
  Drupal\Core\StackMiddleware\NegotiationMiddleware-&gt;handle(Object, 1, 1) (Line: 23)
  Stack\StackedHttpKernel-&gt;handle(Object, 1, 1) (Line: 664)
  Drupal\Core\DrupalKernel-&gt;handle(Object) (Line: 19)

• Search for the same date with day in english works: mon 2018-04-27. Same for date only: 2018-04-27

Proposed resolution

Mimic the date filter validation from views module.

Remaining tasks

1. Add tests
2. Review

PHP Fatal error: Class name must be a valid object or a string in /var/www/html/includes/common.inc on line 7779, referer: [site]

I have traced this down to the MCAPI module/library. I will enable: Mailchimp Integration, Campaign & Lists. Once they are enabled, all 9 of my sites will work properly, then, out of the blue, they all start throwing the above error. So I truncate the cache table and all works again. I haven't isolated it to the exact module yet. I will be doing that tomorrow. But here is a place to start.

I'm running Open Public on the latest drupal core with all modules up to date, my status page states that MCAPI is installed properly.

Problem/Motivation

#2808233: REST 403 responses don't tell the user *why* access is not granted: requires deep Drupal understanding to figure out introduced the infrastructure to be able to surface the reason for why access is not being allowed. Over there, we used that to provide meaningful, actionable 403 responses when entity access is denied. But … we never did the same for field access!

(I noticed this while working on JSON API test coverage. See #2930028: Comprehensive JSON API integration test coverage phase 1: for every entity type, individual resources only.)

Proposed resolution

When generating a 403 response due to field access not being allowed, check if the access result object contains a reason, and expose it in the error response.

Remaining tasks

Implement!

User interface changes

None.

API changes

None.

Data model changes

Follow-up to #2638140: Error logging should log a backtrace consistently

Problem/Motivation

Software has bugs, so errors are there and will be logged.
Sadly by default Drupal just puts the line of the broken code, which is already helpful, but on the other hand often now really helpful, because you need a full backtrace to figure something out.

Proposed resolution

Log a backtrace on top of the actual error message.
This will just make the backtrace available in the variables section, but won't be displayed as part of the watchdog site.

D7: Make the new setting opt-in and provide a way to get the value.

Remaining tasks

User interface changes

API changes

Data model changes

The users table contains a 'created' column but no 'modified' column. It would be useful to know when a row in the table was last modified to help with things like synchronization and auditing.

Example use case:
Say you want to export a list of all users who were either new to the system or who had changed their email address, on or after a given date (for example the date of a previous export). Without a 'modified' column, it's impossible to know if the 'mail' column has been modified since the user was created.

This means that we can't just export a list of new/updated users to an external system, but have to export ALL user records and check each one to make sure it's not a duplicate before importing to the external system. If the external system only supports CSV imports and doesn't have in-built duplicate checking, this becomes quite a pain because it requires doing an export from the external system first, and comparing the lists to remove duplicates. Even if the external system does have duplicate checking, it requires a larger upload file and unnecessary processing time.
---

It seems like it would be easy enough to add a 'modified' column and have the Drupal user module update it any time an update is made to a row in the users table.

In addition to the use case above, it could be useful for other synchronization scenarios as well.

Drupal 7 issue for #2747075: [meta] Improve WebTestCase / BrowserTestBase performance by 50%

Problem/Motivation

- Tests are slow and installation takes a long time (both for d.org test runs and local development)
- Backdrop found out that installation is deterministic and can easily be cached per profile

Credit: https://github.com/backdrop/backdrop/pull/1366

Their patch works, but is preparing for a known set of profiles instead of demand.

Proposed resolution

- Introduce --cache option for BC compatibility
- Cache database tables and files after installation
- Re-use cache when it exists
- Prevent race conditions with transactions
- Also add --cache-modules for local development only

99% of people don't change the database data or schema during development, so the cache will work fine.

Remaining tasks

- Get it committed to Drupal 7

User interface changes

- None, commandline only. UI change can be follow-up

API changes

- None

Profiling of setUp()

Before is without cache.

--cache

--cache-modules

Problem/Motivation

The responsive menu in Umami has some accessibility problems:

1. The button only does something when JS is enabled. When JS is off, the button is there in markup, but does nothing.
2. Menu links are always in the tabbing order, changing the wrapper's height just hides them visually. A keyboard user will have to tab through these even when the menu is closed. For screen reader users, it defeats the object of the toggle button. For sighted keyboard users, the links are invisible-but-still-operable. This is a failure of WCAG 2.0 SC 2.4.7 Focus Visible.
3. The open closed state of the menu is not conveyed to assistive tech. Screen reader users just know there's a button, not whether the menu is open or closed.
4. Th menu open/close is animated, but some users prefer no motion. We're forming a Drupal core policy around this, see #2928103: [policy, no patch] Use "prefers-reduced-motion" media query to disable animations.
5. The button is outside the navigation landmark. When closed, a screen reader user might search for the navigation landmark region, but find it empty. They should find the button inside the nav landmark region.
6. There are some unnecessary <title> and <desc> elements inside the SVG icon. The accessible name comes from button's own aria-label.

Proposed resolution

1. DEFERRED, NEEDS FOLLOW-UP ISSUE: Remove the button from the Twig template, create it using JS instead
2. DONE: Use display: none or visibility: hidden on the <ul> to remove the links from the tabbing order when the menu is closed.
   • If this is a problem for the animation, do it in two steps. When the menu opens, first remove the display:none, then change the height. Reverse order of these steps when closing.
3. NEEDS WORK: As well as toggling the CSS class for styling, toggle aria-expanded=true|false. This attribute goes on the <button>.
   • The <button> also wants an aria-controls=<IDREF>, pointing to the ID of the <ul> that gets toggled.
4. DONE, NEEDS MANUAL TESTING. Use the new prefers-reduced-motion media query to allow users to turn off animation if their platform allows it (currently just works in Safari).
5. DEFERRED, NEEDS FOLLOW-UP ISSUE: Move the toggle button to just inside the start of <nav>. Note, in the previous github issue this was highlighted as something that could be tricky, because the CSS currently assumes the button is outside the nav.
6. DEFERRED, NEEDS FOLLOW-UP ISSUE: Remove the <title> and <desc> elements from the SVG icon.

Remaining tasks

Update the Umami JS.

User interface changes

No visual changes. Accessibility wins:

1. Conveys the menu open/closed state to assistive tech in a machine readable way.
2. Fixes a failure of WCAG "Focus Visible" for sighted keyboard users
3. Makes the menu button easier to find using landmark navigation in assistive tech.

API changes

None.

Data model changes

None.

Original report

Previously discussed in detail at issue #130 - Improve menu accessibility in the lauriii/umami Github repo.

The parent issue reports a bug in the taxonomy module in Drupal 8. This issue is a backport of that issue to Drupal 7

I created a new vocabulary and i ordered the terms using the reset to alphabetical button. The problem is when clicking on the save button the order of the terms is set back to way it was before i reset the terms to alphabetical.

Steps to reproduce:
1. Create a vocabulary
2. Create terms. I created a,b,c for this case.
4. Order them by b, c, a
5. Click on reset to alphabetical button - the terms are arranged to a,b,c
6. Click on the save button
7. The terms are set back to b, c, a

Please credit `svenryen, nattie, joseph.olstad, mforbes, bwaindwain` from #2908543: Tabledrag is broken when you've scrolled down on the page in chrome 61

Problem/Motivation

After two recent commits, the drag and drop behavior is bugged in IE11: when dragging the bottom item, the page is scrolled to the top of the page.

Behavior before (7.50):

Current behavior (7.53):

The related commits are:
- #1261002: Draggable tables do not work on touch screen devices
- #2821441: Newer Chrome versions and IE11/Edge cannot drag and drop anymore on desktop after 7.51 update when jQuery is updated to 1.7-1.11.0

Proposed resolution

Return the drag and drop behavior in IE11 to the state of Drupal <7.51

Remaining tasks

1. Write a patch
2. Review
3. Commit

User interface changes

The drag and drop behavior in IE11 is unchanged compared to Drupal <7.51

API changes

None

Data model changes

drupal_attributes() should allow boolean values and should output in a way that is consistent with the boolean attribute definition in HTML5. This means omitting attributes that are FALSE and including only the name of attributes that are TRUE.

https://www.w3.org/TR/html5/infrastructure.html#boolean-attributes

Follow up to PostgreSQL: PDOException:Invalid text representation when attempting to load an entity with a string or non-scalar ID.

In comment #256 @soyarma was right, the revision id needs to be cleaned as well. I came across this issue with the webform module. The error in watchdog was:

PDOException: SQLSTATE[22018]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Conversion failed when converting the varchar value 'configure' to data type int.: SELECT revision.[vid] AS [vid], base.[uid] AS [uid], revision.[title] AS [title], revision.[log] AS [log], revision.[status] AS [status], revision.[comment] AS [comment], revision.[promote] AS [promote], revision.[sticky] AS [sticky], revision.[vuuid] AS [vuuid], revision.[ds_switch] AS [ds_switch], base.[nid] AS [nid], base.[type] AS [type], base.[language] AS [language], base.[created] AS [created], base.[changed] AS [changed], base.[tnid] AS [tnid], base.[translate] AS [translate], base.[uuid] AS [uuid], revision.[timestamp] AS [revision_timestamp], revision.[uid] AS [revision_uid] FROM node base INNER JOIN node_revision revision ON revision.nid = base.nid AND revision.vid = :revisionId WHERE ( ([base].[nid] IN (:db_condition_placeholder_0)) ); Array ( [:db_condition_placeholder_0] => 86475 [:revisionId] => configure ) in DrupalDefaultEntityController->load() (line 198 of E:\KDN\includes\entity.inc).

Add README to Bartik Theme.

Add a README.txt to the Seven Theme.

Problem/Motivation

#2768651: Let TimestampItem (de)normalize to/from RFC3339 timestamps, not UNIX timestamps, for better DX fixed the normalization of "Time fields" aka the TimestampItem. But it did so by adding a normalizer for the @FieldType level. It could have been implemented just as well at the @DataType level, but this simply didn't cross anybody's mind AFAICT. At least it wasn't discussed on the issue. (And I was very active on it too, so my bad!)

IOW: not a normalizer with

use Drupal\Core\Field\Plugin\Field\FieldType\TimestampItem;
…
protected $supportedInterfaceOrClass = TimestampItem::class;

but with

\Drupal\Core\TypedData\Plugin\DataType\Timestamp
…
protected $supportedInterfaceOrClass = Timestamp::class;

The benefit is that the normalizers are then no longer format-specific: we'll need only one and it'll work for both the default normalization (serialization module: json + xml formats) and the HAL normalization (hal module: hal_json format). But also for contrib's jsonapi normalization/format!

Note: this will also fix #2870609: [PP-1] Core Date field is serialized as String instead of timestamp/long.

Proposed resolution

1. Add serializer.normalizer.timestamp
2. Add \Drupal\serialization\Normalizer\TimestampNormalizer
3. Deprecate \Drupal\serialization\Normalizer\TimestampItemNormalizer
4. Deprecate \Drupal\serialization\Normalizer\TimeStampItemNormalizerTrait
5. Deprecate \Drupal\hal\Normalizer\TimestampItemNormalizer
6. Deprecate serializer.normalizer.timestamp_item
7. Deprecate serializer.normalizer.timestamp_item.hal

See #72 for a clear overview of the patch.

Remaining tasks

None.

User interface changes

None.

API changes

1. @FieldType=timestamp: no changes!
2. @FieldType=datetime fields configured to store date + time:
   

   Before

   '2017-03-01T20:02:00'

   Note: timezone information is absent!

   After

   '2017-03-01T20:02:00+11:00'

   Note: the site's timezone is present! This is now a valid RFC3339

3. @FieldType=datetime fields configured to store date only:
   

   Before

   '2017-03-01T20:02:00'

   Note: time information is present despite this being a date-only field!

   After

   '2017-03-01'

   RFC3339 only covers combined date and time representations. For date-only representations, we need to use ISO 8601. There isn't a particular name for this date-only format, so we have to hardcode the format. See https://en.wikipedia.org/wiki/ISO_8601#Calendar_dates.
   

Data model changes

None.

Hello,
I have got existing Drupal 8.5 site with hundreds of nodes. With migrate, if i try to upgrade, new nodes are rather created. Node have a field which is being used as key however that seem to be not working. It seems that node are only updated if their record present in migrate_map_xyz. Any suggestions?

CSV data

serial,type
ABC123,Laptop
XYZ124,Laptop
QRS567,Desktop

I don't know if I've found a bug or if I'm doing something wrong. I'm taking the conservative approach and filing this as a support request.

I've got an entity that is defined as such.

My views data is defined as such.

I want to filter on the article status. Its field type is list_string. The Views filter handler is defined as list_field. When I select that field as a filter I get the error message TypeError: Argument 1 passed to options_allowed_values() must implement interface Drupal\\Core\\Field\\FieldStorageDefinitionInterface, null given, called in /core/modules/options/src/Plugin/views/filter/ListField.php

To check out an example that works:
I have added a field to the Basic page content type that is defined as in the attached file.
I created a view that filters on that field that is defined as in the attached file.
I can see that the field is of type list_string and that the view filter handler is of type list_field.

To me it would appear that I've got everything defined the same as the working example for my entity.

What gives?

I've included an issue that may or may not be related.

Problem/Motivation

It would be useful if the Scale and Crop image effect had an anchor option, similar to the basic Crop image effect. The anchor type, such as "center-center", is used to set the top left coordinates of the crop area. Currently, Scale and Crop crops only to the center of an image.

Proposed resolution

Have the ScaleAndCropImageEffect descend from CropImageEffect which provides the anchor option, (rather than ScaleImageEffect which it descends from currently) and do the extra math.

Remaining tasks

1. Write patch with tests
2. Review
3. Commit!

User interface changes

The "Scale and crop" image effect now gives the option of choosing an anchor - it works exactly like the "Crop" image effect (which the plugin is descending from).

API changes

This adds a backwards compatible change to the 'scale_and_crop' image toolkit operation: it now can optionally accept 'x' and 'y' arguments to give an offset.

This really only affects people who are implementing image toolkits (like the ImageMagick module), who will need to do something with these arguments if provided.

Data model changes

This adds the "anchor" key to the plugin configuration for this image effect. The default value is "center-center" which matches the old behavior, so if someone imports an images style which with a "Scale and crop" effect that doesn't have the "anchor" key, it'll automatically get set to "center-center".

In short, old configuration will continue to import just fine with no change in behavior.

But tests that look at the configuration will see the new key, and on export the new key will be added. This is the cause of the majority of the test changes, and the changes to the config files in the demo_umami profile.

In a project we want to embed 1 view page as iframe on another website with a different domain.
Drupal 8 sets the X-Frame-Options Header hard on response with the setting SAMEORIGIN which prevents this.

You'll find the following in FinishResponsesubscriber::onRespond
$response->headers->set('X-Frame-Options', 'SAMEORIGIN', FALSE);

Lets make the domains there configurable and fallback on SAMEORIGIN if there is no configuration.