Problem/Motivation

History

We added support for CRUD operations on content entities via REST without test coverage. Test coverage followed in #2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method. Translation support never materialized — this issue is the proof of that:

1. this was created in November 2013 (when REST was still in heavy development).
2. Then it was only commented on again almost a year later, in Q4 2014! From #3–#25, there was a solid discussion about how this should work. But no patches.
3. One comment in all of 2015: #26, just updating this issue summary.
4. Then another year later, I commented, in February 2016, in #27, bumping it from Normal (GASP) to Major.
5. Now we're another year later, and still no work happened.

As such, we have no official, and no documented way to handle translations of entities. Do we return all translations at once or not? How do you modify existing translations? And so on.

@Crell and @dixon_ outlined how they thought it should work in #21 and #22: they tried to adhere to RESTful principles as closely as possible. But alas, per the timeline: no work was done.

So, that brings us to today, where Drupal 8 has been out for more than a year (since November 2015), Drupal 8.0, 8.1 and 8.2 have been released, and 8.3's beta is being tagged in a few days. Drupal 8.3 will ship without this too. That's 4 minor releases without support for this. Time to change that. 8.4 MUST have this fixed.

How to move forward: just add test coverage?

However, that also means that we can't just do anything. We cannot break backwards compatibility. Unfortunately, the #21/#22 proposal would break BC.

As I wrote in #46:

Just had a discussion about this with @damiankloip & @tedbow. (On January 30, but only got around to finish this now.)

There are two key observations that were made:

1. Doing the multipart approach @dixon_ suggested in #22 may very well be the most correct approach (the ideal solution), but doing so is unquestionably a BC break.
2. Ted showed in #32 that this already works today. In a way that is natural/intuitive/guessable to a Drupal developer: via a langcode path prefix. Changing that now would also effectively be a BC break, since it's extremely likely that multilingual sites are already suing this.

So doing the ideal isolation would result in a double BC break, hence that approach must be postponed to D9.

---

The pragmatic solution is therefore to just expand the test coverage in EntityResourceTestBase to test all HTTP methods against all entity types in multiple languages.

Why does the existing code already kinda work? Thanks to \Drupal\Core\ParamConverter\EntityConverter::convert(), which calls getTranslationFromContext().

In other words, the ideal solution is without question off the table. But is adding tests enough? There are several problems/questions to answer:

1. #49 points out that getTranslationFromContext() supports not just path-based language negotiation, but also domain etc. Do we want to support that?
2. #51 points out that the HAL normalization and hence the HAL+JSON format in fact does not return a single language, but all translations of every single field. So the HAL normalization is already kind of doing what #22 wanted to do. If a particular language is requested, does that mean that HAL should return only that translation?

Proposed resolution

1. Add test coverage for serialization-normalizer-based formats (currently only json): test that /de/node/1?_format=json returns the German translation, and also allows modifying that translation
2. Add test coverage for hal-normalizer-based formats (currently only hal_json): test that /node/1?_format=hal_json returns all translations, and /de/node/1?_format=hal_json returns only the German translation
3. Language negotiation mechanisms other than the path-based one: TBD

Remaining tasks

TBD

User interface changes

None.

API changes

TBD

Data model changes

None.

See #2735005: Convert all Simpletest web tests to BrowserTestBase (or UnitTestBase/KernelTestBase)

Postponed on

Needs partial conversion to WebDriverTestBase or BrowserTestBase:
#2809489: Convert \Drupal\field\Tests\NestedFormTest to BrowserTestBase
#2809493: Convert AJAX part of \Drupal\field\Tests\Boolean\BooleanFormatterSettingsTest::testBooleanFormatterSettings to JavascriptTestBase
#2809495: Convert AJAX part of \Drupal\field\Tests\EntityReference\EntityReferenceAdminTest to JavascriptTestBase
#2809499: Convert AJAX part of \Drupal\field\Tests\Number\NumberFieldTest to JavascriptTestBase

Problem

When setting language detection method, the checkbox Customize Content language detection to differ from User interface text language detection settings is not applied, only the interface configuration.

This leads to two critical issues with translating content:

1. It is not possible to edit translated version of a node. All "Edit" urls on node's "Translate" tab are the same and lead to main editing form. See edit.png.
2. Translated content is never shown to the user. Default language is always displayed.

Steps to reproduce

On a fresh D8 install:

1. Enable content translation and language modules
2. Add another language
3. Set Detection and selection method to session and browser (tested both, both are broken)
4. Configure content type "Article" to be translatable (Administration >> Configuration >> Regional and language)
5. Add a node and set it's language to default one (I used article with image. All fields were filled including image)
6. Translate node to a second language and save.
7. Go to "Translate" tab and investigate "Edit" links. Both lead to the same page.
8. Go to the newly create node and try switching language using "session" parameter. You will still see the node in default language.
9. Do the same with a browser running second language (or just spoof the browser string to change language). You will still see the node in default language.

Remaining tasks

1. Investigate why the checkbox Customize Content language detection to differ from User interface text language detection settings is ignored. The source of the issue lies probably inside Drupal\language\Form\NegotiationConfigureForm::submitForm() function. - the configuration is correctly saved
2. Create patch - Patch is provided

User interface changes

No changes to the UI are required for the fix.

API changes

The protected variable type which indicates whether a given type of language usage (language_content, language_interface, language_url) changes to an array to allow different types to initialize during the initialization of another.

We are facing an issue on some of our live Drupal 8 Websites.

At random times, the images of the website are shown as broken. Inspecting the img tags, we see that the images src attribute is wrong. Instead of /sites/default/files/.... within the source of the images there is /index.php/sites/default/files/.....

This results the images on the website to show broken.

Also this is sometimes happening to the pages urls as well (i.e. ourdomain/index.php/basic_page_alias).

We tried to define the $base_url in our settings.php to cover the case of automatically detecting this /index.php/ as part of the default base url but this did not fix the issue.

Also it is important to mention that those mistaken urls are saved into the cache drupal db tables. After flushing the drupal cache the website is working normally until the same images are cached again mistakenly in drupal cache.

The website is running on nginx (and thus not using .htaccess), alongside PHP-FPM 7.0

We also provide an attached file with our ngnix configuration.

Any idea or help would be appreciated on what is causing this issue and how we can fix.

Worth noting that across 40+ websites on same configuration - only 2 websites are facing this issue. Both websites D8 - multilingual. Can see index.php being appended to sitemap.xml too on affected websites

1) I already tried editing the update.install

From if (!empty($data)) { to if (!empty($data)['drupal']) { but drupal stops working.

2) Do we have to enable the php module?

3) or do we have to remove in all modules *.info files the drupal.org info ?

I have developed a drupal 8 commerce website for a customer.
I have installed commerce reports alpha version.
And it was working well until certain situation where the module couldn't execute its batch progressing.
I though. "It's ok. I'll uninstall the module. Reinstall it. Maybe that will restore it to its defaults and fixes the problem."
Head to extend section and uninstalled the module. And here was the shock. The entire website stopped working providing me with the only famous message.

The website encountered an unexpected error. Please try again later.

Only the admin area stopped working, the front end was wroking well!

I headed to the log file to see this error record:

[22-Jul-2018 22:25:19 UTC] Uncaught PHP Exception Symfony\Component\Routing\Exception\RouteNotFoundException: "Route "commerce_reports.configuration" does not exist." at /home/kats/public_html/core/lib/Drupal/Core/Routing/RouteProvider.php line 202

Seems like Drupal broke in the middle of the uninstallation process.
and The only thing I could do is to restore a db backup (working in production environment).

The controls for the Time field do not display when using Safari on Mac. It only displays time in 24-hour format.

Error: Call to undefined method stdClass::id() in Drupal\ds\Plugin\views\Entity\Render\RendererBase->dsPreRender() (line 38 of /var/www/un-geneva-d8/modules/contrib/ds/src/Plugin/views/Entity/Render/RendererBase.php) #0 /var/www/un-geneva-d8/modules/contrib/ds/src/Plugin/views/Entity/Render/TranslationLanguageRenderer.php(46): Drupal\ds\Plugin\views\Entity\Render\RendererBase->dsPreRender(Array, true) #1 /var/www/un-geneva-d8/core/modules/views/src/Plugin/views/row/EntityRow.php(178): Drupal\ds\Plugin\views\Entity\Render\TranslationLanguageRenderer->preRender(Array) #2 /var/www/un-geneva-d8/core/modules/views/src/Plugin/views/style/StylePluginBase.php(434): Drupal\views\Plugin\views\row\EntityRow->preRender(Array) #3 /var/www/un-geneva-d8/core/modules/views/src/ViewExecutable.php(1508): Drupal\views\Plugin\views\style\StylePluginBase->preRender(Array) #4 /var/www/un-geneva-d8/core/modules/views/src/Plugin/views/display/Block.php(117): Drupal\views\ViewExecutable->render() #5 /var/www/un-geneva-d8/core/modules/views/src/ViewExecutable.php(1630): Drupal\views\Plugin\views\display\Block->execute() #6 /var/www/un-geneva-d8/core/modules/views/src/Element/View.php(77): Drupal\views\ViewExecutable->executeDisplay('block_1', Array) #7 /var/www/un-geneva-d8/core/modules/views/src/Plugin/Block/ViewsBlock.php(59): Drupal\views\Element\View::preRenderViewElement(Array) #8 /var/www/un-geneva-d8/modules/contrib/panels/src/Plugin/DisplayBuilder/StandardDisplayBuilder.php(135): Drupal\views\Plugin\Block\ViewsBlock->build() #9 /var/www/un-geneva-d8/modules/contrib/panels/src/Plugin/DisplayBuilder/StandardDisplayBuilder.php(176): Drupal\panels\Plugin\DisplayBuilder\StandardDisplayBuilder->buildRegions(Array, Array) #10 /var/www/un-geneva-d8/modules/contrib/panels/src/Plugin/DisplayVariant/PanelsDisplayVariant.php(329): Drupal\panels\Plugin\DisplayBuilder\StandardDisplayBuilder->build(Object(Drupal\panels\Plugin\DisplayVariant\PanelsDisplayVariant)) #11 /var/www/un-geneva-d8/modules/contrib/page_manager/src/Entity/PageVariantViewBuilder.php(34): Drupal\panels\Plugin\DisplayVariant\PanelsDisplayVariant->build() #12 /var/www/un-geneva-d8/core/lib/Drupal/Core/Entity/Controller/EntityViewController.php(97): Drupal\page_manager\Entity\PageVariantViewBuilder->view(Object(Drupal\page_manager\Entity\PageVariant), 'full') #13 [internal function]: Drupal\Core\Entity\Controller\EntityViewController->view(Object(Drupal\page_manager\Entity\PageVariant), 'full') #14 /var/www/un-geneva-d8/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array) #15 /var/www/un-geneva-d8/core/lib/Drupal/Core/Render/Renderer.php(582): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #16 /var/www/un-geneva-d8/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #17 /var/www/un-geneva-d8/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) #18 /var/www/un-geneva-d8/vendor/symfony/http-kernel/HttpKernel.php(151): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #19 /var/www/un-geneva-d8/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #20 /var/www/un-geneva-d8/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #21 /var/www/un-geneva-d8/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #22 /var/www/un-geneva-d8/core/modules/page_cache/src/StackMiddleware/PageCache.php(99): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #23 /var/www/un-geneva-d8/core/modules/page_cache/src/StackMiddleware/PageCache.php(78): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true) #24 /var/www/un-geneva-d8/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #25 /var/www/un-geneva-d8/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #26 /var/www/un-geneva-d8/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #27 /var/www/un-geneva-d8/core/lib/Drupal/Core/DrupalKernel.php(666): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #28 /var/www/un-geneva-d8/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #29 {main}.

Problem/Motivation

All work done so far only will affect the "main content" region of a site.

For full landing page functionality, more work is needed to control the sidebar, header, footer, etc.

Proposed resolution

Discuss!

Remaining tasks

User interface changes

API changes

Data model changes

This is the follow-up issue of Private file download returns access denied, as was suggested by @Berdir here.

Once upon a time a patch was committed to D7 core to make private files accessible, when there are nodes with revisions on your site (see "Private file download returns access denied" issue mentioned above). To achieve this, they changed some code at modules/file/file.module, namely file_get_file_references function parameter to FIELD_LOAD_CURRENT from FIELD_LOAD_REVISION.

But FIELD_LOAD_REVISION parameter was there for a good reason, with FIELD_LOAD_CURRENT we are not able to open files attached to all entity revisions except current. It's fatal in case you're trying to build, say, intranet with library for documents.

Steps to reproduce:
1.Set up clean Drupal 7.12 with private document folder (say, sites/default/files/private) and a content type with just a title and file field called field_file. It should store files in your private folder.
2.Login as UID1, create a node and add a file "testfile1.txt" to it's file field.
3.Save the node
4.Click edit
5.Remove the old file, "testfile1.txt"
6.Add "testfile2.txt"
7.Check "Create new revision" option
8.Click save
9. Click revisions tab, open first revision of your node
10. Node is fine, link to file is there, but when you'll click on this link to the file "testfile1.txt", you'll get "Page not Found"

It is possible to open old version of your file - if you'll revert old revision. But it is not an option in case you use revisions as revisions, not as backups for inaccurate users, because it will produce awful mess of revisions.

In short:

So if a user has access to a revision he should also be able to access its files. If not, not.

Regenerating the problem
- Edit article content type
- Add a Boolean field
- When setting default value you have only two choices (unchecked => null, checked => true)
Check box is used to set default value, I remember in Drupal 7 radio button is used instead.

so when trying to use the field as exposed filter in views. it doesn't work.

Problem/Motivation

The use of HTML5 "required" attribute in D8 has resulted in an accessibility regression. Basic client-side validation now occurs *before* hitting the server and running FAPI validation functions, so the browser jumps in and provides an error as you attempt to submit the form.

In Drupal 7, the FAPI error messages include a) an icon + alt tag to indicate their relative importance (e.g. warning/notice), b) an error message which included the name of the field for reference, c) a red outline on the field.

But in D8, those enhanced error messages are never displayed, in favor of the default browser response to a required field, which in Chrome's case is "Please fill out this field," without any mention of which field is referred to.

Proposed resolution

The accessibility team's goal for form validation is #1493324: Inline form errors for accessibility and UX. HTML5 best practices are:

1. Javascript validation first
2. HTML5 validation for no-Javascript
3. Server-side validation

Implementing Javascript validation before the HTML5 validation would restore accessibility for most users. A proposed patch changing the error message to "SomeFormField is required" would improve accessibility for those without Javascript.

Related Issues

#1696648: [META] Untie content entity validation from form validation
#742344: Allow forms to set custom validation error messages on required fields
#1845546: Implement validation for the TypedData API

Original report by mgifford

I was very surprised to see that in D8 that we've lost some accessibility in the current release as far as how error messages are presented.

They were much better in D7. In D8 they just say "Please fill out this field.", where in D7 there was a red box describing the problem at the top of the page. The error also had an image and text which identified what exactly the problem was.

Ultimately we need this in core #742344: Allow forms to set custom validation error messages on required fields

But the defaults for D8 should be at least as good as they were in D7.

Problem:

Nodes are not saving with inaccesible pre-existing referenced items.

Issue has been fixed once with the ticket: https://www.drupal.org/project/drupal/issues/2791269 stating, "Allow saving pre-existing references to inaccessible items" means there should not be any validation check for the existing referenced items.

Still the node save was disallowed and throwing an exception : "This entity (node: 32) cannot be referenced."

On cheking deeper the solution contains a condition:

/core/lib/Drupal/Core/Entity/Plugin/Validation/Constraint/ValidReferenceConstraintValidator.php
@@ -119,32 +119,31 @@ public function validate($value, Constraint $constraint) {
+          // Check if any of the invalid existing references are simply not
+          // accessible by the user, in which case they need to be excluded from
+          // validation
+          if (isset($previously_referenced_ids[$target_id]) && isset($existing_entities[$target_id]) && !$existing_entities[$target_id]->access('view')) {
+            continue;
+          }

Accordingly, the clause !$existing_entities[$target_id]->access('view') is causing problem in my casue.

Steps to reproduce

• Create a content type with an entity reference field, able to reference the same content type.
• Give a test user access to edit all content of that type + "view own unpublished content".
• Create an unpublished node using user "test user".
• Create another node referencing the unpublished node. using user "test user"
• As the test user, edit the second node. Notice the reference field says “- Restricted access - (1)”
• Try saving the node, get an “This entity (node: 1) cannot be referenced.” error.

here, the condition is failing becasue the "test user" has "view access" for the referenced unpublished node ceated by himself.

It is not only the problem with "view own unpublished content" permisisons. When you have any other Node access module enabled like Domain Access or content modertion. The issue get more severe and requires a broader scope.

Becasue user will be editing a node shared on different domains consisting different doamins (assigned) entity references.

Required solutions

1. The scope of the validation check should be defined.
   • When the items should be validated - pre-existing or new ?
   • Should validate existing items in case of deleted entites ?
   • What is overall requirement of the validations ?
2. Remove the "view access" condition ? And add other conditions depending upon the anwser of above point.

Follow-up to #2225775: Migrate Drupal 6 core node translation to Drupal 8

Problem/Motivation

In D8, a node revision has data for all languages. In D6 and D7, each node revision has data for just one language. This means currently D6 -> D8 and D7 -> D8 migrations yield a revision history where each node revision has only one language present, even if previous revisions had translations. This is strange and likely to confuse users.

Proposed resolution

D6 and D7 node revisions do not directly indicate which other translated node revisions they are associated with. But we can attempt to guess this, based on the order of revisions.

• For each D6 and D7 revision, the migration source should yield every translation that we think goes along with it. This means multiple rows per revision, which is slightly confusing. But it will provide a mostly-sane revision history.
• Make sure to pull in the correct fields for each such revision-translation row. The row's vid-for-matching-revisions-together may not necessarily be the same as its vid-for-finding-field-values.
• Make sure the current revision of each node has the correct data in it. This must be true even if the current revision is not the highest one (ie: revision was reverted).
• Make the code to accomplish this comprehensible. Previous attempts had complex subquery-joins, which need at least more explanation. Maybe there's a better solution without weird joins?

I think we need to agree on a technique for detecting the current media query that is active. This is not the same as #1252178: Add Modernizr to core

I think as we move Drupal to mobile first a lot of Drupal's javascript could be dependent on this. For example:
#1277352: Responsive vertical tabs
#1510532: [META] Implement the new create content page design
#1276908: Administrative tables are too wide for smaller screens
#1524414: Rewrite tabledrag.js to use jQuery UI
#1137920: Fix toolbar on small screen sizes and redesign toolbar for desktop

I think we should probably use this technique - http://www.springload.co.nz/love-the-web/responsive-javascripthttps://github.com/JoshBarr/js-media-queries

These are also similar:
http://harvesthq.github.com/harvey/
http://xoxco.com/projects/code/breakpoints/
http://rezitech.github.com/syze/

Would love to hear other peoples thoughts.

This entity type has no bundles.

Saw these when looking at test results, https://dispatcher.drupalci.org/job/drupal_patches/66032/consoleFull
Perhaps related to #2877839: Reuse option in FileCopy migrate process plugin not work with remote files?

12:00:41 Notice: Constant FILE_EXISTS_RENAME already defined in /var/www/html/core/modules/migrate/tests/src/Unit/process/FileCopyTest.php on line 13
12:00:41 
12:00:41 Notice: Constant FILE_EXISTS_REPLACE already defined in /var/www/html/core/modules/migrate/tests/src/Unit/process/FileCopyTest.php on line 18
12:00:41 
12:00:41 Notice: Constant FILE_EXISTS_ERROR already defined in /var/www/html/core/modules/migrate/tests/src/Unit/process/FileCopyTest.php on line 23
12:00:41 PHP Notice:  Constant FILE_EXISTS_RENAME already defined in /var/www/html/core/modules/migrate/tests/src/Unit/process/FileCopyTest.php on line 13
12:00:41 PHP Notice:  Constant FILE_EXISTS_REPLACE already defined in /var/www/html/core/modules/migrate/tests/src/Unit/process/FileCopyTest.php on line 18
12:00:41 PHP Notice:  Constant FILE_EXISTS_ERROR already defined in /var/www/html/core/modules/migrate/tests/src/Unit/process/FileCopyTest.php on line 23

You can check the current state of coding standards compliance using phpcs and coder from the command line:

$ cd /path/to/drupal/root/
$ composer install
$ ./vendor/bin/phpcs -p -s --standard=./vendor/drupal/coder/coder_sniffer/Drupal core/

There are a few changes to automate code review for the different parts:

• #1266444: DrupalCI should return failed for poor code style - php
• #2575497: DrupalCI should report code style issues - CSS
• #2575501: [PP-2] DrupalCI should return failed for poor code style - JS
• #2591827: DrupalCI should report code style issues - YAML
• #2985245: DrupalCI should return failed for poor code style - Twig

Origin

This is a followup of #1518116: [meta] Make Core pass Coder Review which was the original initiative from 2012 to fix coding standards in core. This new issue was made to replace the old one because the suggested workflow changed from a module-per-module approach to a sniff-per-sniff approach. The old issue has a large number of linked issues which are now obsolete.

Note that no coding standards fixes will be committed until the beta phase ends. Only when the first release candidate is released these issues will be eligible for committing.

Problem/Motivation

Drupal Core fails our automated coding standards tests.

Proposed resolution

It would be impossible to fix all coding standards at once. We will split up the work in manageable chunks. In a previous effort (#1518116: [meta] Make Core pass Coder Review) we split up the work per module, but this proved to be less than ideal since it requires intimate knowledge of ALL coding standards for everyone involved in the issue: developers as well as reviewers.

Instead we will now split up the work per type of coding standard. For example in separate issues we'll deal with trailing whitespace, inline comments, line lengths, etc. This will be much easier to review, since every patch will only contain very similar fixes.

In addition to fixing the coding standards, we'll also add automatic coding standards checking to the DrupalCI test bot. Once a particular coding standard is fixed, all new patches will be automatically checked and will fail if they do not meet this standard. This way we can progressively fix all coding standards, and ensure that what is once fixed will remain fixed.

An XML file (phpcs.xml.dist) was added to core to list all coding standards currently passing and it is used by the automated coding standards check. Whenever a particular standard is fixed we will add that sniff to phpcs.xml.dist or remove the exception from it, so it will be automatically checked from that point onwards.
Eventually phpcs.xml.dist would contain all sniffs defined in Drupal CS along with their configuration from ruleset.xml. All the sniffs defined in other CS and referenced in ruleset.xml should also be present in phpcs.xml.dist.
If rulesest.xml is modified or new sniffs are defined in Drupal CS, phpcs.xml.dist should also be modified.

Approach

1. We analyzed the available "sniffs" and put them in related groups. The goal is that each group can be easily fixed and reviewed as a whole.
2. Choose an unclaimed sniff from the Remaining Tasks section below and create a new issue for it. You can also work on one of the active child issues.
3. If you are creating a new issue:
   • it's best to clone one of the child issues. Pay attention to Title, Status and Parent issue fields. Parent issue field should reference this issue.
   • You may also assign the newly created issue to yourself.
   • Edit this issue summary and remove the sniff from Remaining Tasks section.
   • As always, when editing an issue summary, you should add a comment to the issue saying what you edited, so that anyone following this issue will get an email. In this case, provide a link to the new issue you filed and state which sniff you are claiming.

Remaining tasks

This list contains all sniffs for which we don't have an issue yet.

1. Drupal.Commenting.ClassComment.Missing
2. Drupal.Commenting.DocComment.MissingShort
3. Drupal.Commenting.DocComment.ParamNotFirst
4. Drupal.Commenting.DocComment.ShortNotCapital
5. Drupal.Commenting.DocComment.ShortSingleLine
6. Drupal.NamingConventions.ValidClassName
7. Drupal.NamingConventions.ValidFunctionName
8. Drupal.Semantics.FunctionT.NotLiteralString
9. Drupal.Semantics.FunctionT.ConcatString
10. Generic.CodeAnalysis.UselessOverridingMethod
11. PSR2.Classes.PropertyDeclaration.Underscore

Problem/Motivation

It's unclear whether we want to support operations like PUT using HAL, or whether we should just expect application/json.

Related discussions on the HAL mailing list:

• granularity of link relations and embedding resources
• POST/PATCH/PUT with Hal discusses whether state of embedded resources should be handled on PUT/POST/PATCH
• embedding links in a non-convoluted way discusses a similar approach to one we've been thinking about, having _links for all entity references but then also including the entity reference information in the state of the resource.
• HAL representation for PUT/POST/PATCH, in which Mike Kelly says "But, sure, definitely use HAL if you want to be able to write links, or include nested resources, in write requests."

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...