Coming from #2045039-7: Cleanup HTML heading structure @terrill:

That said, I still think we should add aria-label attributes to all elements. There are many of these on each page, and without a label they're each identified by screen readers as "Navigation region" - there's no means of clarifying which navigation region is which. If we add aria-label, screen readers use the value of aria-label when identifying the region (e.g., "Toolbar Items Navigation Region", "Breadcrumb Navigation Region", and the like)

@falcon03 and later on:

Well, I think that hearing messages like "entering navigation", "entering main" and so on doesn't give a real "context". So, as a blind user, I'm completely in favor of adding aria-labels.

@pratikp1 and finally:

Having an effective label is essential. I would like some discussion about that for D8 or D9. Let's see if we can make it more understandable. It will go a long way toward having users understand that landmarks can actually be useful.

I don't know why there isn't any in Seven, but in Bartik, we can find the <nav> element in:
core/themes/bartik/templates/comment.html.twig
core/themes/bartik/templates/page.html.twig

And in modules it's in:
core/modules/book/templates/book-all-books-block.html.twig
core/modules/book/templates/book-navigation.html.twig
core/modules/system/templates/breadcrumb.html.twig
core/modules/system/templates/page.html.twig
core/modules/toolbar/toolbar.module

Where else do we find them?

Some more info on using aria-labels:
http://www.last-child.com/debugging-aria-label/

Problem/Motivation

When installing a fresh Drupal install, at step "Set up database" during "Database Configuration",
- choose MySQL database
- insert a database name with special character, for instance "drupal8-dev"
Assuming that drupal8-dev does not yet exists, Drupal will create it (probably assuming that your DB user has permission to do so).
Then process fails with following symptoms:
- UI indication "Drupal already installed".
- settings.php file create with database properly setted to drupal8-dev.
- table drupal8dev created in DB, note that the dash in the name is lost.
- exception AlreadyInstalledException is thrown from install.core.inc 471 after if (Database::getConnectionInfo()) { fails.

In 8.0.x,
Drupal creates the database and reports "Drupal already installed.", but fails to install.

In 8.1.x, there is a fatal:
Update, the exception is now:

Fatal error: Uncaught exception 'Symfony\Component\DependencyInjection\Exception\InvalidArgumentException' with message 'The service definition "renderer" does not exist.' in /Users/cjm/Sites/drupal8x/vendor/symfony/dependency-injection/ContainerBuilder.php:796 Stack trace: #0 /Users/cjm/Sites/drupal8x/vendor/symfony/dependency-injection/ContainerBuilder.php(440): Symfony\Component\DependencyInjection\ContainerBuilder->getDefinition('renderer') #1 /Users/cjm/Sites/drupal8x/core/lib/Drupal.php(158): Symfony\Component\DependencyInjection\ContainerBuilder->get('renderer') #2 /Users/cjm/Sites/drupal8x/core/includes/install.core.inc(1151): Drupal::service('renderer') #3 /Users/cjm/Sites/drupal8x/core/includes/install.core.inc(1089): install_database_errors(Array, './sites/default...') #4 /Users/cjm/Sites/drupal8x/core/includes/install.core.inc(366): install_verify_database_settings('sites/default') #5 /Users/cjm/Sites/drupal8x/core/includes/install.core.inc(113): install_begin_request(Object(Composer\Autoload\ClassLoader), Arr in /Users/cjm/Sites/drupal8x/vendor/symfony/dependency-injection/ContainerBuilder.php on line 796

Proposed resolution

To be investigated. The problem at this stage is that the database name is escaped before being created but the unescaped name is written to settings.php.

Remaining tasks

- Investigate issue
- Write patch
- Review patch

User interface changes

None

API changes

None

Credits go to @stefanosala, @swentel, @jhedstrom, @cilefen, @JeroenT, @daffie, @dasginganinja for their work on all the patches. Sorry if I've forgot someone.

i set url

for example
tours/belgorod

but i see it like
index.php/tours/belgorod

check shows that there are no addresses with index.php
/admin/config/search/path/

Problem/Motivation

User profile categories in Drupal 6 are translated using the i18nprofile submodule of the i18n suite. We need to migrate these translations.

Proposed resolution

1. Establish a system to migrate configuration translations since this is the first issue that needs it. Drupal\migrate\Plugin\migrate\destination\EntityConfigBase is changed to take the language manager and the config factory in its constructor. Change import() and updateEntity() to support translations. Expand rollback() to support for rolling back config translations.

2. User profile field translations are stored within i18n_strings and locales_target tables connected by the lid key on Drupal 6. These profile values are fields in the user entity on Drupal 8. Migrate the title and description of the fields to Drupal 8.

3. Add tests.

Remaining tasks

Migrate field options translations (if field options themselves are migrated). This is to be handled in a followup.

User interface changes

None.

API changes

Constructor of Drupal\migrate\Plugin\migrate\destination\EntityConfigBase gets two new arguments. As per https://www.drupal.org/core/d8-bc-policy the constructor of a plugin is considered internal and thus does not explicitly count as an API change.

Data model changes

None.

Problem/Motivation

When attempting to PATCH an entity, and the type key is missing from the body object, the error message is confusing and not obviously related to the missing field.

For example, a PATCH request to /node/201 with the following body,

{"title": [{"value": "API EDIT PAGE"
	}],"body": [{"value": "<p>Body Value<\/p>\r\n","format": "basic_html","summary": "Body Summary"
	}]
}

results in a HTTP 400 error with the error message, {"error":"A string must be provided as a bundle value."}.

To a developer who is not familiar with Drupal, and just trying to use the REST API, the term bundle means nothing. However the missing key is not actually returned in the error message leaving the user confused. You must provide the type key for a successful PATCH request.

Proposed resolution

Provide a more appropriate error message when keys are missing from the post/patch body.

Now that we have set PHP 5.5.9 as a minimum it looks like this can (and needs to) be done.

@todo Use RecursiveCallbackFilterIterator instead of the $acceptTests parameter forwarding once PHP 5.4 is available.

http://cgit.drupalcode.org/drupal/tree/core/lib/Drupal/Core/Extension/Di...

Problem/Motivation

After working on #2281429: [js] D8 Port for lengthy amount of time today, I finally got to a good enough stopping point where I felt it was safe to finally "enable" the module. Much to my surprise: the module couldn't be "found".

I spent a ton of time trying to figure out if it was a file permission issue, symlink issue, parse issue... only to finally remember that there was a "blacklist" somewhere that may be causing me grief.

Sure enough, this valid D7 module cannot be ported using the same name because the entire directory is skipped. This is a major problem considering the namespace (on d.o) is already being used.

Yes, I read the doc comment:

  /**
   * List of directory names to skip when recursing.
   *
   * These directories are globally ignored in the recursive filesystem scan;
   * i.e., extensions (of all types) are not able to use any of these names,
   * because their directory names will be skipped.
   *
   * @var array
   */

However, that is a really... really stupid "reason".

Especially considering the "fix" is really simple: just check if there's an immediate .info.yml file directly inside it.

Before anyone tells me to "just rename the module", that isn't an option. I don't want to have to try and come up with a new "name" when all the code (in 7.x) and the stuff I just did in 8.x centers around "js". It'll make backporting a PITA.

Proposed resolution

Loosen blacklist to allow modules that have an .info.yml directly inside the folder that's blacklisted.

Remaining tasks

• Create a patch
• Create tests

User interface changes

None

API changes

None

Data model changes

None

Problem/Motivation

We added migration for Drupal 6 node translation to Drupal 8 content translation in #2225775: Migrate Drupal 6 core node translation to Drupal 8. The situation with Drupal 7 is very similar in a way because Drupal 7 core also uses node copies for translations, but it is different because Drupal 7 also has configurable fields in core and some fields that were built-in in Drupal 6 are configurable in Drupal 8.

Also, Drupal 7 has per field translation support which facilitates the Entity Translation contributed module but not used in core for node translation, so that should be dealt with carefully when doing the migration.

Proposed resolution

• Migrate field storage config to default to translatable as is with Drupal 8 default fields.
• Migrate field instance config to set translatable based on whether the parent content type was translatable (based on the language_content_type_{bundle} variable from D7.
• Make the node migration sources include only the default translation (same as with the D6 migration).
• Add auxiliary migrations to bring in the translations (same as with the D6 migration).
• Add new nodes for testing both in the migrate dump and in the kernel tests.

Remaining tasks

Commit :)

User interface changes

None.

API changes

The Drupal\node\Plugin\migrate\D7NodeDeriver plugin gets a new boolean $translations argument for its constructor to derive translation sources as well (same change as with D6NodeDeriver earlier).

The Drupal\node\Plugin\migrate\source\d7\D7Node migrate source plugin also takes a module handler in its constructor, so it can migrate source language information on translations when content translation module is enabled on Drupal 8 (same as with the D6 node source plugin earlier)

MigrateFieldInstanceTest::assertEntity() gets a new required argument at the end to assert for translatability.

Data model changes

None.

Problem/Motivation

Currently we set $entity->original during the saving process however the entity object does not have such a property and therefor on content entities the magic methods __isset, __get and __set will be involved. In order to make the original property official and do not involve the magic methods it makes sense to create a property on the entity object for it.

Proposed resolution

Create a property $original on \Drupal\Core\Entity\Entity.

Remaining tasks

Review & Commit.

User interface changes

None.

API changes

None.

Data model changes

None.

The menu_links macro in menu.html.twig wraps its {% for item in items %} in a {% if items %} to prevent the opening and closing ul from outputing. That's a standard PHP pattern. But it is NOT a standard Twig pattern. Twig has a special loop variable that is built specifically for cases like this, the loop variable. http://twig.sensiolabs.org/doc/tags/for.html#the-loop-variable

Currently we do this:

  {% if items %}
    {% if menu_level == 0 %}<ul{{ attributes.addClass('menu') }}>
    {% else %}<ul class="menu">
    {% endif %}
    {% for item in items %}<li>…
    {% endfor %}
    </ul>
  {% endif %}

But we should use Twig's loop variable like this instead:

  {% for item in items %}
    {% if loop.first %}
      {% if menu_level == 0 %}<ul{{ attributes.addClass('menu') }}>
      {% else %}<ul class="menu">
      {% endif %}
    {% endif %}<li>…
    {% if loop.last %}
      </ul>
    {% endif %}
  {% endfor %}

Additionally, our if-ul-else-ul-endif construct means we have 2 opening ul tags and 1 closing ul tags. This causes a Twig analysis "error" in IDEs like PhpStorm:

Element ul is not closed

So this is even better:

  {% for item in items %}
    {% if loop.first %}<ul
        {% if menu_level == 0 %}
          {{ attributes.addClass('menu') }}
        {% else %}
          class="menu"
        {% endif %}>
    {% endif %}<li>…
    {% if loop.last %}
      </ul>
    {% endif %}
  {% endfor %}

Problem/Motivation

Menu links in Drupal 6 are translated using i18n_menu submodule of the suite i18n, we need to migrate those respecting the language settings.

Proposed resolution

There's an element called langcode in the options array of the menu items: $item['options']['langcode'] and it's saved using i18nstrings in a key-value-language table.
Only title and description are stored with the i18nstrings module by using this tokens:

'menu:item:'. $mlid .':title''menu:item:'. $mlid .':description'

We probably need to have a plugin source that gets all this information from the {i18n_strings} table.

Original report by Ryan Weal

i18n menu (D6/D7 i18n contrib -> D8 menu config). This contrib module provided a setting where a site could have separate menus for each language and display only the desired one in a section. In cases where separate menus are used the menu links often do not have a language setting.

Postponed on #2178703: Migrate D6 menu links

Problem/Motivation

When you create a file field, you can enable the description field for each file. This field description is supposed to override the file name on display.
It is working properly with the "Generic file" formatter but not with the "Table of files" formatter.

More than just fixing this bug (it was working in 7.x) we decided to add a setting on the concerned formatters to let the site builder choose if she wants the file name to be overriden by the description.

Proposed resolution

- pass the file description to the theme so it can be used instead of the file name
- add a setting to the "Generic file" formatter to use the description when available
- add a setting to the "Table of files" formatter to use the description when available
- add an upgrade path to disable the new settings for existing "Table of files" formatters (Backward Compatibility)
- increase test coverage to ensure these new settings are working

Remaining tasks

User interface changes

A new setting allows the site builder to define if she want the file name to be overriden by the description when it's available.
The file description is shown, when available and when the formatter allows it, instead of the file name when using the "Table of files" or "Generic files" formatter.

API changes

None.

Data model changes

A new setting on the file_table and file_default formatters.

Problem/Motivation

JSON produced by the HAL and JSON normalizers provides all data values as strings. This makes it difficult for strongly typed uses of the REST interface to interact with the JSON payload. Examples include: client libraries, auto-generated documentation, and schemas. By providing BooleanItems as booleans, IntegerItems as integers, and so on, the values output in JSON will have the correct type without client-side casting. This has the nice side effect of better lining up output with expectations of the Typed Data API.

Proposed resolution

Add additional field item normalizers casting values to explicitly match the type implied by the field item class.

Remaining tasks

None.

User interface changes

None.

API changes

None: this is an opt-in change. Existing sites continue to get the exact same responses, with booleans and integers as strings.

Only new sites will get the "correct" output by default.

See the change record: https://www.drupal.org/node/2837696.

Data model changes

None.

Hi there, I have my new brand d8 up and running, there is an issue though that I could not solve....
In my d7 installation I had:
drupal_d7/directory/some_file.php
but if I reproduce the same on d8:
drupal_d8/directory/some_file.php
when trying to access the `some_file.php` I get a:
Forbidden You don't have permission to access /directory/some_file.php
while at old d7 there is not such a problem, I've been trying with htaccess file but no success, any clue on how to solve this.

Thanks

Problem/Motivation

We have a really flexible exception system which was a bit designed around the usecase of HTML, which requires you to have a different behaviour for every XYZ HTTP status code.
For the case of JSON/XML etc. this is though not the common case so its really cumbersome to create for example a 40X method for every possible one.

Proposed resolution

Introduce onX** methods, which catches all respecting cases.

Remaining tasks

User interface changes

API changes

Data model changes

See Drupal\basic_auth\Authentication\Provider

  public function applies(Request $request) {
    $username = $request->headers->get('PHP_AUTH_USER');
    $password = $request->headers->get('PHP_AUTH_PW');
    return isset($username) && isset($password);
  }

This means that basic auth applies whenever the user submits a username and password. However my route has _access = TRUE and I've spent a long time wondering why that was overridden and I was still getting a 403.
Sure basic auth should apply according to some route parameter, not according to what the user does?

Please add the field name (field_my_custom_field) to the Add field selection window. It shows the field "label" and the table(s) in which it is used, but that's not always enough. Because there is no way to override the field label on the "Manage Form Display" page, the field label that we wish the user to see when adding/editing a content type has to be the one assigned to the field on the "Manage Fields" page.

Example use case... We have two pairs of fields: month and year for Expected Departure and Expected Arrival. Instead of showing it like this on the form:

Expected Departure Month: [ field input item here ]
Expected Departure Year: [ field input item here ]
Expected Arrival Month: [ field input item here ]
Expected Arrival Year: [ field input item here ]

.

We'd rather show them inside fieldsets, like this:

Expected Departure:
     Month: [ field input item here ]
     Year: [ field input item here ]
Expected Arrival:
     Month: [ field input item here ]
     Year: [ field input item here ]

.

The problem is when selecting the fields for placement in a View, it only shows (for example) "Month", and "Appears in: my_content_type". [See screenshot.] The actual field name there would be very helpful.

Sometimes it is desirable to show a different label on an add/edit form, or a node display, than what was entered when a field was created. The label we see on the Manage fields page should be descriptive, but though the use of fieldsets (on forms) and/or grouping divs on node displays, we don't always want that full field name to show in those cases. It would be nice to have a way to override the label - separately - for forms and displays.

Problem/Motivation

The "cache_form" database table (or cache bin) is well known for being a problem point for heavy-traffic sites or in situations where a form is displayed on every page of the site, such as a login or contact block. The problem is that any form that makes use of the #ajax form API property will immediately make two entries in the cache_form table just by viewing the form.

This has lead to run-away tables with millions of entries in some cases. And while more recent solutions like #2091511: Make cache_form $expiry configurable, to mitigate runaway cache_form table or key:value store growth attempt to mitigate the problem, they don't solve the underlying issue that the Drupal form system has a database write operation simply upon view of a form.

This issue has already been solved in Drupal 8 through #2263569: Bypass form caching by default for forms using #ajax..

Proposed resolution

Similar to the Drupal 8 issue, make it so that instead of posting to system/ajax, AJAX requests by default post to the current page path. This allows the normal form execution to occur in the same way as the non-Ajax approach. Then detect when the form is built (in drupal_get_form()) if it was done via an Ajax request. If so, process the form normally, but then return the set of Ajax commands directly, ending the page request early.

This eliminates the need for the system/ajax callback entirely, but it is left in place for backwards-compatibility. This suggested change only affects #ajax usages that use "callback", any usages that leverage "path" will still by default trigger the "cache_form" table to be used.

Remaining tasks

Tests are probably still failing.

User interface changes

None.

API changes

Switches the File module to use #ajax['callback'] instead of #ajax['path'], and in the process eliminates the menu callback at "file/ajax".

Data model changes

None.

When installing a fresh version of Drupal 8.2.0-beta2 (and beta3) the given site name is not showing. Instead it just says "Drupal" on the newly homepage.
MacOS Sierra, Apache 2.4.23, PHP 7.0.8. Safari 10.0 (build 12602). See attachment phpinfo. Site installation with language dutch (Nederlands).

Steps to reproduce it:

- Choose "Español" as site language.
- In the "Configure site" section, set the site name, mail, user and password as usual and in the regional options set "España" and "Europe/Madrid" and click in Save and Continue.
- When the install process finish the site name is "Drupal" and not the site name that you set during the install process.

I recorded a gif (drupal_site_name_issue.gif) with the process and the steps to reproduce it.

The system is a MacOS Sierra with php 7.0.12, sqlite, php built-in webserver and Drupal 8.2.1. I also tested with apache 2.4.18, mysql and OSX El Capitan and Ubuntu 16.04 as os with the same results.