In #2675464: Margin on form-items in table rows (Classy) we identified and devised a solution for a problem in the Classy theme that causes problems for modules like IEF and Paragraphs. However, @lauriii suggested it was too dangerous to fix properly in Classy without trying first in Seven.

Problem

In /core/themes/classy/css/components/form.css we have:

tr.odd .form-item,
tr.even .form-item {
  margin-top: 0;
  margin-bottom: 0;
}

This works fine for single element forms (like checkboxes or selects) in table rows, but causes problems when we want to have more complex multi-element forms in tables (like anywhere in a standard node edit form when a field widget requires multiple form elements).

Furthermore, this may break break content list styles; see comment 47 in #2675464-47: Margin on form-items in table rows (Classy).

Solution

Add the margin back in, overriding Classy. Then remove it just for td > .form-item:only-child.

Todo

1. Create a patch
2. Post screenshots showing before/after in a complex form like paragraphs
3. Post screenshots showing before/after in the content list
4. Tag for Needs frontend framework manager review
5. Copy issue credit across from #2675464: Margin on form-items in table rows (Classy)

Screenshots

Before:

After:

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...

The documentation here says that "The size of the conditional is the size of its conditional array minus one, because one element is the conjunction." After getting some unexpected results though I stepped through the code and found that the conjunction is not in the conditions array that the count function is going through (please see screenshot).

As such to get the expected results we had to use the conditions() function to get the array of conditions and pass them through count() ourselves.

Currently the system uses either: PECL uploadprogress http://pecl.php.net/package/uploadprogress or APC rfc1867 to show file upload progress (neither of which work with PHP 7 and nginx).

There was a discussion here https://www.drupal.org/node/1561866 about using the built in php session upload progress (PHP 5.4+) however Drupal's implementation of PHP session seems to interfere with this in a lot of cases.

https://www.drupal.org/u/droplet suggested that as D8 uses the jQuery.form plugin, it's proposed that we remove the reliance on 3rd party PHP libraries in the built in session upload progress and go with a the jQuery.form client side solution.

I have attached a patch that implements this and removes the old solutions.

It definitely needs review and some additional work (I would like this to work with remote file systems and CORS upload eventually).

Tested with Apache2 and nginx in Chrome (latest version).
I suspect there may be issues with Internet Explorer 9 compatibility. Does anyone know if there is a fallback built into jQuery.form to handle this?

Problem/Motivation

Currently ajax errors are only visible in the browser console. This is confusing for non-technical users because there's no indication in the UI that an error happened. Providing easy to understand error messages is often listed as one of the most important UX considerations.

Proposed resolution

Improve the ajax error handling so that errors are visible in the UI.

Remaining tasks

-

User interface changes

In case of an ajax error, the error will be visible in the UI.

API changes

-

Data model changes

-

At the moment there are few issues with data range field:
* filed is not integrated with `datetime` views plugin
* sorting is working but only for the start value
* filter is rendered as a string.

Using Drupal 8.2.7, we are not seeing this issue in 8.2.6

We have a content type that includes a required image field. Alt field is enabled and required, as well as the Title field. When we attempt to add new content of this type, we will select an image for upload from our local drive, and after we choose we notice that no preview or alternative text field appears. After attempting to save the content, we will be prompted for the alt text and we do see a thumbnail preview. Right after selecting the file for upload, our console is showing an AJAX error:

Uncaught 
Drupal.AjaxError
message: "↵An AJAX HTTP error occurred.↵HTTP Result Code: 200↵Debugging information follows.↵Path: /node/add/product?element_parents=field_product_image/widget/0&ajax_form=1↵StatusText: OK↵ResponseText: "name: "AjaxError"
__proto__: Error
    at http://<our_site>/sites/default/files/js/js_KozRDxBErHUfJMA7BgEUnamnTZc671T13mIssv8-wXY.js:2890:32
    at http://<our_site>/sites/default/files/js/js_KozRDxBErHUfJMA7BgEUnamnTZc671T13mIssv8-wXY.js:4053:3
Drupal.Ajax.error @ js_KozRDxBErHUfJMA7BgEUnamnTZc671T13mIssv8-wXY.js:3674
complete @ js_KozRDxBErHUfJMA7BgEUnamnTZc671T13mIssv8-wXY.js:3219
t.complete @ js_ZGVf7yyqX4XiBdN49CivMYwoCyt-AJMaBxLWwhfPoxk.js:565
i @ js_KozRDxBErHUfJMA7BgEUnamnTZc671T13mIssv8-wXY.js:2
fireWith @ js_KozRDxBErHUfJMA7BgEUnamnTZc671T13mIssv8-wXY.js:2
z @ js_KozRDxBErHUfJMA7BgEUnamnTZc671T13mIssv8-wXY.js:4
(anonymous) @ js_KozRDxBErHUfJMA7BgEUnamnTZc671T13mIssv8-wXY.js:4

We have tried changing the thumbnail sizes in the form-display settings for this content type to no avail.

The two pictures attached show before and after attempting to save, with form validation and thumbnail appearing after.

Problem/Motivation

Some modules need to act before an entity is loaded, and swap out the default revision with a different one.

For example, the Workspace module in core swaps the default revision with a workspace-specific revision, if one exists.

Proposed resolution

Add two new hooks: hook_entity_preload() and hook_ENTITY_TYPE_preload() that are called before the entity loading process.

Remaining tasks

Discuss, review.

User interface changes

Nope.

API changes

API addition, the two new hooks mentioned above.

Data model changes

Nope.

Problem/Motivation

To write test we are going to need different modules enabled.
You might want to test what happens before and after a certain module is installed.

Proposed resolution

Create a command to install modules.

If we could do this via PHP not via the UI then it would speed up test a lot. Every test is going to need to enable modules.

Remaining tasks

do it.

User interface changes

API changes

Data model changes

Problem/Motivation

There might be use cases in custom/contrib where we have to take a different decision depending on if we are comparing a field item list from within ContentEntityStorageBase::hasFieldValueChanged, ContentEntityStorageBase::populateAffectedRevisionTranslations or from within ContentEntityBase::hasTranslationChanges.

ContentEntityStorageBase::hasFieldValueChanged needs to compare only the values that are saved to the storage that would be target_id only in case of entity references.

ContentEntityStorageBase::populateAffectedRevisionTranslations and ContentEntityBase::hasTranslationChanges on the other side might need much more complicated decisions to be made e.g. in our system we have translation changes on a entity reference field if the referenced entities have been changed which we are mainly using for inline editing. In this case FieldItemList::equals is not sufficient because of two reasons:
1. We are not able to differentiate wherefrom the function is called.
2. We do not know the language for which it is called in case of not-translatable field but ContentEntityBase::hasTranslationChanges might still wanna compute differences only for entities of a specific language as when the parent is rendered its references are retrieved in the current language of parent.

Proposed resolution

To solve the problem we introduce a new method FieldItemListInterface::hasTranslationChanges which has two parameters - one for the list to compare against and one for the language to consider. This new method will by default just call ::equals, but to give more developer possibilities the new method will be called to compare the lists from within ContentEntityBase::hasTranslationChanges instead the equals.

Remaining tasks

Review, Change Record, Commit.

User interface changes

None.

API changes

New method FieldItemListInterface::hasTranslationChanges.

Data model changes

None.

Problem/Motivation

There is a line of code $context['user'] = $this->currentUser; inside of LoggerChannel::log() that was introduced as part of #1289536: Switch Watchdog to a PSR-3 logging framework.

When the log message includes some type of wildcard referencing {user*}, then \Drupal\Core\Logger\LogMessageParser::parseMessagePlaceholders() converts {users*} to @users* and then, because we have a context key 'user', it tries to put the AccountProxy object in there, which gives you this recoverable fatal error like: AccountProxy could not be converted to string

I tracked the code of the dblog and syslog and there is no use of the user object from the context array, just the uid. This makes sense since the username of a user can change, the only thing that does not vary is the user id.

Proposed resolution

• Remove the non used line.
• Create a change record that explicit indicates this lines was removed in case a contrib module was depending on this.

Please credit to @penyaskito and @berdir in this issue too.

Problem/Motivation

Follow up #2784921: Add Workspaces experimental module.

+++ b/core/modules/workspace/src/EntityOperations.php
@@ -0,0 +1,248 @@
+
+    // Handle the case when a new published entity was created in a non-default
+    // workspace and create a published pending revision for it. This does not
+    // cause an infinite recursion with ::entityPresave() because at this point

Is this logic explained anywhere else? If not it could probably use expansion (can be in a follow-up issue, but it's a tricky thing to explain exactly why it happens like it does).

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

When editing content from this page https://example.com/admin/content clicking the edit button and saving the content works the first time. The content just edited then goes to the top of the page for being the most recent edited content. Trying to edit the next piece of content in line, opens the previous content.

This does not appear to be a bug if logged in as administrator, only when non admin.

What are the steps required to reproduce the bug?

Login as non administrator
Go to https://example.com/admin/content
Click edit link on second content in list
Edit > Save (Content should be at top of list now)
Edit next content in line after previous
The content will be the previous document.

OS, webserver name and version, PHP version, Drupal version, Drupal path

OS: OSX 10.12.6
Browser: Chome 67.0.3396.99 (Official Build) (64-bit)
PHP: PHP 7.2
Hosting: Acquia
Drupal core version: 8.5.5
Path: https://example.com/admin/content

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

See #2848161: [meta] Replace calls to deprecated db_*() wrappers.

Replace all usages of db_insert in core, except in code that is testing db_insert.

Problem/Motivation

The current instructions for updating core can result in broken sites.

3. Remove the 'core' and 'vendor' directories. Also remove all of the files
in the top-level directory, except any that you added manually.

If you made modifications to files like .htaccess, composer.json, or
robots.txt you will need to re-apply them from your backup, after the new
files are in place.

5. Re-apply any modifications to files such as .htaccess, composer.json, or
robots.txt.

If you've done the following your site will be broken:

1. Install Drupal from git or the tarball
2. Get a module like AMP or Address that uses a library
3. Follow the instructions to do composer require from root
4. Follow the core UPDATE.txt instructions

If you re-apply the changes to composer.json by hand then vendor won't be magically fixed until you've run composer install. If you maintained all the non core provided directories in vendor this won't work either because the autoloader in vendor/composer will not know how to get to the non core dependencies.

Proposed resolution

I'm not sure what the real instructions should be. Here are some thoughts:

1. We need to ensure hook_requirements detects missing composer dependencies and is fired before updating (drush needs a fix for this https://github.com/drush-ops/drush/pull/2708 and not all modules do it correctly #2867687: We should be checking if the lullabot/amp is available during update.php too) See: #2494073: Mark modules with unmet composer dependencies uninstallable
2. We should be telling people to do "composer require dependency" again this ensures that the latest version and any dependency conflicts etc are detected
3. What about other composer.json customisations?
4. We should tell people if drupal/core is in the require section of their project (ie. they have a composer managed project) to just do composer update drupal/core --with-dependencies

Remaining tasks

User interface changes

API changes

Data model changes

Having struggled with more or less the same problem described in issue #2450867, which is both old and closed as duplicate, I've uncovered part of the problem and underlying cause, in my case at least.

My setup was multilingual and configured for language selection from URL. When trying to export full config from /admin/config/development/configuration/full/export, it was redirecting to /en/admin/config/development/configuration/full/export-download (NB starts with /en and ends with export-download) which was gave a 200 OK response code, but no src html or download file, i.e. White Screen Of Emptiness (WSOE, not WSOD!).

I disabled URL language selection and tried again and got the [common and not surprising]: Fatal error: Maximum execution time of 30 seconds exceeded in /core/lib/Drupal/Core/Archiver/ArchiveTar.php on line 2257.

Solution easy: in php.ini set: max_execution_time = 300

Bingo - full export works fine, even when I re-enable URL language selection.

But the thing that needs some attention is why the language redirect is hiding the PHP fatal error and returning 200 OK.

See #2848161: [meta] Replace calls to deprecated db_*() wrappers

Problem/Motivation

In #2953656: No ability to control "extra fields" with Layout Builder we add a custom assertion to assert that text only appears once on a page this is totally useful in more situations that just this one test. For example most assertions on messages should use something like this.

Proposed resolution

• Add WebAssert::pageTextContainsOnce() based on the code for pageTextContains()
• Add tests for the new assertion.
• Update tests added by #2953656: No ability to control "extra fields" with Layout Builder to use it.

Suggested code:

   $actual = $this->session->getPage()->getText();
   $actual = preg_replace('/\s+/u', '', $actual);
   $regex = '/'.preg_quote($text, '/').'/ui';
   $message = sprintf('The text "%s" only appears once on the current page.', $text);
   $this->assertSession()->assertResponseText((bool) preg_match_all($regex, $actual) === 1, $message);

Remaining tasks

User interface changes

none

API changes

new test assertion

Data model changes

none

Problem/Motivation

Make $modules protected on BrowserTestBase and KernelTestBase.

Use something like

find . -path './.git' -prune -o -not \( -name '*.js' \) -type f -path '*/tests/*' -exec sed -i -e 's/public static $modules/protected static $modules/g' {} \;

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

To reproduce:

1. Enable rest, hal, language, content_translation on a standard profile.
2. Enable a second language (German) and make the node type "page" translatable with all fields.
3. Save the attached JSON text file (generated by NodeHalJsonCookieTranslationsTest).
4. Enter the Drupal console and use the following commands:

$serializer = \Drupal::service('serializer');
$data = $serializer->decode(file_get_contents('JSON_FILE'), 'hal_json');
$node = $serializer->denormalize($data, 'Drupal\node\Entity\Node', 'hal_json');

The deserialized node's translation contains values for all "default" items (status, sticky, created, changed, langcode, etc.)

print count($node->changed); // 1
print count($node->getTranslation('de')->changed); // 2

The duplicates increase each time the node is normalized and denormalized.

$node = $serializer->denormalize($serializer->normalize($node, 'hal_json'), 'Drupal\node\Entity\Node', 'hal_json');
print count($node->changed); // 1
print count($node->getTranslation('de')->changed); // 3
$node = $serializer->denormalize($serializer->normalize($node, 'hal_json'), 'Drupal\node\Entity\Node', 'hal_json');
$node = $serializer->denormalize($serializer->normalize($node, 'hal_json'), 'Drupal\node\Entity\Node', 'hal_json');
print count($node->changed); // 1
print count($node->getTranslation('de')->changed); // 5

This looks like a bug in the field denormalization which causes it fail to properly clear default values.

Tested on 8.5.x and 8.3.7. This is causing test failures in #2135829: [PP-1] EntityResource: translations support.

Proposed resolution

Avoid the field value duplication.

Remaining tasks

1. Get patch to green.
2. Review.
3. Commit.

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

We want to get rid of simpletest.module in Drupal 9. We want to prepare the latest Drupal 8 development branch as much as possible before opening the Drupal 9 development branch (see #2608062: [policy, no patch] Pre-requisites for opening Drupal 9). Therefore we need to convert all web tests to BrowserTestBase or UnitTestBase or KernelTestBase and deprecate WebTestBase.

Proposed resolution

1) Convert a small part of Drupal core web tests to Browser tests to get them battle tested. See all the conversion child issues that have been opened here before 2016-Sept-01.
2) Implement a backward compatibility layer as AssertLegacyTrait used by BrowserTestBase. Ideally a test conversion should only be the change of the namespace and used base class. Everything else should be covered by backwards compatible methods as far as possible/reasonable.
3) Prepare one big bang patch of test conversions in #2770921: Feb 21st: Convert chunk of WTB to BTB by just moving classes, changing use statements adding traits. Commit it during code freeze of the next Drupal minor release (likely March 2017 for 8.3).
4) In the meantime open child issues to convert web tests for each core module. While doing so we should also check if the test cases actually require a browser or can be converted to unit/kernel tests. They will be postponed until #2770921: Feb 21st: Convert chunk of WTB to BTB by just moving classes, changing use statements adding traits is committed.

Instructions for converting a Simpletest web test

1. Read https://www.drupal.org/phpunit and all subpages, especially https://www.drupal.org/node/2783189 .
2. Do not bulk move all the test files but move and work on one test at a time.
3. Move the test file to a tests/src/Functional folder in the module.
4. Rename the namespace, make the class extend BrowserTestBase and fix the use statement.
5. If there is a test method which does not perform any web request (for example no ->drupalGet() or ->drupalPostForm() calls) then that method should be extracted to a unit test or kernel test. $this->setRawContent() generally means the test should be converted to a Kernel test
6. $this->drupalPostAjaxForm(); means the test should be converted to a Javascript test. There most likely already is an issue for it, see #2809161: Convert Javascript/AJAX testing to use JavascriptTestBase
7. Otherwise try to change as little as possible in the converted web test. Do not get tempted to "improve" or "tidy up" the tests - the conversion should be easy to review with only the minimum necessary changes. Further cleanup can be done in a follow-up issue.
8. Run the single test file with phpunit (replace the path with the file you converted):
   

   cd core
   ../vendor/bin/phpunit   modules/help/tests/src/Functional/HelpTest.php --stop-on-failure
   

9. Regularly upload a patch to see if the tests pass on the testbot as well.
10. If the conversion starts to involve complex changes, please reach out to people or search the other conversion issues. Occasionally it can be helpful to skip tricky tests, in which case update the issue summry stating which tests are not converted yet.
11. Create follow-up issues to deal with blockers so that progress can continue with converting the majority of tests in a module. Update the "Conversions blocked by another" section on this page.
12. Any TestBase or Trait which is in the old /src/Tests/ location should remain there and be deprecated. Copy the TestBase or Trait file into the new location and alter the tests to use the new version. The deprecated class must not "use" the newly-moved class, but remain exactly as it is. Create a change record for the deprecation notice - one CR can cover all deprecations within a module.

Hints and Tips

• Simpletest allowed typecasting of elements. BrowserTestBase does not. Instead of (string) $element use $element->getText() or $element->getHtml();
• Views tests need the new constructor format with $import_test_views = TRUE as the first parameter in the setUp() method.
• Attributes are fetched with $item->getAttribute('value'); now, previously it was $item->value or $item->attributes()->value.
• Not all legacy assertion methods are implemented yet, for example you may get Fatal error: undefined function assertNoLink(). Check #2750941: Additional BC assertions from WebTestBase to BrowserTestBase to borrow from there.

Remaining tasks

Resolve all the child issues. Convert web tests in child issues per module/component in Drupal core.

Issue creation

Please add the tag 'phpunit initiative' to every issue and add the issue to the correct Component (if it's a test for the comment module, add it to comment.module).

Remaining conversions per module

• field: #2870444: Convert web tests to browser tests for field module
• field_ui: #2794347: Convert web tests to browser tests for field_ui module
• quickedit: #2870458: Convert web tests to browser tests for quickedit module
• simpletest: #2932909: Convert web tests to browser tests for Simpletest module
• system: #2862508: Convert system functional tests to phpunit
• taxonomy: #2887134: Convert web tests to browser tests for taxonomy module Part -2
• text: #2870462: Convert web tests to browser tests for text module

Remaining simpletests

Check http://simpletest-countdown.org/simpletestcount/simpletests

Some of these are covered by the module conversions and their follow-ups, some are not. If you see a group of tests that still need to be converted but are not covered by an existing issue, feel free to open one up. Please try not to open one issue per test unless there is a really compelling reason to do so (it's the last of its kind, it's a really difficult conversion etc.).

Conversions blocked by another

• Example - this issue
  • is blocking this one
  • and this one
• #2809501: Convert AJAX part of \Drupal\field_ui\Tests\ManageDisplayTest to JavascriptTestBase
  • #2794347: Convert web tests to browser tests for field_ui module
• #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
• #2870444: Convert web tests to browser tests for field module
• #2870444: Convert web tests to browser tests for field module
• #2870462: Convert web tests to browser tests for text module

Progress report

Want to know how we are doing? Check: http://simpletest-countdown.org

API changes

Simpletest and WebTestBase will be deprecated.