Report based on #2930599: Unable to save a translation if the path alias changes (which is 'works as designed' imho).

Problem/Motivation

User can't add new draft for a content translation of a node if the path alias of the latest published entity (original language) is different from the path alias of the new translation draft's form.

Steps to reproduce

Setup

1. (as an administrator user, suggested install profile: standard)
2. Enable node, content_moderation, content_translation and path modules.
3. Add an another language.
4. Create a node type, add a workflow to it and make it translatable. Use the defaults settings of the content translation form.
5. Create a node with in the default language with path alias. Publish it.
6. Create a translation for the node with a translated path alias which is different from the one the default node has. Publish this translation as well.

Scenario 1

1. Try to add a new draft for the translation while not changing the path alias.
2. Expected: new draft is successfully saved while alias of the published translations remain the same.
3. What happens: PathAliasConstraintValidator returns a validation error You can only change the URL alias for the published version of this content.

Scenario 2

1. Now try to add a new draft for the translation while changing the path alias to the one what the original published entity revision has (original means the original language).
2. Expected: Validation error.
3. What happens: New translation draft successfully saved, and the alias of the published (default) translation revision changes to the one we just filled in.

Proposed resolution

Extend logic of PathAliasConstraintValidator to check for the default revision of the current entity language, and not the original entity.

Remaining tasks

Copy my patch from #2930599: Unable to save a translation if the path alias changes here.
Extend it with a test for Scenario 2
Get a review.

User interface changes

Nothing.

API changes

Nothing.

Data model changes

Nothing.

Problem/Motivation

After path aliases are converted to entities, we should also convert their forms to extend content entity form base classes.

Proposed resolution

Convert custom path alias forms to entity forms.

Remaining tasks

Do it :)

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope.

Problem/Motivation

Modules need a way to declare their migration status and give a short description on the Migrate Upgrade review page, /upgrade. The short description can have a link to a documentation page for example for known issues.

The form lists all modules on the source site in either a 'will be upgraded' or 'will not be upgraded' list. If the module has migrations, it will be displayed in the 'will be upgraded' list, even if it only has one migration and needs more than one to be complete. We need a mechanism that can explain this situation in the UI.

Note: in #2914974: Migrate UI - handle sources that do not need an upgrade we defined a list of modules that do not need any migrations (e.g. Overlay, Help) or the contrib functionality has moved into core and there is not a D8 core module with the same name. These modules are listed in ReviewForm::$noUpgradePaths

In a migrate meeting, using a hook or an event was discussed. A possible solution, using hook_form_alter, was implemented in #2914974: Migrate UI - handle sources that do not need an upgrade and removed after a review #176. That review asked some questions, listed below, which should be resolved here.

1. The CR is titled Provide a Method to Intentionally Mark Modules, Themes and Profiles as not Upgradable but we're not really providing a method.
2. Did we give consideration to a dedicated API? E.g. we could put entries in .info.yml or we could put .migrate.info.yml files in modules.
3. How likely is it that contrib modules will need to make this change?

Proposed resolution

In a migrate meeting option #2 was decided as the best option, reasons included that it is easy to add and there is no need to write code. See #7 and #8.
Add a version key to identify the source version. While working on this it became clear that the status needs to be declared by source version. See #10

Remaining tasks

• Decide on the format of the new 'migrate' key and values in .info.yml. Suggested formats are in #11 and #15.
• Decide on the allowed values for status. Suggestions are in #7, #9. Currently proposed values are 'complete', 'incomplete' and 'n/a'. The UI impact with a screenshot is in #28.
• Decide if adding a key for source version is ok. As pointed out in #10, the status needs to be declared by source version.
• Review
• Update change record
• Update handbook documentation
• Commit

About the scope of this issue

The UI impact to Migrate Drupal UI is discussed in this same issue so that we have a holistic view on the design but the actual change to Migrate Drupal UI will be handled in a separate issue, see #2928147: Migrate UI - add 'incomplete' migration status.

Problem/Motivation

Images uploaded to an image field are lost when the node language is changed (because file usage incorrectly drops down to zero, causing the permanent file to be marked temporary, and then eventually being deleted — after 6 hours by default).

Same for files uploaded to a file field.

Steps to reproduce

1. create a content type with an image field
2. enable >=2 languages in site
3. set the content translatable (tested setting the file translatable or not)
4. create a node with an image and save it
5. verify that the uploaded file has its status column in the file_managed table set to 1,
   and it has 1 usage in the file_usage table
6. edit the node and change the language
7. • expected result: the uploaded file still has its status column in the file_managed table set to 1, and it has 1 usage in the file_usage table
   • actual result: the uploaded file now has its status column in the file_managed table set to 0, and it has 0 usage in the file_usage table
8. run cron 6 hours later (this is the default value of the temporary_maximum_age setting in system.file)
9. • expected result: the uploaded file is still present (because usage > 0)
   • actual result: the uploaded file is absent (because usage = 0)

Note: see #40, where it is explained how this same problem is even reproducible on sites without content_translation are affected by this, merely having the language (Interface translation) module installed and having >1 interface language enabled is sufficient to reproduce this problem for image/file fields on User entities!

Proposed resolution

Root cause analysis:

• \Drupal\file\Plugin\Field\FieldType\FileFieldItemList::delete() removing file usages:
  

    public function delete() {
      parent::delete();
      $entity = $this->getEntity();
  
      // If a translation is deleted only decrement the file usage by one. If the
      // default translation is deleted remove all file usages within this entity.
      $count = $entity->isDefaultTranslation() ? 0 : 1;
      foreach ($this->referencedEntities() as $file) {
        \Drupal::service('file.usage')->delete($file, 'file', $entity->getEntityTypeId(), $entity->id(), $count);
      }
    }
  

• to delete file usages, it relies on $entity->isDefaultTranslation() (i.e. \Drupal\Core\TypedData\TranslatableInterface::isDefaultTranslation()) to determine whether a translation is being deleted or not
• $entity->isDefaultTranslation() behaves incorrectly when the default translation is being changed

Therefore the solution is: fix \Drupal\Core\Entity\ContentEntityBase::isDefaultTranslation().

Remaining tasks

TBD

User interface changes

None.

API changes

None.

Data model changes

None.

All Taxonomie get lost while updateing from 8.5.6 to 8.6.1
That didn't happen from 3.5.6 to 3.6.0

Sorry for type-error in previous issues version.

Problem/Motivation

ContentEntityBase::hasTranslationChanges is being called in core two times during the saving process.
1. ChangedItem::preSave
2. ContentEntityStorageBase::populateAffectedRevisionTranslations

In each of this cases the method will be called for each translation and having a lot of entity translations with complex fields one might want to somehow cache the output of the first execution of the method in order to serve the result on subsequent calls from this cache instead of having the complex logic running over and over again.

Additionally the core uses the method two times during the saving process but one might have hook_entity_update and running the method there as well in order to do stuff based on the output of the method, so caching the output of the method will be really useful and will have a real performance boost.

Proposed resolution

1. In ContentEntityBase::preSave flag the entity as being in a state of saving. - Should we set the flag at this point or it would be better to do in the storage after the field preSave method has been executed as after it the field values might have changed.. but actually the only place where the method might be correctly used is in the hook_entity_update which is running after field preSave which makes it unnecessary setting the flag from the storage.
2. In ContentEntityBase::hasTranslationChanges check if the flag from ::preSave is set and if so cache the output, otherwise if it is already cached serve it from the cache.
3. In ContentEntityBase::postSave reset the ::preSave flag and the cache of the ::hasTranslationChanges method.

With this change our system gained a real performance boost as we use the method also in hook_entity_update and during save we call it a lot of times on a lot of entities.
Numbers: 14 % less memory usage and 65 % faster saving.

Remaining tasks

Review & Commit.

User interface changes

None.

API changes

None.

Data model changes

None.

[guessing path module?]

1. If people upload files, I would like them to be private, so that those files can only be seen by other local users who log in.
2. If a picture is uploaded to a person's page, I would hope that that picture would be visible on the collected "People" page.

It seems that as both of those involve an "upload", I can't treat them differently, but hopefully I'm missing something - any hints?

In Configuration/Media/File system, I have "Default download method = Private local files served by Drupal." which I think is necessary for 1).

In Configuration/People/Account settings, I have "Picture directory: pictures""Subdirectory in the file upload directory where pictures will be stored", so there doesn't seem to be anything I can do...

(This is on Drupal 7.59)

Hello.

This morning I updated Drupal core 7.59 to 7.60 and get a 500 error.

User warning: The following module is missing from the file system: path. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (regel 1143 van /home/filmhuis/public_html/includes/bootstrap.inc).

Second website I updated from 7.59 to 7.60 the same 500 error occured.
Anyone any idea what's going on here?

Problem/Motivation

Follow-up from #2809635-178: Create experimental installation profile:

This link needs context for accessibility, 'View Recipe' or similar isn't specific enough for screen reader users.

+++ b/core/profiles/demo_umami/themes/umami/templates/content/node--highlighted-bottom.html.twig
@@ -0,0 +1,107 @@
+      <a class="read-more__link" href="{{ url }}">{{ 'View'|t }} {{ node.bundle }}</a>

To satisfy WCAG Link Purpose (In Context) at level A, we should distinguish multiple "View recipe" links from each other.

Proposed resolution

Add the recipe node title as visually-hidden text in the "view recipe" link. Either:

1. Update exiting custom template in Umami. Suggested twig code was discussed in comments #10-11:
   

   <a class="read-more__link" href="{{ url }}">{%- trans -%}
      View {{ node.bundle }} - <span class="visually-hidden">{{ label }}</span>
   {%- end trans -%}
   </a>

2. Alternatively, change the recipe card display to use the read-more links provided by node module. Can we update the phrasing in a preprocess hook? This has the advantage of respecting "manage display" settings for recipe nodes.

Either of these approaches will satisfy WCAG Link Purpose at level A. The relevant WCAG technique document is C7: Using CSS to hide a portion of the link text.

Important: whichever approach we follow, the link text must also satisfy WCAG 2.5.3 Label in Name. There must not be any visually-hidden text between the words "view" and "recipe". Explained in comment #11.

Remaining tasks

Patch!

User interface changes

No visible changes. Some visually hidden text provides extra context for accessibility, screen reader users especially.

API changes

None.

Data model changes

None.

Original report by [username]

Reported in TWO places already.

• Reported by @DuaelFr in the lauriii/umami Gitub repo: #147: [a11y][AAA] Link Purpose (Link Only)
• Also noticed during code review at : #2809635-178: Create experimental installation profile

I'm not sure i agree with this request. At the moment in Drupal core, we just have a "Read more" string. We are being more explicit here in letting readers know that it's an article or a recipe they are going to read. I'm happy to be corrected.

Problem/Motivation

A migration for custom block translated strings is needed. The translations for the title and body of custom blocks is in the i18n string module.

Use D6 custom block translation migration as example. And in D7 the i18n string table is named 'i18n_string' and not '18n_strings' as in D6.

Proposed resolution

Write a patch
review
commit

Problem/Motivation

Actions definition have a category, but it's unused now.

Proposed resolution

Show category in the action listing

Remaining tasks

Add tests

User interface changes

Action list will contain category column

API changes

None

Data model changes

None

Steps to reproduce

1. create an entity type that includes AJAX calls on the node edit form, e.g. node with a link field and a media field
2. try to create an instance of that entity
3. enter an invalid path in the link field, e.g. 'foo'
4. click on the file upload button
5. try to upload a file

Expected result

An error message should appear, but you should be able to upload the file

Actual result

It isn't possible to upload the file.
The AJAX call responds with a 500 error "The internal path component is invalid. Its path component must have a leading slash" with field widget type "Link".

↵An AJAX HTTP error occurred.↵HTTP Result Code: 500↵Debugging information follows.↵Path: /fr/node/6/edit?element_parents=field_test/widget/0&destination=/admin/content&ajax_form=1↵StatusText: 500 Service unavailable (with message)↵ResponseText: The website encountered an unexpected error. Please try again later.InvalidArgumentException: The internal path component 'test' is invalid. Its path component must have a leading slash, e.g. internal:/foo.

This error generates from \Drupal\Core\Url::fromInternalUri

It happens from \Drupal\link\Plugin\Field\FieldWidget\LinkWidget::formElement
in code
$item->getUrl()->access() (core/modules/link/src/Plugin/Field/FieldWidget/LinkWidget.php:175)

For avoidance of this error we have next element validator where check input values
\Drupal\link\Plugin\Field\FieldWidget\LinkWidget::validateUriElement

So we can't catch this error on common entity save operation.
But we can catch it with any additional ajax buttons, which skip validation with #limit_validation_errors

It appears on all browsers.

In my example "foo" value is incorrect for Link field. We can avoid this error by putting only correct values. But customer can be confused. He doesn't know what values are correct, and he doesn't know why all his AJAX buttons don't work. So we should avoid 500 error with ajax buttons.

I have investigated this issue and found, that we need to add additional check in \Drupal\link\Plugin\Field\FieldWidget\LinkWidget::formElement
I have prepared patch and I will apply it in comment.

When GET:ting data for nodes like /jsonapi/node/article the referenced images are correctly appearing in response so we get:

"field_image": {
                    "data": {
                        "type": "file--file",
                        "id": "1c563a12-6bb7-4aa0-be83-d2ba62c420cc",
                        "meta": {
                            "alt": "test",
                            "title": "",
                            "width": 320,
                            "height": 240
                        }
                    }

But if the entity type has a default image the file reference data is:

"field_image": {
                    "data": null,
...

Reproduce:
1. Create an article with an image. => Request works.
2. Set a default image to article image field.
3. Create a new article using the default image. => Request gives null value to field_image.

Link to Taxonomy term get invalid language path if my language is not origin. Same bug if get Image (Link to content) get same error

How to reproduce

1. enabled language and content translation
2. add another language (ex: RO)
3. create translatable taxonomy vocabulary
4. enable content translation for taxonomies, and for the fields of the new vocabulary terms
5. add to this vocabulary a term (ex: Test) and translate it (Test(Ro))
6. create a taxonomy term view that displays fields, add "Name" and "Link to taxonomy term"

Notice how the two different fields have different links for the term. The term "Name" field ads correct link for both languages (en: "/taxonomy/term/1", ro: "/ro/taxonomy/term/1"), but the "Link to taxonomy term" adds for both the default language link (en: "/taxonomy/term/1", ro: "/taxonomy/term/1"

This bug for all my project. That i made start at 8.2.2

Problem/Motivation

AlreadyInstalledException is thrown from four different places and produces the same output on each, so you can't know precisely why the installation process (perhaps mistakenly) believes Drupal is already installed. See https://github.com/drush-ops/drush/issues/511 for one false positive scenario.

Proposed resolution

Add a $detail string argument to AlreadyInstalledException::__construct() and incorporate it into the output. Provide useful info when throwing the exception.

Remaining tasks

Bikeshed the info to provide.

User interface changes

None.

API changes

Additional argument to AlreadyInstalledException.

Update from 8.6.1 to 8.6.2 gives a "unexpected error..."
There was one update in update.php: contextual module.

Disable contextuale module en quick edit module don't solve the problem.

Problem/Motivation

Working on #2626298: REST module must cache only responses to GET requests we detected that EarlyRenderingControllerWrapperSubscriber is not executed only for GET requests.

Only GET requests are cached so we don't need to verify render contexts for other methods(i.e. POST).

Proposed resolution

Avoid to check the render context to detect early rendering for Non-GET requests.

Problem/Motivation

Moving a large block on a smaller screen (13') is very hard to do. (I succeeded once)
See: https://www.youtube.com/watch?v=GQ_D6A3j3As

Using latest Chrome, Standard profile, 8.6.x, 13-inch screen. (Default Layout Builder configuration, I did not change the field block for the Basic page content type)

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Fairly often there is a need for some sort of contextual data when theming. It's possible in preprocess functions to add any variable you want, but when building render arrays you're limited to what's defined in hook_theme() and _template_preprocess_default_variables().

Example from the search module in core, where a 'context' variable was manually added to allow for this flexibility (#2495419: Move the 'search-results' class from the render array and into a Classy template):

    $build['search_results'] = array(
      '#theme' => array('item_list__search_results__' . $plugin->getPluginId(), 'item_list__search_results'),
      '#items' => $results,
      '#empty' => array(
        '#markup' => '<h3>' . $this->t('Your search yielded no results.') . '</h3>',
      ),
      '#list_type' => 'ol',
      '#cache' => array(
        'tags' => $entity->getCacheTags(),
      ),
      '#context' => array(
        'plugin' => $plugin->getPluginId(),
      ),
    );

Proposed resolution

In the theme registry add a context variable as an empty array to all theme hooks if it doesn't already exist.

In elements, add a #context property as an empty array if it doesn't already exist.

Remaining tasks

All of them

User interface changes

None

API changes

Small API addition.

Data model changes

None

WSOD after upgrading from 8.5.7 to 8.6.0.

Here's php and nginx log:

php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: "NOTICE: PHP message: Uncaught PHP Exception Drupal\Core\Database\DatabaseExceptionWrapper: "SQLSTATE[42S22]: Column not found: 1054 Unknown column 'block_content_field_data.reusable' in 'where clause': SELECT base_table.revision_id AS revision_id, base_table.id AS id"
php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: "FROM"
php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: "{block_content} base_table"
nginx | 2018/09/07 12:08:59 [error] 24#24: *507 FastCGI sent in stderr: "PHP message: Uncaught PHP Exception Drupal\Core\Database\DatabaseExceptionWrapper: "SQLSTATE[42S22]: Column not found: 1054 Unknown column 'block_content_field_data.reusable' in 'where clause': SELECT base_table.revision_id AS revision_id, base_table.id AS id
nginx | FROM
nginx | {block_content} base_table
nginx | INNER JOIN {block_content_field_data} block_content_field_data ON block_content_field_data.id = base_table.id
nginx | WHERE (block_content_field_data.reusable IN (:db_condition_placeholder_0)) AND (block_content_field_data.default_langcode IN (:db_condition_placeholder_1)); Array
nginx | (
nginx |     [:db_condition_placeholder_0] => 1
nginx |     [:db_condition_placeholder_1] => 1
nginx | )
nginx | " at /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php line 686" while reading response header from upstream, client: 172.18.0.6, server: drupal, request: "GET / HTTP/1.1", upstream: "fastcgi://172.18.0.4:9000", host: "EXAMPLE.COM"
nginx | 172.18.0.6 - - [07/Sep/2018:12:08:59 +0000] "GET / HTTP/1.1" 500 79 "-""Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36"
php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: "INNER JOIN {block_content_field_data} block_content_field_data ON block_content_field_data.id = base_table.id"
php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: "WHERE (block_content_field_data.reusable IN (:db_condition_placeholder_0)) AND (block_content_field_data.default_langcode IN (:db_condition_placeholder_1)); Array"
php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: "("
php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: "    [:db_condition_placeholder_0] => 1"
php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: "    [:db_condition_placeholder_1] => 1"
php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: ")"
php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: "" at /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php line 686"
php | 172.18.0.7 -  07/Sep/2018:12:08:59 +0000 "GET /index.php" 500