Problem/Motivation

When deleting a content type field, the UI shows the view as a dependency under configuration deletions and deletes the view when you confirm the delete.
In D7, the view gets automatically updated. (sort of, see #15). Users apparently do not expect this behavior and end up accidentally deleting a whole view. Possible user experience problems with this:

1. The delete section is at the bottom of what is potentially a long list of updated configuration.
2. Users get used to just confirming the less severe configuration entity updates and so are not aware they are deleting a whole view.
3. Even if the user sees the message about deletion, there is no information on how to fix it instead.

Proposed resolution

The behavior itself should not be changed, but we can improve the user experience problem:

• Make deletions more obvious than automated dependency removals, possibly with a confirm form.
• Provide stronger/clearer warnings in the UI, e.g."Warning: You are about to delete an entire view".
• Provide instructions on what to do instead,e.g. "To remove this field without deleting these items, first edit the items so they no longer use this field."

Alternate resolution from #51 and onward:

The behaviour should be changed. By default, the View should just be disabled. An attempt can be made to update it by removing handlers that trigger the dependency, if this still leaves dependencies, disable the View so the user can manually update the View before enabling it again. This will prevent any unexpected data loss.
Things to look at (possibly in follow-ups):

• Make sure the View gets deleted when the module providing the base table is uninstalled (fixed in #83)
• Add a check that a View is valid when enabling it.
• Add a fieldset to the confrm screen with all disabled config instead of putting it under 'updated' (follow up: #2832558: Add a 'disabled' section to config changes page when removing config)

Alternate resolution from #91 and onward:

The behaviour should be changed but only for field handlers. The proposed solution would be to remove any field handlers that have a dependency on any configuration being removed. If that solves all the dependencies then the View can just be updated and saved without this field. Dependencies because of other handlers (filters, relationships et al.) will still cause the whole View to be deleted. The removal of a field handler should have little impact on the overall working of the View, so the normal notice that it will be updated should suffice for that.
The deletion of a View because of a field handler is probably the most commonly occurring situation and the one where removing the handler should not have any dramatic effects.
Follow ups will be opened to see how we can handle the other types of handlers on a handler-type basis.

Remaining tasks

Decide on a proposed resolution. Needs designs and usability review for them once proposed.

User interface changes

TBD

Original report by [username]

I created a 'date' field on a content type and a view to for this content type.
Then i deleted the 'date' field from the content type and the whole view got deleted also without any warnings.

Problem/Motivation

#314385: Make position of #description configurable via the API introduced option #description_display which controls placement of the form element #description.

The options for #description_display are "before", "after", "invisible".

But when using the option #description_display with the form element fieldset ('#type' => 'fieldset') the description is always placed after and the Form API ignores the option at all.

How to reproduce it

1. Install Drupal 8 with the Normal profile.
2. Create and enable a small custom module that alter the Node form. On this form add a simple fieldset. Here is a small sandbox module to test with the 3 options (before, after, invisible) https://www.drupal.org/sandbox/tplcom/2575395
3. Go to node/add/page to see the new fieldset. All the fieldset descriptions are displayed after the elements.

Before (description is always displayed after the elements)

After the patch (what we want!)

Proposed resolution

Applying patch from https://www.drupal.org/node/2396145#comment-10372343 fixes the #description_display the issue but it needs work.

Check comment https://www.drupal.org/node/2396145#comment-10374153 for more details about the patch and what needs to be done.

Problem/Motivation

When #2831274: Bring Media entity module to core as Media module lands we'll have Media entity in core. But it won't be of much use if we don't provide any proper media plugins.

In order to replicate current file field behavior we need support for local documents/files.

Proposed resolution

Adopt documentfile plugin from Media entity document contributed module.

Besides that create a media bundle for documents files with sane default configuration. Location of this bundles still needs to be decided as it could be in module that provides media entity, (experimental) module that implements media library (see: #2796001: [prototype] Create design for a Media Library), in standard or in an experimental profile.

Remaining tasks

- Adopt document file media type plugin handler
- decide where media bundles types will be defined
- create media bundle handler for documents

I have a user who forgot his password, and he started getting the "5 failed attempts" message. So I go in and reset the password manually as an admin.

But the new password will not work, and he continues to get the "5 failed attempts" message. The only thing we could do was delete his user, then recreate it.

Once their password has been changed in the interface by an admin, it should clear the security block, correct? Or is there a manual way to clear the security block? Because the user still says "active".

Problem/Motivation

Original statement:

Need to build out the spinning circle throbber for use in autocomplete and ajax loading events based on the Proposal: A Style Guide for Seven.

Motivation is discussed in more detail in the style guide.

Proposed resolution

(To confirm: does this issue cover approving the new spinner into core? Or is this issue just about coming to some sort of agreement regarding the style guide element[s]?)

Replace the existing spinner with a preferred SVG version, falling back to a GIF for older browsers.

Remaining tasks

1. Write/propose patch. (done: #9)
2. Trial patch. (done: #14)
3. Identify where the spinner is not being applied. (#17)
4. Re-roll/add to patch, in order to cover all instances where spinner is required.
5. RTBC patch.

User interface changes

Superficial, in line with the style guide.

API changes

n/a although patch as stands includes the Modernizr library in its assets.

Data model changes

None.

Coming from #1849610-48: Improve "add" links accessibility I realized how important it would be to have a consistent way to have some sort of tooltip functionality without relying on a link title attribute like we do now.

There are a few problems with tooltips:
http://stevenclark.com.au/2008/06/30/title-attributes-on-links-tooltips-...

Often though it comes down to simply duplicating the information provided to a screen reader user. There's also an issue about how support for titles isn't consistent across different Assistive Technology:
http://www.paciellogroup.com/resources/articles/WE05/forms.html

But there is an approach to do this with jQuery which is themable & has been tested for accessibility:
http://api.jqueryui.com/tooltip/

What I'd like to see though is that the tooltip or title doesn't replace the information provided to screen readers with text hidden by element-invisible.

Having a common API that can be leveraged & extended would help Core & other modules.

Problem/Motivation

Core option fields don't allow using predefined select list. One can use https://github.com/Realityloop/list_predefined_options to add the functionality which is an unoffical port of http://drupal.org/project/list_predefined_options.

It is a very generic functionality i.e. country list, states lists, timezones and language list.

Proposed resolution

Move https://github.com/Realityloop/list_predefined_options functionality to the core. It shouldn't have to be an experimental module.

Remaining tasks

Create Ptach

User interface changes

None

API changes

None

During the drupal installation, after requirements check some messages are shown. They can be status message indicating that a particular thing is ok or error messages containing information to fix the problem.

At this time, a blind user must ensure that everything is ok browsing all them.

My proposal is to group these messages in a table, maybe with these columns:
1. "Status": it should indicate "ok" or "error";
2. "requirement": it should indicate the requirement the message refers to;
3. Message: the content of the message.

In addition to this, I think we could place error messages in the first rows of the table, so that it can be really easier and faster to find them!

What do you think about this?

Problem/Motivation

#2503755: Switch from user login block to login menu link and search block in standard profile got committed and then needed to be reverted because there was a single test failure in both SQLite and Postgres, that was only discovered after commit (because we don't test every patch against those two DBs, but we do test HEAD against them).

After a long search, the root cause was discovered at #2503755-142: Switch from user login block to login menu link and search block in standard profile:

I found the root cause.

There are two.

On MySQL, ToolbarAdminMenuTest::testLocaleTranslationSubtreesHashCacheClear(), where it saves a translation ($this->drupalPostForm('admin/config/regional/translate', $edit, t('Save translations'));) is posting the translation for Menus to the first text area on this page:

On SQLite, it looks like this:

On SQLite, but without this patch's DefaultMenuLinkTreeManipulators and MenuLinkBase hunks, it looks like this:

Root cause one: config_translation behaves differently in SQLite/Postgres vs. Mysql

Note how there is one match in MySQL versus 3 in SQLite. Note how MySQL appears to be doing case-sensitive matching, and SQLite case-insensitive.

Root cause two: different ordering with this patch

Somehow, the changes in DefaultMenuLinkTreeManipulators and/or MenuLinkBase are causing a different ordering of those 3 matches.

Conclusion

The test assumes there will be only one match. It's only by chance that HEAD is passing, because in HEAD the first match just happens to be the right one. It should actually only show one match.
So the test translates the WRONG string, and therefore the toolbar menu is the same before and after, and hence the subtrees hash doesn't change on SQLite/Postgres.

Clearly, there are much deeper problems at play here.

This was one giant WTF! It'd be funny if it wasn't just before RC and I now have to somehow fix SQLite support in code totally unrelated to this issue…

Then, Gábor Hojtsy did a further analysis, figuring out why it's behaving differently on SQLite/Postgres, i.e. where the DB mismatch exists, over at #2503755-144: Switch from user login block to login menu link and search block in standard profile:

Looking at the locale schema (the bug has nothing to do with config translation):

function locale_schema() {
  $schema['locales_source'] = array('description' => 'List of English source strings.','fields' => array(
      // ...'source' => array('type' => 'text','mysql_type' => 'blob','not null' => TRUE,'description' => 'The original string in English.',
      ),
      // ...
    ),'primary key' => array('lid'),'indexes' => array('source_context' => array(array('source', 30), 'context'),
    ),
  );

  $schema['locales_target'] = array('description' => 'Stores translated versions of strings.','fields' => array(
      // ...'translation' => array('type' => 'text','mysql_type' => 'blob','not null' => TRUE,'description' => 'Translation string value in this language.',
      ),
      // ...
  );

So in both cases, specifies blob only for MySQL specifically. I don't know if there was a reason to not specify blob for other DB engines given the 'type' key itself supports blob as per our docs:

 *     - 'type': The generic datatype: 'char', 'varchar', 'text', 'blob', 'int',
 *       'float', 'numeric', or 'serial'. Most types just map to the according
 *       database engine specific datatypes. Use 'serial' for auto incrementing
 *       fields. This will expand to 'INT auto_increment' on MySQL.
 *       A special 'varchar_ascii' type is also available for limiting machine
 *       name field to US ASCII characters.
 *     - 'mysql_type', 'pgsql_type', 'sqlite_type', etc.: If you need to
 *       use a record type not included in the officially supported list
 *       of types above, you can specify a type for each database
 *       backend. In this case, you can leave out the type parameter,
 *       but be advised that your schema will fail to load on backends that
 *       do not have a type specified. A possible solution can be to
 *       use the "text" type as a fallback.

As per our database.api.php. OTOH looking at the SQLite schema driver, it would only make a text field case insensitive if we did explictly provide a binary key with a FALSE value:

      if (in_array($spec['sqlite_type'], array('VARCHAR', 'TEXT'))) {
        if (isset($spec['length'])) {
          $sql .= '(' . $spec['length'] . ')';
        }

        if (isset($spec['binary']) && $spec['binary'] === FALSE) {
          $sql .= ' COLLATE NOCASE_UTF8';
        }
      }

Did not find the relevant code in the PgSQL driver.

Proposed resolution

Adjust locale.module's DB schema per Gábor's findings.

Remaining tasks

TBD

User interface changes

None.

API changes

None.

Data model changes

None.

Following from #2002336: Introduce a CSS class to hide borders of fieldset elements

Problem/Motivation

There are times that you want to remove the border from a table in Drupal. Having a generalized CSS class that can be used to hide borders for table headings (like used in the Install page) could be useful.

Proposed resolution

Add new CSS utility classes to style a table without borders.
Keep these in a new tableborder.module.css file.

Remaining tasks

• Build a generalized addition to the system module CSS library.
• Test for accessibility.
• Should the new utility class be added to the Stable theme? It's a (probably) non-breaking API addition.

User interface changes

None.
This introduces a utility class for style border-less tables, but doesn't apply it to any actual cores tables yet.

API changes

Adds a new utility class in System module to style a table with no visible borders.

Data model changes

None.

Currently most (all) D8 themes 'Skip to content' link target the markup:

<a id="main-content" tabindex="-1"></a>

When we should be targeting something like:

<main id="main-content" role="main" tabindex="-1"></main>

This extra a tag that's missing an href attribute and textual content, isn't really needed and should be removed.

After running across #1332694: Disable AHAH (javascript) on filefield I realized that I should open an issue.

Currently there is little information / context to help a screen-reader user understand what is happening when they upload a file using a file field. This is true for both those w/ Javascript disabled and enabled.

I don't really think that there is much to do for those w/ JS disabled, and there is at least the knowledge that the page has reloaded.

For those w/ JS enabled we should be adding a WAI-ARIA live region to indicate that the file is being uploaded / upload has completed.

Problem/Motivation

Follow-up to #2712647: Update Symfony components to ~3.1 since 3.2.0 is already out. Symfony 3.2.0 was released on November 30, 2016, and #2712647: Update Symfony components to ~3.1 landed on December 1, 2016.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Add API documentation to the Flatten process plugin

API page: http://api.drupal.org/api/drupal/modules--field--field.attach.inc/group/...

"Each field defines which storage backend it uses."

Does that mean field type, ie, defined and fixed by the module that defines the field type?
Or each field that is defined in the UI, ie for each row in {field_config}?
Or for each field instance?

My money's on the first, but it's not clear in the text.

Would be nice if the FormState object could determine whether a form's values have changed, so to say that whether it is dirty.

Problem/Motivation

Related to #2161337: Add a Date Range field type with support for end date

People want to have datetimes with start and end dates.

Proposed resolution

Add DateTime Range as an experimental module https://www.drupal.org/core/experimental

Proposal roadmap

Required sign-off before commit

For this module to become a stable part of Drupal core, all of the "Must-have" and most "Should-have" followups should be completed before the beta phase for 8.4.0.

Must-have

https://www.drupal.org/core/experimental#requirements

Experimental modules are not subject to the same rigorous quality standards as stable Drupal core modules and do not yet need to meet all the Drupal core gates. They can be added with known architectural issues, imperfect coding standards (so long as they do not fail automated checks), minimal UIs, outstanding issues, etc.

These must-haves will need to be completed prior to 8.4.0-beta1.

• verify removing the module without can be done without lasting disruption
• create followups to meet the core gates.
  • Usability review, including #2788359: datetime_wrapper improperly applied to DateTimeWidgetBase
  • Accessibility fixes including #1918994: Date fields labels are not accessible and probably an additional followup for the datetime_range field itself (see #2161337-319: Add a Date Range field type with support for end date and https://www.drupal.org/files/issues/Screen%20Shot%202016-08-19%20at%209....).
• datetime_range_help() - done
• Followup step: Add the stable module to Standard.

Should-have

• Translatable string context for field labels: #2796145: Daterange field labels not specific enough
  

  It would be nice to add "context" to the start and end strings so that someone translating those interface strings would know they have to deal with dates.

• Discuss whether to make BC changes to datetime in DateTimeDefaultFormatter, DateTimePlainFormatter etc. related to the buildDate() trait (see https://www.drupal.org/files/issues/2161337-missing-hunks.txt).
• There is still some code duplication we could refactor away besides the above trait. Many methods on the various plugins override the parent method to more or less repeat what it did, but on both the start and end dates. We could refactor away a lot of this by creating protected helper methods for things that are used internally in the parent and then reused in the overridden child method.
• Ensure the custom daterange formatter and configurable separator support RTL:#2787105: Add RTL support for daterange formatters
  

  Might make sense to have this as its own template so it is easier to customize. Also, what about RTL languages?

  Going to play the Stupid American card, and ask what the proper way to handle RTL is? Inject LanguageManager, then check $languageManager->getCurrentLanguage()->getDirection() and change the element order if the result is DIRECTION_RTL? Not really seeing anything in core as an example (may not be tracing this out right or fully).

  This seems like a sound approach. In ckeditor.admin.inc there is some use of this, but it didn't look like it was swapping the order of anything, but rather using a different image button based on RTL.

  This might not actually be an issue -- manually test it. See#2788253-45: Plan for DateTime Range experimental module
  Working as designed, see #2787105-6: Add RTL support for daterange formatters

• Date range separator should be translatable: #2796151: Date range separator should be translatable

Could-have

• Daterange specific argument, filter, and sort Views plugins

• This trait is specific to formatters, so perhaps rename to DateTimeRangeFormatterTrait? And maybe also move into the Drupal\datetime_range\Plugin\Field\FieldFormatter namespace?

• Finally, if we're rerolling this patch anyway with any changes to the trait for the above, should we also move defaultSettings(), settingsForm(), and settingsSummary() to the trait, since those are identical between the 3 formatters? Even viewElements() could almost be moved there, so long as DateRangeDefaultFormatter could extend the trait's method and additionally handle the $item->_attributes logic.

• Allow templating of the whole formatter to make date ranges easy to customize (beyond just the configurable separator).
• Or, if templating is not provided, consider moving the space into the separator:
  

  +++ b/core/modules/datetime_range/src/Plugin/Field/FieldFormatter/DateRangeCustomFormatter.php
  @@ -0,0 +1,96 @@
  +            'separator' => ['#plain_text' => '' . $separator . ''],
  
  +++ b/core/modules/datetime_range/src/Plugin/Field/FieldFormatter/DateRangeDefaultFormatter.php
  @@ -0,0 +1,104 @@
  +      

  This hardcodes the spaces surrounding the separator, should we move those into the separator variable instead?

• Should the separator support HTML entities? (But: still ensure it's sanitized.)

Not in scope

Already complete in the experimental prototype (or not applicable)

• check for security issues.
• check for data integrity issues.
• verify no disruption or regression to stable functionality
• verify functional test coverage exists for the primary usecase, with no test failures in HEAD
• document Ideas/prototypes for user interfaces that are planned
• minimally validate prototypes for user interfaces
• document any critical issues that maintainers identify as hard blockers
• verify any critical issues that maintainers identify as hard blockers, are fixed
• open followups for additional test coverage that might be needed in the future
• verify basic API documentation exists for the minimum requirements
• document a timeframe for completing the remaining work (typically two minor releases), a plan for addressing followups, and roughly which followups must be completed to keep the module in core.
• Verify UI, API, Data module changes in this issue summary, they were copied from #2161337: Add a Date Range field type with support for end date
• document a plan/open followups for completing more comprehensive documentation in the codebase and handbook (what topics are needed)

Review notes

When reviewing proposed experimental modules, consider whether your feedback is part of these minimal requirements, or whether it should instead be followup work as part of making the experimental module stable. If it does not need to block commit, post a followup issue on the roadmap instead of commenting on the initial patch.

[add more notes that are helpful for reviewers]

Contributed projects

https://www.drupal.org/project/datetime_extras

User interface changes

New field widgets.

API changes

New field type and associated goodness.

Data model changes

New schema for date ranges.

Problem/Motivation

From https://www.drupal.org/node/2787105#comment-11869670

OTOH while I was looking at this, I found that datetime.schema.yml does not use the "built-in" date_format type, so it would not show up with the proper preview/help in config translation. If that switches to use the date_format type, then the UI is better as well for this pattern. We can move this to a different issue if repurposing this one is too much of a headache.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

A number of methods in database.inc end with a return ... but do not state the variable type in a docblock @return statement.

For D8, this includes:

* db_create_table
* db_rename_table
* db_add_field
* db_field_set_default
* db_field_set_no_default
* db_add_primary_key
* db_add_unique_key
* db_add_index
* db_change_field

When backporting to D7, this list might be different.

Add @return statements; get patch approved, then backport to D7. These functions are all deprecated, but they won't be going away any time soon!

I was just forwarded this article - http://hugogiraudel.com/2016/10/13/css-hide-and-seek/

I haven't tested this, but essentially she's recommending:

.visually-hidden {
  border: 0 !important;
  clip: rect(1px, 1px, 1px, 1px) !important;
  clip-path: inset(50%) !important;
  height: 1px !important;
  overflow: hidden !important;
  padding: 0 !important;
  position: absolute !important;
  width: 1px !important;
  white-space: nowrap !important;
}

.visually-hidden.focusable:active,
.visually-hidden.focusable:focus {
  clip-path: none !important;
  height: auto !important;
  overflow: visible !important;
  position: static !important;
  width: auto !important;
  white-space: normal !important;
}

We'd need to keep clip (even though it is depreciated) and add clip-path as the latter's support isn't all that great thus far.

Would love feedback on this.