Problem/Motivation

#attributes gets converted into a \Drupal\Core\Template\Attribute object, with each attribute either needing to extend AttributeValueBase or being converted to one of Attribute[Array|Boolean|String]. These all call Html::escape on their values when converting to a string.

It is common to use data attributes (e.g. data-icon) to store icon characters coupled with CSS (e.g. content: attr(data-icon);) to output icons. It's common practice to use unicode html entities for this (e.g. ✔ for a tick). These then get escaped and render garbage.

Proposed resolution

Add a AttributeEscaped that you can use to indicate that you have already appropriately filtered and escaped the attribute value, who's __toString simply returns the value.

API changes

Addition of a new attribute for use in contrib.

When a menu item has a dynamic title generated by a title callback, and a shortcut is added to that menu item, the shortcut link title will be the title when the shortcut was added. If the dynamic title changes, the static shortcut link will still have the same title.

The key scenario I have in mind is the menu item "Unapproved Comments (#)", located at admin/content/comment/approval. Even after #658702: Automatic title for MENU_LOCAL_TASK page shortcuts is not useful is fixed, the shortcut to this tab will be a very popular one, as it allow users to easily track unapproved comments. The shortcut will display the number of unapproved comments that existed when the shortcut was created, even as new comments are added or deleted. That would obviously be a bit of a WTF.

Even if we can't "properly" fix this bug, adding a shortcut to the comment approval queue should pull the automatic title using the static 'title' attribute in hook_menu(), not the the result returned by the title callback when the shortcut was added.

I'm painfully try to install DKAN distrib with wamp, but i'm facing anytime and anyway to 2 error messages :
(images)

"An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: http://azot/install.php?profile=dkan&locale=en&id=2&op=do StatusText: Service unavailable (with message) ResponseText: Error: Call to undefined function features_get_default() in dkan_build_menu_links() (line 247 of D:\wamp64\www\azot\profiles\dkan\dkan.profile). "

I'm new to Drupal (and DKAN) world, and i need help.

Problem/Motivation

#2403307: RPC endpoints for user authentication: log in, check login status, log out added this service. This service only needs the serializer formats container parameter. It doesn't need the serializer service.

Not only is it unused, it also makes route rebuilds much more expensive, because to use the serializer service, all normalizer services must also be instantiated!

Proposed resolution

Stop injecting the serializer service.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

I'm not 100% sure this is a cache issue, or a views issue, feel free to move it if needed :) I suspect it's views that does the building and gathering of cached content.

Running Drupal 8.2.4 with the theme hook suggestions patch from issue 2118743, Internal Dynamic Page Cache and Internal Page Cache are both enabled. If I disable both, the bug does not occur.

The case :

I have two views, who both render the same entity in the same display mode BUT since it's two different views we wanted to use two different templates, hence the extended template suggestions.

One view creates a block with two news items to be used on the frontpage, A node set a in the settings, and the news is rendered as entity in teaser mode, using a template called node--view--frontpage--news.html.twig

One view created a page with news items, also in entity render, with the teaser display of the news node, but uses a template called node--news--teaser.html.twig

If I clear all caches, and open the front page, both news both blocks show op perfectly, however when you go to the news overview page, both news items are rendered in the output style of the frontpage block. Same works vice versa, clear cache visit overview, the frontpage shows the two items in overview style.

Did some digging in the cache_render table, and noticed that the rendered entity is stored twice. Once with a #markup key, and once with the #cache_redirect and a #cache context. I unserialized the keys of the #cache contexted and noticed that the name of the view is not used in that context.

The CID of both entries are almost the same.

#markup has
entity_view:node:290:teaser:[languages:language_interface]=en:[languages:language_url]=en:[theme]=customer:[timezone]=Europe/Amsterdam:[user.permissions]=b1d6062c14be41e5c86bbcd3e73a0b3f852f71d1eddb603347844a225e28d9a9

#redirect has
entity_view:node:280:teaser:[languages:language_interface]=en:[theme]=customer:[user.permissions]=b1d6062c14be41e5c86bbcd3e73a0b3f852f71d1eddb603347844a225e28d9a9

I think that views should add the view machine name, or the template name to the cache tags of the rendered entity, but i'm not confident enough if this is actually handled by views or by the caching system.

A workaround could be, introduce a new display mode for that entity, but that feels dirty because the only difference between those two output's is one class on the wrapper DIV in the block code.

It would be helpful if a message appears in log at /admin/reports/dblog when core is updated.

Not sure if component 'database system' is correct.

I have a question about the 8.3 Content Moderation module. In pre-8.3 Content Moderation, you can edit the machine names of the states because you can have duplicate state labels. In the 8.3 version (interactive demo), I didn't see the means by which you can edit the state's machine name when you add a state. Will we be able to have duplicate state labels? If so, we'll need the ability to change the state's machine name. This is important, because I need the ability to create a new draft of a published item, as well as un-publish a published item and put it back to a draft state. I don't want to archive it - archive has a very different business meaning from un-publishing something that was published erroneously. In order to accomplish that, I would have 2 different Draft states - one is the default revision, the other is not. But I want both to have a label of Draft. I voiced this concern in the original issue in which this new version was documented. My comment was #65:HERE

Thanks!

Problem/Motivation

The textfield input for "user field" is #required, but has no label (the label is held by the table header) and thus shouldn't have a lone red asterisk. Seven correctly omits the marker if the label is empty.
Example of a form 'multiple, required' field form Bartik :

Seen in #501408: Display user fields on registration form, but is also visible in current HEAD when editing an existing user account with fields.

Beta phase evaluation

Proposed resolution

For these cases mark the title_display as hidden:
'#title_display' => 'invisible',

Remaining tasks

User interface changes

Yes, the red asterisk moves to the correct location AND accessibility is enhanced by a better label around the fields.

Before :

<h4 class="label form-required">My unlimited required field label</h4>
[...]<label for="edit-field-unlimited-0-value" class="form-required"></label>

After :

<h4 class="label form-required">My unlimited required field label</h4>
[...]<label for="edit-field-unlimited-0-value" class="visually-hidden form-required">My unlimited required field label (value 1)</label>

API changes

n/a

Problem/Motivation

At the moment, Content Moderation and Quick Edit are incompatible. If users are viewing a moderated entity, Quick Edit is only available on the default revision, which goes against Content Moderation's workflow of always editing the latest revision. This can lead to tricky problems and bugs.

For example, enable moderation on an entity bundle, publish a draft, then create a new draft of that entity. If you visit the default (published) revision and use Quick Edit, the draft is discarded as Quick Edit is only aware of the default revision of any given Entity! This is really confusing for content editors (and may be considered a bug).

You can view a screencast showcasing the current problems here: https://www.youtube.com/watch?v=gvnXaT7HCeU

Proposed resolution

There are a number of steps that need to happen to make these modules work together:

1. Use the EntityRevisionConverter to pass the correct Entity revision to Quick Edit paths, in the same way Content Moderation currently handles Entity Forms.
2. Ensure that Contextual Links display on the latest revision of a Node. Otherwise Quick Edit will be inaccessible to users.
3. Make sure that the ModerationStateWidget does not interfere with Quick Edit operations.
4. Disable Quick Edit on non-latest and live revisions of moderated entities.

Remaining tasks

Review the provided patch.

User interface changes

None.

API changes

Quick Edit routes provided by inline editors will need to set the route option "quickedit_entity_route: TRUE" so that Content Moderation knows to swap what revision is provided for moderated Entities. This was an explicit way to add this support, as Quick Edit routes are not required to share any similarities and the alternative would be to hard-code routes (see my Workbench Moderation patch from #2749503: Add basic support for Quick Edit).

\Drupal\content_moderation\Entity\Handler\ModerationHandlerInterface will get a new method, entityViewAlter, which will allow handlers to perform modifications on a built moderated entity. This is used by \Drupal\content_moderation\Entity\Handler\NodeModerationHandler to disable Quick Edit on individual revisions and ensure that contextual links on the latest (non-default) revision are rendered normally (typically non-default revisions of Nodes have different contextual links).

Data model changes

None.

Problem/Motivation

#2561115: Use 'Filter' for exposed filter button text in new views and new installations (instead of 'Apply') changed the default submit button text for exposed filters from Apply to Filter.
Let's discuss whether we want an update path for that.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

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

The PHP-FIG has an open PSR in draft, PSR-14, for an "Event Manager" (what we'd call an Event Dispatcher in Symfony):

https://github.com/php-fig/fig-standards/blob/master/proposed/event-mana...

(Ignore the current state of the proposal, it's going to change dramatically.)

The goal is to create a cross-project lightweight interface for what Drupal currently uses hooks and Symfony Events for, so that 3rd party libraries can fire events for that interface and be easily plugged in to Drupal, or Symfony, or Zend, or Laravel, or whatever. The expectation is that each major system will, likely, still have its own implementation of that interface, much as we do for PSR-3. Details of what that will look like have yet to be ironed out.

Fabien Potencier has indicated that he MAY transition Symfony to it as well, IF such a transition is feasible to do without a hard-break.

Under FIG 3, this will turn into a formal Working Group, with Chuck Reeves as the Editor.

Naturally Drupal has a lot of expertise to offer here, as well as a vested interest in the outcome. Therefore, I would like to propose the following:

1) As Drupal FIG Representative, I join the Working Group and work to ensure that Drupal's experience and needs are included in the outcome.

2) We use this thread as a coordination thread to gather and centralize Drupal feedback, and where I will provide periodic updates or requests for feedback. (On a completely arbitrary schedule as most PSRs are developed on an arbitrary and inconsistent schedule.)

3) Drupal states an intention to at least try to implement PSR-14 in our next major version (Drupal 9). While FIG members are not required to implement any PSR, there is an expectation that we will give them "due consideration". And if we're involved in the creation of the spec then presumably the outcome is something that we will be able to adopt. If it's not, we screwed up somewhere. :-)

I intend to work on the spec regardless, but I'd rather do so with my official Drupal hat on now that FIG is setup to encourage that.

Tagging to ping the right people...

This issue was reported for the Workbench Moderation module. It also exists in Content Moderation, so I'm adding it here.

I have a role (manager) with permission to view any unpublished content. That role can also view the latest version, can create and edit any content type X.

Webmaster (administrator role) creates a content type X node. It's in the Draft (unpublished) state.
User A with role "manager" cannot access that node.
Webmaster publishes that node, User A then has access to it.
Webmaster creates a new draft version of that node (has published version and unpublished version).
User A can view and moderate the unpublished version.

User A creates a content type X node. As soon as User A saves it, user gets message: "The website encountered an unexpected error. Please try again later.".
Webmaster can see and access that node (unpublished), but User A cannot - even though User A created it.

Problem: users other than administrator cannot view unpublished content that does not have a published version when they have the View any unpublished content permission.

This renders workflow useless.

Here 's a link to the issue reported for Workbench Moderation: ISSUE

Problem/Motivation

Redis Sorted Sets are, similarly to Redis Sets, non repeating collections of Strings. The difference is that every member of a Sorted Set is associated with score, that is used in order to take the sorted set ordered, from the smallest to the greatest score. While members are unique, scores may be repeated.

https://redis.io/topics/data-types#sorted-sets

Borrowing the idea from Redis, Drupal's key value store should introduce sorted sets.

The current need for this comes via the workflow initiative where we would like to store data in a key/value store but want to be able to order them or do range queries. We'd call it a sequence index and store entity activity, so that when we do content replication we can replicate in the order that activity took place.

Proposed resolution

We already have this in contrib (http://www.drupal.org/project/key_value) and hope it's just a simple case of moving to core.

Remaining tasks

Write a patch

User interface changes

none

API changes

An additional key value store

Data model changes

An extra database table for the new store

While working on a patch for Linkit I failed to set a custom attribute as link text without completely overriding the plugin.js of drupallink.

drupallink uses this code to create the link text: var text = new CKEDITOR.dom.text(returnValues.attributes.href.replace(/^mailto:/, ''), editor.document);
Do I have to override the complete plugin to use another attribute returned by the editor dialog?

Eventually the following code fragment would be an option (as a patch), but maybe there is a better way.

// Use link URL as text with a collapsed cursor.
if (range.collapsed) {
  // Shorten mailto URLs to just the email address.
  var text = new CKEDITOR.dom.text(returnValues.attributes.href.replace(/^mailto:/, ''), editor.document);
  if (editor.config.hasOwnProperty('drupalLink_attributeText') && returnValues.attributes.hasOwnProperty(editor.config.drupalLink_attributeText) && returnValues.attributes[editor.config.drupalLink_attributeText].length) {
    // Use custom attribute as link text.
    text = new CKEDITOR.dom.text(returnValues.attributes[editor.config.drupalLink_attributeText], editor.document);
  }
  range.insertNode(text);
  range.selectNodeContents(text);
}

I've updated to 7.53. I need to move a block to the top of the list on admin/structure/block. I'm using Chrome. When I drag the block's entry from position 4 to the first position, I get the following error in the console and I can't disengage the drag and drop.

js_dJsXzkLhhP4qSYFd_v3Og65fG0PiSDDHGlNVviprTDo.js:1922 Uncaught TypeError: Cannot read property 'className' of undefined
at Drupal.tableDrag.tableDrag.onDrop (js_dJsXzkLhhP4qSYFd_v3Og65fG0PiSDDHGlNVviprTDo.js:1922)
at Drupal.tableDrag.dropRow (js_dJsXzkLhhP4qSYFd_v3Og65fG0PiSDDHGlNVviprTDo.js:560)
at HTMLDocument. (js_dJsXzkLhhP4qSYFd_v3Og65fG0PiSDDHGlNVviprTDo.js:110)
at HTMLDocument.dispatch (jquery.min.js:3)
at HTMLDocument.i (jquery.min.js:3)

However, if I drag a block's entry to any position other than the top, it works correctly.

Problem/Motivation

Specific preprocess functions not being picked up for template_ prefix which is probably some logic issue that is remaining after #939462: Specific preprocess functions for theme hook suggestions are not invoked got fixed.

Proposed resolution

Make template_ prefixed preprocess function picked up. Example preprocess function that is not being picked: template_preprocess_node__article.

Remaining tasks

• Write failing test
• Write fix for the bug
• Test manually
• Review code

User interface changes

API changes

Data model changes

Problem/Motivation

While working on #2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method, I noticed it was unfortunately necessary to rebuild the router whenever you imported (i.e. deployed) RestResourceConfig config entities. This should happen automatically thanks to a ConfigEvents::SAVE event subscriber.

Worse, you actually even need to call drupal_flush_all_caches(): just calling $this->container->get('router.builder')->rebuild() is insufficient! (I have no idea why yet.)

When doing an import through the UI, this means you need to go to /admin/config/development/performance and click the Clear all caches button. If a developer forgets this step, then their REST routes won't work.

Proposed resolution

Implement config save event subscriber that triggers a route rebuild.

Remaining tasks

TBD

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

EntityResourceTestBase tests fail randomly. See https://www.drupal.org/pift-ci-job/564977. I think this has only been seen on PHP7.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Updated: Comment #N

Problem/Motivation

When an array of suggestions is passed to theme(), the twig_debug output doesn't match up.

Proposed resolution

Display the suggestions that are passed in as an array.

Remaining tasks

Patch
Tests

User interface changes

Twig debug output will display the suggestions passed in as an array.

API changes

None