Problem/Motivation

For Drupal 8.3, we want to ship with a library that allows displaying and selecting from a listing of previously-uploaded media.

Proposed resolution

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

Implementation happening so far at https://github.com/mortenson/media_library, will post patches later.

Remaining tasks

These are fairly high level, but in general I think we should:

1. Discuss what should be covered by the MVP (this is being done in #2796001: [prototype] Create design for a Media Library).
2. Develop a pattern for selecting entities in views (this doesn't have to be a form element/widget, just the logic that powers the MVP)
3. Develop a pattern for adding (uploading) new media, with a focus on the "image" bundle
4. Write CSS and JS required for the MVP to function
5. Ensure that the library works in a standalone page at /admin/content/media
6. Ensure that the library works in Field widgets
7. Ensure that the library works in WYSIWYG

User interface changes

This is a UI addition, so existing user interfaces should not be affected by this change.

API changes

We may be implementing new APIs for implementing Views-based entity selection, but we haven't decided how abstract we're going to get (see task #2 above).

Data model changes

None, the data model changes are being added in #2831274: Bring Media entity module to core as Media module.

Problem/Motivation

Nodes - as the canonical example of revisionable entities - store the revision author, the revision timestamp and a log message for each revision. The Node entity declares these fields in its baseFieldDefinitions().

Custom blocks only provide a log, but no revision author or timestamp.

We should make this consistent and make it easy for contrib entity types to provide the same behavior.

#2666808: Add a revisionable entity base class and log interface introduced three revision metadata fields, which are named "revision_created, revision_user, revision_log_message". However the core still assumes at some places that they are called "revision_timestamp, revision_uid, revision_log". That is the case where the node entity and the block entity use the previous nomenclature. But unfortunately this is not the only place.. There is one another really important place and it is in SqlContentEntityStorage::getTableMapping where the only the old nomenclature is used to put these revision metadata fields in the "entity_type_id_revision" table. #2666808: Add a revisionable entity base class and log interface did not extend the list with the new revision metadata fields and what now happens is that if you use the new RevisionLogEntityTrait your revision metadata fields will not be put like they should in the "entity_type_id_revision" table, but they will be put in the field table.

Proposed resolution

Provide a revision_metadata_keys key in the entity annotation which provides a mapping of common identifiers like "log", "uid", "created" to the actual field names. Because there are places where we need the list of revision metadata fields explicitly, for example in SqlContentEntityStorage::getTableMapping() or in ContentEntityBase::hasTranslationChanges() with #2615016: [PP-1] ContentEntityBase::hasTranslationChanges doesn't skip the revision metadata fields leading to wrong result, this is not part of the entity_keys key even though it is similar in nature. This also allows to ignore (at least for the scope of this issue) the fact that entity key fields get a NOT NULL constraint in the SQL schema. Note that calling EntityType::getKeys() will also not return the revision metadata keys.

In order to provide backwards-compatibility, in the case that revision_metadata_keys is not set, we will check the field definitions if fields with the appropriate names (revision_log, revision_log_message) exist and use those as as values. This behavior can be disabled by a boolean parameter which is utilized in RevisionLogEntityTrait because due to the above checking of the field definitions, checking the revision metadata keys while building the field definitions would lead to infinite recursion.

Because the hardcoding of incorrect revision metadata field names in SqlContentEntityStorage::getTableMapping() entity types using RevisionLogTrait have the database columns for the revision metadata fields in the wrong table. (They are in the revision data table, but they should be in the revision table.) To correct this, an update function is provided that moves the field values to the correct table and fixed any views that reference the old table names in their views field configuration.

Remaining tasks

Follow-up issue for D9 to remove the hard coded revision metadata field list from \Drupal\Core\Entity\RevisionLogEntityTrait::getRevisionMetadataKey and RevisionLogEntityTrait should create the fields only if they are mentioned in the entity annotation.

Follow-up issue for D9 to remove the backwards compatibility parameter from \Drupal\Core\Entity\ContentEntityTypeInterface::getRevisionMetadataKeys and make the annotation for revision metadata keys obligatory for revisionable entities.

User interface changes

API changes

New functions :
-EntityTypeInterface::getRevisionMetadataKeys
-EntityTypeInterface::getRevisionMetadataKey
-EntityTypeInterface::hasRevisionMetadataKey

Change record

https://www.drupal.org/node/2831499

Problem/Motivation

In #2836224: Missing schema exception on latest 8.3.x when adding view via the UI, I tracked the issue down to this code in DisplayPluginBase::getPlugin():

    // Query plugins allow specifying a specific query class per base table.
    if ($type == 'query') {
      $views_data = Views::viewsData()->get($this->view->storage->get('base_table'));
      $name = isset($views_data['table']['base']['query_id']) ? $views_data['table']['base']['query_id'] : 'views_query';
    }
    else {
      $name = $options['type'];
    }

The problem here is that the query plugin is updated (in the linked issue, to search_api_query), but the actual view definition still contains the default query plugin ID of views_query.

Proposed resolution

Update the $options['type'] value to have the correct plugin ID.

Remaining tasks

User interface changes

API changes

Data model changes

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

Is there any reason why development.services.yml does not disable TWIG cache by default? Every core update overrides this file with the default one. Themers routinely set those 3 lines, but this is a repetitive task. And the file loads only when settings.local.php is included, so it will not cause any problems on production sites.

Proposed resolution

Add the twig.config related lines to development.services.yml, under parameters: key:

  twig.config:
    debug: true
    auto_reload: true
    cache: false

So the whole file will look like this:

# Local development services.
#
# To activate this feature, follow the instructions at the top of the
# 'example.settings.local.php' file, which sits next to this file.
parameters:
  http.response.debug_cacheability_headers: true
  twig.config:
    debug: true
    auto_reload: true
    cache: false
services:
  cache.backend.null:
    class: Drupal\Core\Cache\NullBackendFactory

Problem/Motivation

We add fields that handle alt and title attributes on the image. Core, on the other hand, stores values for those attributes on an image field. This causes some inconsistencies. If an image is rendered through entity view display we use alt/title from the fields and ignore any values that might be available on the field. When using core's image formatter the problem is reversed; fields on the entity are ignored and values from the field are used.

It would be great to figure out how to make this consistent. How do we sync alt/title between image field and file entity? What happens if data was changed on both sides after sync? Should we override core's image field formatter and widget to pass responsibility for alt/title to the file entity? This is certainly possible, but becomes problematic if another module overrides the same plugin.

Before patching:

After patching

french

english

Steps to reproduce

IF we change the format of the image field to 'rendered file' on the content display settings page everything works, alt tags and titles show up properly. However most sites use image styles, other formatters like flex slider, colorbox etc, therefore it is an important functionality.

This can be reproduced on sympletest.me and on our test environments as well.

We use the latest media module, file entity and entity translation modules.

1. Core and Basic module installation on one language
2. Enabled 1 more language
3. File Entity configuration -> in TRANSLATABLE ENTITY TYPES image is configured with the following options:
   • Hide language selector
   • Exclude Language neutral from the available languages
   • Prevent language from being changed once the entity has been created
4. Created custom content type for testing
   • Content type is translatable with entity translation
   • Added image field with media file selector widget not translatable (unlimited values)
   • Configured display settings of the image field format to 'image'.
5. Uploaded single or multiple image files through content/files/add files or via media widget, does not make a difference
6. After upload we translated Alt and title fields on multiple images through content/files/edit/translate
7. Added images to the content's image field through media browser
8. After saving and/or cache flushing, our alt and title tags stays on the language (regardless of the chosen language) that is active.

Proposed resolution

See patch for D7 , Needs port to D8.

Note: further testing showed that while this patch ALWAYS works, without this patch you might occationally notice the alt and title working correctly on some records but not others. Sorry I don't have more details

My site was using traditional Chinese as the default language. Simplified Chinese was the second and English the third languages. Due to some language translation errors logged by the Commerce module, I uninstalled the Language and Translation modules. After some tests, I reinstalled the Language module again. When I tried to add back the traditional Chinese language, it was not on the selection list. Simplified Chinese was there. I cleared cache, logged out and then logged in again. Still, traditional Chinese was not on the language selection list.

We're going to use the newer version of JS (ES6) in core #2809281: Use ES6 for core JavaScript development, that comes with some pretty significant language improvements that we need to have standards for. Instead of making up our own we should make use of an existing established standard close to ours.

One of the most well known and used standard similar to ours is airbnb JavaScript Style Guide. They have rules for new ES6 features, they also use react hence have react rules ready. Won't help core but might be helpful to contrib and projects. Their rules are more strict than ours, it's a good move for our codebase.

The only significant whitespace change that will impact us are the config for brace-style and object-curly-spacing.

Current drupal style

if (this.model.get('isActive')) {
  // …
  this.model.set({isActive: true, activeTour: $tour});
  // …
}
else {
  // …
}

Airbnb style

if (this.model.get('isActive')) {
  // …
  this.model.set({ isActive: true, activeTour: $tour });
  // …
} else {
  // …
}

People might complain but it's a really minor thing in the grand scheme of things. And if we really have to, we can override those 2 rules. The rest of the rules enforce good practices.

Right now running coding standard on our codebase, after eslint auto-fix of some rules (and without the whitepace rules discussed above) there are 2061 problems, 95% of which come from the following rules:

"camelcase""no-param-reassign""func-names""comma-dangle""max-len""no-underscore-dangle""no-unused-vars""no-plusplus""newline-per-chained-call""no-restricted-syntax""new-cap""no-new""padded-blocks""prefer-const""no-use-before-define""consistent-return""no-prototype-builtins""no-else-return""default-case""no-shadow"

Attaching a patch since adopting this means changing some eslint files.

Some projects using this standard:

• React
• reddit
• Evernote

And it seems ember.js coding standards are extremely similar.

Previous discussions

#1778828-51: [policy, no patch] Update JS coding standards
#1778828-59: [policy, no patch] Update JS coding standards
#2746807-2: Consider standard js coding standard

Problem/Motivation

Settings Tray "Edit Mode" and QuickEdit module editing don't work well together as far as UX and it is not clear which links or form elements will function as regular links(leave the page) and which are disabled in edit mode.

Problems

1. If you open QuickEdit toolbar and then open a form in the Tray then both will be open confusing the focus of the user.
2. If you do the reverse open a form in the tray and then open QuickEdit toolbar they still will remain open confusing the focus of the user.
3. Click anywhere on a block that works with Settings Tray will open the try to edit the block. On the other hand sections of the page that are controlled by QuickEdit you have open the contextual like and click "Quick Edit"
4. Form elements and links on the page can still have link pointers(the little hand) suggesting they maybe should work
5. Forms elements such as textfield on the page can gain focus if you click and quickly type.

Proposed resolution

Make a more unified experience between QuickEdit and Settings Tray edit modes.

1. If QuickEdit form is open then the user triggers a block form to open in the Tray automatically close the QuickEdit form.
2. If the tray is open with a block form and user triggers the quick edit form automatically close the tray.
3. Disable the pointer for links and form element forms that are disabled by Settings Tray edit mode. This includes forms in the blocks and main content area(i.e. search block and search page)
4. Don't allow form elements that are disabled by Settings Tray edit mode to gain focus

Remaining tasks

None

User interface changes

All described in "Proposed resolution" section above

API changes

None

Data model changes

None

Original summary

Follow-up to #2753941: [Experimental] Create Outside In module MVP to provide block configuration in Off-Canvas tray and expand site edit mode.

Links, buttons, etc, on the page behave inconsistently with Outside In. Some are overridden by the Edit toggle, and clicking on them opens the configuration sidebar for that element. Others submit forms or navigate away, taking you to other pages such that it is unclear whether you are still in Edit mode or not.

According to #2732443-35: Finalize the behavior for triggering view/edit/build modes from the toolbar (and fix the "disappearing toolbar") the toolbar is taken away to keep the user from accidentally navigating away from the page, but it seems much worse to me for some links to open the editing mode and others to take you away from the page. At least the Toolbar is clearly not part of the canvas you are editing.

Proposed resolution

Make links, buttons, etc. on the page being edited behave in a consistent fashion.

Problem/Motivation

Currently, outside_in_contextual_links_view_alter() hardcodes a single contextual link as using offcanvas.
Any other links to be added will need the same logic.

Proposed resolution

Make it easier for contextual links to opt-in to being displayed in a dialog.
In #2784443: Move off-canvas functionality from Settings tray module into drupal.dialog.ajax library so that other modules can use it, make this available for all contextual links and all dialog/modal options.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Now that we have a generic interface for publishable entities, a lot of queries will need to take the entity status into account.

Proposed resolution

Add a SQL index for <status_key>_<bundle_key>_<id_key> just like we have for nodes.

Remaining tasks

Review, agree, etc.

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope.

I was having fatal error when I installed Drupal on my laptop. It asked me to increase time execution more than 30seconds, I changed in settings with 1200, than I I tried to instal Drupal second time but before that I restarted apache server on xampp, after I requested to Instal Drupal8
In Mozilla with localhost, it came with an msg to try later some other time. Please sir help me fix this issue.

API page: https://api.drupal.org/api/drupal/core!modules!node!templates!node.html....

Enter a descriptive title (above) relating to node.html.twig, then describe the problem you have found:

Node Template: node--type-[type] is not working
ex: node--type-article.html.twig

Template naming: node--article.html.twig is working fine.
ex: node--article.html.twig

Please make the changes on the node.html.twig page.

Problem/Motivation

Found while manually testing #2161801: Update hook_help for Config translation module

When there is only one language, translate pages exist, but do not give a hint that translation cannot happen until another language is added.

Proposed resolution

Add a message, and link to the language admin, when there is only one language to add enable

Remaining tasks

• discuss if this is really needed, or is wont fix.

User interface changes

Yes.

Content translation, before

Configuration translation, before (for comparison)

Note that configuration translation is different, because even with only the site default language, config text can be edited on the translate page. (For example, english can be translated.)

API changes

No.

Problem/Motivation

Follow up to #576296: Remove redundant description for some permissions

Yoroy noted in comment #33 there that the descriptions on the "Revert all revisions", "Delete all revisions", and "Revert/delete TYPE revisions" permissions were confusing. These are in node.permissions.yml and the NodePermissions class, and they look something like this:
Role requires permission to <em>view revisions</em> and <em>edit rights</em> for nodes in question or <em>administer nodes</em>.

So I looked at the logic in the NodeRevisionAccessCheck class, which is the only place (outside of tests) in Core that these permission strings appear.... and I think that those descriptions are actually wrong.

What they should say is that in order to revert or delete revisions, you also need to either have 'administer nodes' permission, or permission to edit the given node. Actually the 'view revisions' permission is not needed, as far as I can tell.

Proposed resolution

All of these strings should be modified to say something like:

Reverting a revision also requires permission to edit the content.
Deleting a revision also requires permission to edit the content.

[Note: We should never use the word "node" in the UI! This wording would be consistent with the names/descriptions of other Node module permissions.]

Remaining tasks

Make a patch.

User interface changes

Correct descriptions for the node revision revert/delete permissions.

API changes

None.

Data model changes

None.

I have discovered problem with mixed mode session. When mixed mode enabled:
$conf['https'] = TRUE;
we should have same session for secure and insecure pages (https and http) but it does not works and starts new anonymous session instead.
Test environment:
clean Drupal 7.28 (no contrib installed), PHP 5.3.10, Ubuntu 12.04 (server and client), any browser
Ways to reproduce:
1. Add next lines to your settings.php:
$conf['https'] = TRUE;
2. open incesure user login page (http:///user)
3. Login
4. Open any site page under SSL (https://)
5. Open any insecure page again

Expecting to be logged in with same session for secure and insecure pages.
Happend instead - new anonymous session started for secure and insecure pages.

Problem/Motivation

In user_user_role_insert we create actions per user role being created. We do this like this:

    $action = entity_create('action', array('id' => $add_id,'type' => 'user','label' => t('Add the @label role to the selected users', array('@label' => $role->label())),'configuration' => array('rid' => $role->id(),
      ),'plugin' => 'user_add_role_action',
    ));
    $action->trustData()->save();

At first sight the t() looks wrong because it means config will be saved with the translated text - but actually I think this is fine since the configuration entity will have the language that the user has when they create the role. But what is more problematic is saving the escaped role label. This causes two problems - double escaping on admin/people if the role label contains an & and also potentially getting out of sync with the role label if that changes.

Proposed resolution

no idea yet

Remaining tasks

Find a solution.

User interface changes

None

API changes

?

Data model changes

?

Why is this an RC target?

• Escaping the role label during the creation of the action label leads to double escaping. This patch fixes 27 out of the 32 fails found by #2571065-14: Find escaping due to Twig autoescape. Without this patch going in we can't implement some sort of generic double escaping test for all of our WebTestBase tests.
• Not keeping the action label in sync with the action label could result in a very confusing UI experience (image if role labels are swapped - yes that would be dumb but we all do dumb things sometimes)
• The fix creates a generic solution for actions to add arguments for it's labels. Given how actions are created based on other config entities this is likely to be needed again

Notice: Undefined index: package in system_requirements() (line 60 of core\modules\system\system.install).

system_requirements('runtime')
call_user_func_array('system_requirements', Array) (Line: 402)
Drupal\Core\Extension\ModuleHandler->invokeAll('requirements', Array) (Line: 112)
Drupal\system\SystemManager->listRequirements() (Line: 49)
Drupal\system\Controller\SystemInfoController->status()

On fresh installation of Drupal after enabling twig debugging.

From #2547833: Pager.inc -- add tests, clean it up, convert to a service, use it!:

Problem/Motivation

pager.inc uses global variables, which we are trying to get rid of, as they make it impossible to manage pagers in a OO manner. All the pager related API are procedural functions.

Proposed resolution

Make Drupal's default pager an OO service, using the capabilities introduced in Drupal 8. This will make it OO and will open it up to the possibility to replace it by alternative implementations.

Unfortunately proper cleanup would include removing the four globals in pager.inc. Since that's an API change, the best we can do in 8.x is deprecate them and include (deprecated) wrappers for the new service to maintain backwards comparability until 9.x.

In detail:

1) A 'pager' is a classed object that contains data and methods relative to a pager element. A 'pager factory' creates 'pager' objects and keeps track of the objects created so that they can be traversed to produce the 'page' URL querystring for the pager links.

2) The global variables are retained at this stage, wrapped into the PagerInterface methods so that methods can alter them, but also, for BC, other code can alter them independently, and in this case the values stored in the global override any value stored in the PagerInterface object.

3) pager.inc procedural functions remain for BC as wrappers to PagerFactoryInterface service or PagerInterface methods. There are no longer global variables declared in this file!

4) template_preprocess_pager() use the new service methods instead of directly accessing the globals.

Remaining tasks

• review

User interface changes

None.

API changes

All pager_* global variables and procedural function will be deprecated. New Drupal\Core\Pager\PagerInterface and Drupal\Core\Pager\PagerFactoryInterface and their default implementations will be added. BC layer introduced to allow deprecated global variables and functions to stay with same functionality until Drupal 9.

Data model changes

None.

Original report:

I do not know how this would fit in the timeline :( but looking at pager.inc overall I thought it may be worth to build a component for the helper functions and to move the pager theme preprocessing to theme.inc.

I will post a first stab - a patch that eventually removes pager.inc and 4 global variables; also, makes a bit more readable the routine that prepares the 'page' querystring fragment.

I have incorporated parts of #1588138: pager_query_add_page() [in D7, theme_pager_link()] overrides parameters passed programmatically in this patch.

Of course more polishing would be needed, but before all I'd like to get feedback: is this a path that make sense to follow?

Problem/Motivation

The Drupal\Core\KeyValueStore\DatabaseStorage uses a configurable serializer to store PHP objects. This serializer is injected as a service in core. The pre-configured serializer used there Drupal\Component\Serialization\PhpSerialize. But this serializer could be swapped to any serializer that implements Drupal\Component\Serialization\SerializationInterface, for example:

• Drupal\Component\Serialization\Yaml
• Drupal\Component\Serialization\Json

These serializers will break PHP objects like in the form_state that gets saved in the key value store.

Proposed resolution

#839444: Make serializer customizable in Cache\MemoryBackend and Cache\DatabaseBackend will introduce a new interface Drupal\Component\Serialization\ObjectAwareSerializationInterface that just extends Drupal\Component\Serialization\SerializationInterface to clearly indicate that implementing Serializers are suitable for PHP Object serialization.

The Drupal\Core\KeyValueStore\DatabaseStorage and Drupal\Core\KeyValueStore\DatabaseStorageExpirable and their factories need to adjusted to expect a serializer that implements that new interface.

Remaining tasks

Write a patch.

User interface changes

None.

API changes

The Drupal\Core\KeyValueStore\DatabaseStorage and Drupal\Core\KeyValueStore\DatabaseStorageExpirable and their factories need to adjusted to expect a serializer that implements that new interface.

Data model changes

None.