Hi, just as the title says:
When you define a rest resource, you have to use the Drupal\module_name\Plugin\rest\resource namespace, however, "resource" is a soft reserved keyword in PHP7.
See: http://php.net/manual/en/reserved.other-reserved-words.php

Large info files of more than around 1500 items causes Drupal to throw an exception.

Issue Details

Features itemizes it's exportables in a feature module's mymodule.info file. Drupal core caches the info file as a serialized array. When there get to be about 1000 - 2000 items exported (strongarm variables for instance) , the size of the serialized array exceeds the size of the MySQL column (system.info) which is currently 64K.

I was going to try and just alter the table, but I need this work during site-install and even when a module isn't enabled, the info file still gets cached resulting in a SQL Exception. I tried some hacks to hook in right after system table gets created in drupal_install_system() , but before system_rebuild_module_data(). The only thing that could possibly work is a function declaring system_system_info_alter() in settings.php, but that function already exists so it can't work either.

Proposed Solution

I propose a hook_update_N and schema update to change the value of system.info from blob (normal), to size 'big', which will support larger info files.

Updated #65

Problem/Motivation

• Install content_moderation
• Apply the "Editorial" workflow to articles.
• Create an article node in the published workflow state.
• Goto /admin/content
• Use the bulk action "Unpublish content" on the article node.
• You will see this validation error:
  

Proposed resolution

• Remove the publish/unpublish action
• Provide action plugins for every state
• Dynamically create/update/delete action instances when workflow settings are changed.
• Update moderation_content admin view with the state actions.

Remaining tasks

Dynamically create/update/delete action instances when:

• create/update/delete operation happens on a workflow entity by implementing hook workflow (insert|update|delete).
• changes to the workflow entity happen during config import.
• changes to the workflow entity are done hook_update_N.

Update moderation_content admin view with the state actions.
Add functional test for both cases.

User interface changes

moderation_content admin view will have state change actions.

API changes

No API change only addition.
Adds new moderation state change action and deriver.

Data model changes

None.

AFAICT, there's no way for a menu link plugin to cause the menu link not to appear.

There is MenuLinkInterface::isEnabled(), but returning FALSE from that causes the menu link itself to become disabled.

I've also tried returning either '' or NULL from getRouteName(), but that causes a routing crash. There's route '<none>' but that creates a link to the current page.

At this point the only thing I can see to do is to create a custom route which always denies access, and return that route name.

Use case is that I am writing a custom menu link plugin to show a user's group. If the user has no group memberships, then the link should not show.

Drupal 8 creates <link rel="canonical" href="/relative/url" /> by default. support.google.com says:

Use absolute paths rather than relative paths with the rel="canonical" link element.

Use this structure: https://www.example.com/dresses/green/greendresss.html Not this structure: /dresses/green/greendress.html

I used the Google Search Console URL Inspection and found Google does not recognize relative urls as canonical. It says:

User-declared canonical N/A

This caused some google indexing issues with our D8 Multi-Language website.

Please see also: https://drupal.stackexchange.com/questions/270150/link-rel-canonical-hre...

Problem/Motivation

Layout discovery provides a handful of layout plugins that do not work with Layout builder's concept of section based layouts. Virtually all of layout discovery's layout plugins are stacked, and Layout builder operates on the idea that end users would choose to make a layout stacked with the provided user interface if they wanted that feature.

Proposed resolution

Provide a set of layout plugins specific to layout_builder. These should include (at least):

• 2 column 50/50 (not stacked)
• 3 column 33/34/33 (not stacked)
• 3 column 25/50/25 (not stacked)
• 4 column 25/25/25/25 (not stacked)

Others could probably be added as well. Popular variations on 2 column would likely be welcome additions.

Consider hiding the existing layout_discovery provided plugins in Layout Builder's UI.

Remaining tasks

Build the plugins
Hide the old plugins.

User interface changes

Additional layouts to choose from when using Layout Builder UI.

API changes

none

Data model changes

none

Problem/Motivation

When processing a queue, it's common to run into situations where a single item cannot be processed. For example, perhaps an upstream URL is 404'ing, while other URLs in other queue items work fine. If the worker throws a SuspendQueueException, or nothing at all, all items end up blocked on the single failing item.

In the HTTP 404 case, the error is often transient and will solve itself, in which case trying again later provides a near seamless experience. In other cases (such as a broken queue item), at least other items in the queue won't be blocked from processing.

Proposed resolution

Let's allow queue processors to recreate items at the bottom of a queue, and allow queue workers to throw an exception indicating that the individual queue item is broken and should be recreated.

Remaining tasks

User interface changes

None.

API changes

reCreateItem becomes a new interface method required for queue implementations. This doesn't violate our b/c policy today as the interface isn't marked as @api, but if that was a concern we could create a new RecreateQueueInterface for the new method.

Data model changes

None.

Problem/Motivation

Once #2907413: Consider supporting one-off Layout Builder customization for other view modes is addressed, sections will be stored per-view mode.

LayoutEntityHelperTrait::getEntitySections() assumes the view mode is default.

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

N/A

API changes

TBD

Data model changes

N/A

I have two recurring errors in my log as follows. Please could someone advise on a php code snippet to remove these errors? Both are reported as a 'views' error type and occur when clearing all caches.

A non-existent config entity name returned by FieldStorageConfigInterface::getBundles(): field name: field_mpn, bundle: cpl_microwave_heat_packs_other

A non-existent config entity name returned by FieldStorageConfigInterface::getBundles(): field name: field_product_packed_volumetric_, bundle: default

Problem/Motivation

For all default layouts the bread is the same leading to the bundle edit page.

So to use the breadcrumb to get back to where you clicked "Manage Layout" you have to
click bundle item in breadcrumb
click manage display tab
click display mode tab

Proposed resolution

have breadcrumb's last item be the View Mode for the layout you are editing

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

When you are editing a default layout there is no way to know (besides your memory) which view mode the layout is for.

For example for articles the titles is always

Edit layout for Article content items

No matter which view mode is being configured

Proposed resolution

Add view mode to the title.

Edit [view_mode] layout for Article content items

Remaining tasks

Do it

User interface changes

View mode will be displayed

API changes

None

Data model changes

None

Hi,

Im not sure if anyone else has got this error or not, but when I try to perform a validation $form_state->setErrorI am getting an error 

LogicException: The database connection is not serializable. This probably means you are serializing an object that has an indirect reference to the database connection. Adjust your code so that is not necessary. Alternatively, look at DependencySerializationTrait as a temporary solution. in Drupal\Core\Database\Connection->__sleep()

I will explain a bit more. In my form I have a form element which has an "Add more" functionality. That is, I can add another instance of that field with an incremented index in its name which is working all fine. Now I have added a form validation and want to validate against all the instances of this field. Its a straight forward validation logic

if (empty($field)) {
  $form_state->setError($form['content_bag_container']['bag_wrapper'][$key]['content_bag'], t('Please enter a content bag name.'));
}

Weirdly enough, this validation works for the first instance of the form element which pre-loads with the page itself. But whenever, I create a new instance via ajax, this validation fails and throws this error message in the log.

Can anyone check if this is some problem from my end or a bug in the core, cause I am not sure if an ajax populated field should be validated separately.

Thanks in advance...

Problem/Motivation

Path aliases are currently represented as arrays. While this works OK it also comes with certain limitations. It is harder to document and extend. It is also prone to misuses/hacks.

Proposed resolution

We would like to have path aliases represented as objects with properly defined structure and business logic. It seems that going all the way to full-features content entities takes almost the same amount of effort while giving us even more goodies and flexibility.

Note about performance

Operating with an entity is heavier than just sending arrays around. This patch doesn't change any of the queries that happen in bootstrap phase (which is most sensitive to performance regressions). All the queries (even functions) stay the same. Same is true for URL generation.

Remaining tasks

- agree on direction/architecture
- prepare patch
- review patch

User interface changes

None.

API changes

Path alias arrays are converted to "path_alias" revisionable and translatable content entities

As I was testing some facet functionality I noticed the "Preparation time" facet range slider is not working as it should and then checked the Chrome Dev Tools to see if it's got the same errors I was having locally when I installed the Facet Range Widget module.
As suspected it had the same errors I was having:

Uncaught Error: no such method 'pips' for slider widget instance
    at Function.error (jquery.min.js?v=3.2.1:2)
    at HTMLDivElement.<anonymous> (widget-min.js?v=1.12.1:4)
    at Function.each (jquery.min.js?v=3.2.1:2)
    at r.fn.init.each (jquery.min.js?v=3.2.1:2)
    at r.fn.init.a.fn.(anonymous function) [as slider] (http://drupalsear.ch/core/assets/vendor/jquery.ui/ui/widget-min.js?v=1.12.1:4:1947)
    at Object.Drupal.facets.addSlider (<anonymous>:37:6)
    at Object.<anonymous> (<anonymous>:16:25)
    at Function.each (jquery.min.js?v=3.2.1:2)
    at Object.attach (<anonymous>:15:11)
    at drupal.js?v=8.5.7:25

This means that the "jQuery-ui-Slider-Pips" library that is required by Facets Range Widget (facets_range_widget) module is not installed.

While the slider works to restrict the search results by the range values, a few things get affected by the missing library such as the values on the range slider are not displayed, and I assume any JS running after those errors doesn't run properly on the page.

Problem/Motivation

function foo_entity_delete(EntityInterface $entity) {
  $context = EntityContext::fromEntity($entity);
}

This will fail.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Focusable elements across the site have these various focus style scenarios

1. default browser focus style only
2. default plus Umami focus styles
3. Umami successfully overriding default focus styles

	Mac OS - Safari	Windows - Edge
Skip link
Menu - active
Menu - not active
Umami logo
Search field
Search submit button
Log in link
Banner top button
Article card - image
Article card - title
Article card - view more
Recipe card - small - image
Recipe card - small - title
Recipe card - small - view more
Recipe card - large - image
Recipe card - large - title
Recipe card - large - view more
Footer links
Breadcrumb
Tags

Pages tested

<front>
/articles
/articles/give-it-a-go-and-grow-your-own-herbs
/recipes
/recipes/super-easy-vegetarian-pasta-bake

Most of the images are from the home page. Components that appear to be re-used are only included once – this includes the cards on the collection pages (/articles and /recipes).

Elements which have two focus states (default and Umami)

*names and screenshots*

Elements which do not have Umami theme focus states

*names and screenshots*

The default focus style on Firefox is a dashed line which is weak (stated in this issue as stated here https://www.drupal.org/project/drupal/issues/2942506 (the problem is when the thin dark outline directly abuts a dark image).

Chrome's is a thick blue line which doesn't always look great (off-centered, a side cut off the border, etc), and fails doesn't satisfy WCAG SC 1.4.11 Non-text contrast against the grey footer.

Proposed solution

- Carry on down the road of using focus styles from the theme?
- overriding the default selector and styles that browsers use to set their styling ie. :focus ?

I have three blocks on page, all them are created as Block Plugins and displayed via #lazy_builder in build() method. For every block is performed some requests to Jira using GuzzleHttp library.
Example of one of the blocks:

  public function build() {
    $build = [
      '#lazy_builder' => [ static::class . '::getIssuesList', [ $this->siteId ]],
      '#create_placeholder' => TRUE,
    ];
    return $build;
  }

  public static function getIssuesList($siteId) {
  /**
   * Here goes retrieving information and some calculations.
   * $data is an associative array.
   * $siteEntity is a custom entity received in this way \Drupal::entityTypeManager()->getStorage('site_entity')->load($siteId);
   */
    $build = [
      '#theme' => 'issues_list',
      '#data' => $data,
      '#toremove' => $siteEntity
    ];
    return $build;
  }

Expected result:
Blocks are rendered and displayed on page one by one in order in which they are written in twig template as far as $build array is formed.

Actual result:
Blocks are displayed on page one by one only if '#toremove' property with $siteEntity in present in render array and in twig template. Otherwise blocks are displayed at last moment together.

During debugging I see that for every chunk of content (for every block) debugger goes to 264 row of BigPipe.php -> sendChunk() method -> print $chunk but actually nothing is printed unless render array contains '#toremove' => $siteEntity

  protected function sendChunk($chunk) {
    assert(is_string($chunk) || $chunk instanceof HtmlResponse);
    if ($chunk instanceof HtmlResponse) {
      print $chunk->getContent();
    }
    else {
      print $chunk;
    }
    flush();
  } 

As far as calculations for blocks sometimes require sufficient time it's a big deal to display them in sequence, one after the other.

I suppose the problem might be related to flush() function as well.

Drupal version - 8.4.3. Site is launched on Docker4Drupal.

Update:
Actually I found out that it's about flush() function. In Docker4Drupal default value for output_buffering directive is 16384, so until the chunk size is 16384, buffer will not be flushed and as a result output won't be pushed to the browser. Therefore I needed '#toremove' => $siteEntity, this variable provided necessary size of chunk. But the next difficulty that I faced it's why header X-Accel-Buffering, which automatically disables gzip and fastcgi_buffering for BigPipe response on Nginx is not sent to browser.

BigPipeResponse.php file, from the 94 row:

// Add header to support streaming on NGINX + php-fpm (nginx >= 1.5.6).
$this->headers->set('X-Accel-Buffering', 'no');

Response.php, from the 383 row:

// headers
   foreach ($this->headers->allPreserveCase() as $name => $values) {
       foreach ($values as $value) {
            header($name.': '.$value, false, $this->statusCode);
       }
   }

Debugger stops at this points and set X-Accel-Buffering along with other headers, but it doesn't appear on Network tab of browsers.

*I have 1.14 version of Nginx. Check headers in Chrome and Firefox.

Problem/Motivation

SqlContentEntityStorage::mapToStorageRecord sends update statements that includes IDENTITY fields that need to be updated, such as: UPDATE xxx SET nid = 1, property0 = :value0 WHERE nid = 1;. This is not supported in SQL Server because although there is no actual update happening it is explicitly telling the database engine that you wish to perform an update.

Question: Is it correct to allow UPDATE statements that change (even if new value is same as previous) IDENTITY values?

IDENTITY column values are immutable.

Proposed resolution

Remaining tasks

User interface changes

API changes

Original report by david_garcia

In content_moderation.service.yml the "content_moderation.state_transition_validation" service has a class definition that starts with a "\"

This caused me an issue recently when I installed a site via drush, and imported config, would give me the following error:

The steps to replicate in my instance were:
drush si minimal
drush config:set uuid "THESITEUUID"
drush cim -y
drush cr
error :(

Notes:
The site has no content, Didn't have an issue prior to reinstall with site content.
Drupal 8.6
Drush 9
Extensive configuration
Using config split.
Worked D8.4 with Drush 8 think also D8.5

To fix
I removed the leading "\" cleared cache and reloaded.
I have observed a number of other instances in core of a leading "\" I am unsure if this is deliberate or not.

Problem/Motivation

Number, email, and reference field types are defined in the Core library, and when it came time to create MigrateField plugins for these fields, they were placed in the Core library.

However, these plugins extend MigrateFieldPluginBase from the migrate_drupal module, and depend on Interfaces from migrate and migrate_drupal modules. Code that depends on code in core modules should not be located in the Core Libraries.

Proposed resolution

Move plugins supporting field migrations of core fields into the field module, configure deprecations on the current classes in case anyone has extended them.

Remaining tasks

Do it.

User interface changes

none

API changes

None, but location of the plugins will change. This is allowed per BC policy, but we can leave deprecated BC shims in place until Drupal 9.

Data model changes

None.