I'm getting the following runtime error in my PHP's error_log:

[Thu Jul 31 20:54:59 2014] [error] [client 98.176.242.59] PHP Fatal error: Cannot create references to/from string offsets nor overloaded objects in /var/www/drupal-7.27/includes/common.inc on line 6606, referer: http://myserver/mypath/summary?field_log_time_value%5Bvalue%5D%5Byear%5D...

and that URL results in a blank (white) screen.

I searched for this PHP error and saw a posting where someone said they upgraded their PHP and it fixed their problem. So I upgraded from 5.3.3 to 5.5.14 but the error and problem persist.

Please help!

(Note, I tried to search for the above title in the 7.27 core issues but got a blank page instead so please excuse this posting if it is duplicate or answered elsewhere. If it is answered elsewhere, I would appreciate a link to that page, thanks!)

Problem/Motivation

Our phpunit based functional javascript test will pass even if there are Javascript errors on the page.

While we test JS functionality sometimes a JS error will not break our tests because the core functionality still works but other JS that is the page of a particular site could be broken.

A user ran into this scenario on #3072231: Custom blocks break layout builder module - Quick Edit could not associate the rendered entity field markup

Proposed resolution

if a Javascript error is thrown to during a test fail the test.

Additionally

1. All core tests should fail on Console errors by default. Each class should not need to set a property so that we cannot ignore console errors in core tests by forgetting this property
2. Core tests should be able to set the property protected $failOnJavascriptConsoleErrors = FALSE; to suppress errors for 2 reasons
   1) This will allows use to commit this with known errors such as #3091878: MediaEmbedFilterConfigurationUiTest throws a Javascript Error or any others we find at the time we are able to commit this this issue. Before we commit this at any point we can't be sure how many tests will fail with this patch applied. We could be adding new tests that throw JS console errors with any commit.
   2)After this patch is committed we could have tests start to fail for a number of reasons such as, changes in the chrome driver/browser Drupalci uses or needed updates to our JS dependences. In the example of our JS dependencies these could be security updates that we need ASAP but also cause a small non-important JS console error. In such cases we should be able to commit the dependency updates and do a follow-up to fix the error.
3. Any class that extends \Drupal\FunctionalJavascriptTests\WebDriverTestBaseexcept core test, i.e Contrib and custom test, should have to opt in this behavior by setting protected $failOnJavascriptConsoleErrors = TRUE;. This will ensure a bunch of contrib tests will not start to fail after we commit this patch. We could consider changing this to opt out in Drupal 10
4. Contrib/custom tests should be able to opt in a bunch of classes at once by setting protected $failOnJavascriptConsoleErrors = TRUE; in a base test class like, MyModuleTestBase

Remaining tasks

All

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

TBD

Problem/Motivation

We've come upon an issue with the syncing of langcode with preferred_langcode on the User entity.

When editing the preferred language of the User entity to an existing entity translation langcode, an exception is thrown:
InvalidArgumentException: A translation already exists for the specified language (pt-pt). in Drupal\Core\Entity\ContentEntityBase->onChange() (line 810 of drupal/core/lib/Drupal/Core/Entity/ContentEntityBase.php).

After investigating the cause for this issue, our findings point to the entity builder Account:syncUserLangcode(), which is syncing the langcode with the preferred_langcode. This results in a problem when changing the langcode if the new value points to an existing translation. If this operation is removed, the problem no longer occurs.

Reproduction steps

1. Enable content translation
2. Add new languages to the site (e.g. pt-pt).
3. Translate the user entity to pt-pt.
4. Edit the User entity in its default translation, through the UI, setting its preferred langcode to pt-pt.
5. Save
6. Observe the thrown exception

Proposed resolution

Remove Account:syncUserLangcode(), which is BC break. We need to find out why it was introduced in the first place.
See #2230637: Create a Language field widget and the related formatter where this has not been discussed in the comments.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

#2846614: Incorrect field name is used in views integration for multi-value base fields (CR) changed the naming used for multi value base fields in views. It was noted in the CR/issue that this might be a BC break with #199.

For backwards compatibility, we should be converting configuration on config save, as has been done for other issues, however the patch that was committed makes the change inline in the update. Therefore installation of custom or contributed modules with affected configuration is broken.

Proposed resolution

Move the configuration change logic from the update handler to hook_view_presave(), a post update should be added to resave the views.

See https://api.drupal.org/api/drupal/core%21modules%21views%21views.module/... for existing examples of backwards compatibility logic for views config.

views_post_update_table_display_cache_max_age() is an example of a views post update using ConfigEntityUpdater

Problem/Motivation

Unit tests based on BrowserTestBase and KernelTestBase have a $modules property that allows to specify the modules that should be enabled before executing the tests. This property had always been intended to be protected, and it was declared as such in the two base classes.

However in practice many tests in Drupal core changed the visibility to public. Over time this problem became worse, mainly because some popular base classes (such as EntityKernelTestBase) were changing this property public, forcing all their child classes to make this property public as well. While there is no harm in making this property public, it is useless and the need to check the actual visibility to use when writing a test was resulting in lost developer time.

This property should now always be protected.

Make $modules protected on BrowserTestBase and KernelTestBase.

Use the next script to prepare changes for the patch:

# find PHP files in "tests" or "Tests" or "simpletest" directories
# replace 'public static $modules' with 'protected static $modules'
# replace 'static public $modules' with 'protected static $modules'
find . -path './.git' -prune -o -name '*.php' -type f \( -path '*/tests/*' -or -path '*/Tests/*' -or -path '*/simpletest/*' \) -exec sed -i -e 's/public static $modules/protected static $modules/g; s/static public $modules/protected static $modules/g' {} \;

Proposed resolution

During the RC time window generate the patch using the script and apply changes. Follow #33#49

Remaining tasks

Prepare script and be sure that it will cover all places where replacements are required.
Do not skip the time window
Current development cycle
Current window is: May 4 to June 3, 2020

User interface changes

API changes

Data model changes

Problem/Motivation

Spin-off from #3063887: Support PHPUnit 8 in Drupal 9, drop support for PHPUnit 7.

PHPUnit 8 is changing the signature of the main test methods that test classes extend - above all setUp and tearDown, adding a void return typehint.

As per #3063887-75: Support PHPUnit 8 in Drupal 9, drop support for PHPUnit 7, in this issue we change the signatures of the methods in concrete Drupal test code according to PHPUnit 8.

Proposed resolution

Change all the implementations of

• setUp()
• tearDown()
• setUpBeforeClass()
• assertPostConditions()

in concrete test classes to have a void return typehint.

We will then add a deprecation to inform developers of this change in #3111044: Deprecate setUp/tearDown concrete test methods that do not specify void return type

We cannot change abstract base test classes without breaking backward compatibility, so that will be done in a follow-up.

Remaining tasks

Patch.

User interface changes

API changes

Data model changes

Release notes snippet

Overridden test methods should have void return type hints added, see the change record at https://www.drupal.org/node/3114724 for more details.

Problem/Motivation

Currently there is no way, to add the playsinline or muted attributes on <video> elements being output by the new Drupal code Media module. The playsinline attribute is required for background video to work on iOS devices. (Note: a similar to the same issue filed on the file_entity project a few years ago – this one is specifically a reference to the core Drupal media entity and file formatter.)

Proposed resolution

Two new checkboxes should be added to the display options "plays inline" and "muted".

Remaining tasks

Patch is included, may needs some tests?

User interface changes

Adds two new checkboxes to the "Manage display" options for the media video type.

API changes

n/a

Data model changes

Adds playsinline to the media video schema.

Release notes snippet

Original report by chris_wearebraid

It would be excellent to add a playsinline option to media elements

I had an issue with twig after upgrading to 8.7.0-beta1

User warning: mkdir(): Permission Denied in Drupal\Component\PhpStorage\FileStorage->createDirectory() (line 174 of core/lib/Drupal/Component/PhpStorage/FileStorage.php).
Drupal\Component\PhpStorage\FileStorage->createDirectory('/tmp/twig', 511) (Line: 121)
Drupal\Component\PhpStorage\FileStorage->ensureDirectory('/tmp/twig') (Line: 66)
Drupal\Component\PhpStorage\MTimeProtectedFastFileStorage->save('5ca0b23c28013_status-messages.html.twig_3_7GEvvubFlSDBFsuJwHKQ4so', '<?php

I have the following in settings.php:

$settings['php_storage']['twig'] = array(
  'directory' => DRUPAL_ROOT . '/../.php',
);

This should change the twig cache dir, but it was still throwing the above error.

I also tried changing the default tmp dir in file system settings to no avail.

AccountForm::form() contains the following code.

  $form['#cache']['tags'] = $config->getCacheTags();
  $language_interface = \Drupal::languageManager()->getCurrentLanguage();

Instead of calling \Drupal::languageManager(), it should use its own $this->languageManager property, which is initialized from the class constructor.

public function __construct(EntityRepositoryInterface $entity_repository, LanguageManagerInterface $language_manager, EntityTypeBundleInfoInterface $entity_type_bundle_info = NULL, TimeInterface $time = NULL) {
  parent::__construct($entity_repository, $entity_type_bundle_info, $time);
  $this->languageManager = $language_manager;
}

There is code in the same method that uses $this->languageManager, so this seems a forgetfulness in one of the past commits.

  $form['language'] = [
    '#type' => $this->languageManager->isMultilingual() ? 'details' : 'container',
    '#title' => $this->t('Language settings'),
    '#open' => TRUE,
    // Display language selector when either creating a user on the admin
    // interface or editing a user account.
    '#access' => !$self_register,
  ];

Problem/Motivation

In \Drupal\Tests\Core\Extension\InfoParserUnitTest we have at least 8 test methods that do that same thing

1. Define a broken yml string
2. Set 2 yml files to use this exact same string
3. set an expected exception
4. parse file 1 and make sure the exception is expected
5. parse file 2 and make sure the exception is expected(only difference is file name)

Really these could all be 1 test method with dataprovider. Not all the current test methods do the double files but they would be better if they did.

Proposed resolution

Make a 1 test method testInfoException that has a dataprovider that covers all the cases by the current 8(or more) test methods.

This will the advantages of

1. Being easier to add and review new test cases
2. Make sure when we add test cases we don't forget anything like calling the parser 2x to make sure the static function doesn't affect the result(this happened originally)

Remaining tasks

Review, and Commit

User interface changes

API changes

Data model changes

Release notes snippet

Problem

Now that #2880152: Convert custom menu links to be revisionable is in, changes to menu links in non-live workspaces are not showing up. Making changes, and publishing changes from non-live to live works well. But it's not possible to preview the changes on the site's frontend.

This is probably due to cache issues where rendered menus needs to be cached per workspace.

Proposed solution

Cache menus per workspace.

API changes

None.

I can't seem to get the node title to show on a comment display here https://www.vegancheese.co/discover/reviews

So you can see the comment (a review) and its star ratings and everything is great, but I want to see what taht review relates to, what node it was made on for some context.

Dont know how to go about this, when I use display suite, I lose some fields and don't have as many options as standard/default comment display.

Do I have to use fields instead of DS display?

Problem/Motivation

After upgrading to 8.8, our tests started throwing exceptions in various places that weren't checking if $route_match->getRouteObject() returned NULL. One of those places is in layout_builder_system_breadcrumb_alter

I'm not entirely sure what changed between 8.7 and 8.8, but it seems to be to do with rendering content controlled by layout_builder outside of a route context, for example during search indexing.

See the full stack trace below:

1) Drupal\Tests\apra_publications_search\Functional\PublicationsSearchTest::testPublicationsSearch
Error: Call to a member function hasOption() on null

/data/app/core/modules/layout_builder/layout_builder.module:336
/data/app/core/lib/Drupal/Core/Extension/ModuleHandler.php:539
/data/app/core/lib/Drupal/Core/Breadcrumb/BreadcrumbManager.php:94
/data/app/core/modules/system/src/Plugin/Block/SystemBreadcrumbBlock.php:72
/data/app/core/modules/layout_builder/src/EventSubscriber/BlockComponentRenderArray.php:104
/data/app/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php:111
/data/app/core/modules/layout_builder/src/SectionComponent.php:90
/data/app/core/modules/layout_builder/src/Section.php:86
/data/app/core/modules/layout_builder/src/Entity/LayoutBuilderEntityViewDisplay.php:317
/data/app/core/modules/layout_builder/src/Entity/LayoutBuilderEntityViewDisplay.php:276
/data/app/core/lib/Drupal/Core/Entity/EntityViewBuilder.php:351
/data/app/core/modules/node/src/NodeViewBuilder.php:24
/data/app/core/lib/Drupal/Core/Entity/EntityViewBuilder.php:293
/data/app/core/lib/Drupal/Core/Entity/EntityViewBuilder.php:250
/data/app/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php:100
/data/app/core/lib/Drupal/Core/Render/Renderer.php:781
/data/app/core/lib/Drupal/Core/Render/Renderer.php:372
/data/app/core/lib/Drupal/Core/Render/Renderer.php:200
/data/app/core/lib/Drupal/Core/Render/Renderer.php:156
/data/app/core/lib/Drupal/Core/Render/Renderer.php:573
/data/app/core/lib/Drupal/Core/Render/Renderer.php:157
/data/app/modules/contrib/search_api/src/Plugin/search_api/processor/RenderedItem.php:276
/data/app/modules/contrib/search_api/src/Item/Item.php:272
/data/app/modules/contrib/search_api/src/Entity/Index.php:975
/data/app/modules/contrib/search_api/src/Utility/PostRequestIndexing.php:84
/data/app/modules/custom/apra_tests/tests/src/Functional/ApraTestBase.php:90
/data/app/modules/custom/apra_publications_search/tests/src/Functional/PublicationsSearchTest.php:33

Proposed resolution

Check $route_match->getRouteObject() is not NULL.

1- Site version was 8.7.9
2- Listed updatable modules at /admin/reports/updates/update
3- Updated 3 modules using the UI
4- Ran database update => modules showed as "Up to date" at /admin/reports/updates
5- Updated Drupal core to 8.8.3
6- Ran database update => Drupal core showed as "Up to date" at /admin/reports/updates
But all Modules and Themes show "No available releases found" as apposed to "Up to date"

Apache, PHP 7.1.14, MySQL 5.6.41

I have a multilingual site that uses content_moderation workflow and revisions. I came across an issue recently where If I create a node and leave it in review but then translate it, and publish the translation, I cannot delete the translation.

Steps to reproduce:

1. Create a site with three languages and enable content moderation
2. Create an article in the default language but do not publish it.
3. Create a translation of new article and publish it
4. Create a second translation of the article and publish it
5. Now try to delete the translations. They appear to delete but when you visit the translations page you will still see them marked as published. If you try to visit the translated pages you will get a 500 error as they entity has deleted the translation but the tables have not been updated. If you have created a single translation you will be able to delete the translation by clicking delete a second time. However if you have multiple publish translations on an unpublished node you will not be able to delete the translations

From what I can see, it all comes down to the entity after the translation is deleted is not being marked as a default_revision because it does not trigger any of the following in 'src/EntityOperations.php':

$update_default_revision = $entity->isNew()
      || $current_state->isDefaultRevisionState()
      || !$this->moderationInfo->isDefaultRevisionPublished($entity);

If I force $update_default_revision to be true the node deletes translations correctly. Is it correct to have a new default revision on every translation removal?

Expected Behavior

When I delete a translation I expect it to be removed from the list of available translations and to be redirected back to the default language translation which should be unpublished.

Actual Behavior

When I delete a translation I get redirected to a seemingly published version of unpublished default language article and translation still appears as published in translation list even though it has been removed from the entity.

Hi All,

I am working on Drupal 8.2.0-dev for website on linux server with MariaDB as database server. The site setup is based on 3 instances of website setup or file system using one database. Whenever updates are made to the site cache is cleared from all 3 instances / nodes for changes to work properly esp. twig template changes.

Here is more detail about site configuration on server :-

The website is actually a 3-node cluster behind a load balancer.
Each node (node1,node2 and node3) are part of a MariaDB Galera Cluster, and each node is hosting the Drupal website.
Each drupal website communicates with it’s own DB. So this means when node1 is serving a page, it is reading/writing to the DB on node1. Likewise, node2 read/writes to node2’s DB and so on.
The website files on main location are replicated between the nodes using lsyncd and csync2.

So, when a visitor hits the website, traffic flow is :
HTTP Traffic -> HAPROXY Load Balancer -> (one of the 3 Nodes)
a. Node1 website communication to MariaDB on node1 (localhost)
b. Node2 website communication to MariaDB on node2 (localhost)
c. Node3 website communication to MariaDB on node3 (localhost)

I face an error :-
1. While using drupal admin interface for making updates or inserts website admin often gets error below.
2. Wen cache is cleared using Drush on website on the frontend also.

Uncaught PHP Exception Drupal\\Core\\Database\\DatabaseExceptionWrapper: "SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: INSERT INTO {cache_entity} (cid, expire, created, tags, checksum, data, serialized) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6) ON DUPLICATE KEY UPDATE cid = VALUES(cid), expire = VALUES(expire), created = VALUES(created), tags = VALUES(tags), checksum = VALUES(checksum), data = VALUES(data), serialized = VALUES(serialized); Array, referer:

After searching on similar issues I found that solution suggested are using modules which are not ported to Drupal 8 yet e.g. https://www.drupal.org/project/apdqc. This issue was reported for Drupal 7 several times but not Drupal 8. I am not sure if its bug so adding support request.

Have not been able to find any reliable solution for this.

Just to add in my case the deadlock always is related to cache tables. Also can "Entity/field definitions" , " Mismatched entity and/or field definitions " as on page /admin/reports/status has any relation to this?

Any suggestions would be appreciated.

Thanks
Atul

Problem/Motivation

When using the dropdown lists in content overview or content types overview, I've noticed the dropbutton is only as wide as the first item (eg. 'edit') and when the list contains longer terms (eg. 'translate), the whole component becomes wider, which makes the cell wider and pushes content.

Proposed resolution

Implement this according to the design system which shows that the list width doesn't have to match with the width of the button:

Status with the latest patch

This is how it looks like with the latest patch reapplied after moving the theme to core. It doesn't jump anymore so seems to be solving the issue.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Discovered in #3063887: Support PHPUnit 8 in Drupal 9, drop support for PHPUnit 7.

Drupal\Tests\Traits\ExpectDeprecationTrait implements

protected function expectDeprecation($message)

This method has a name collision with a PHPUnit 8 method on PHPUnit\Framework\TestCase that has a different signature and a different purpose.

This will prevent future usage of PHPUnit 8.

Proposed resolution

• Rename expectDeprecation to something else: addExpectedDeprecationMessage
• Deprecate expectDeprecation
• Add/adjust tests

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In #3109534: Raise the minimum MySQL version to 5.7.8 and MariaDB version to 10.2.7 in Drupal 9, we raised the minimum MySQL version to 5.7 for Drupal 9.0. However, MySQL 5.6 isn't EOL until Feb. 2021. We should therefore make it possible for people to have a custom driver that allows MySQL 5.6, at least for a little while. At some point, possibly as early as Drupal 9.1, we might start using MySQL 5.7 features, such as JSON, that'll be hard for a 5.6 driver to implement. But even if a MySQL 5.6 custom driver is only functional for Drupal 9.0 (and not 9.1), Drupal 9.0 will be supported until after Feb. 2021, so even a trivial custom driver can get people past MySQL 5.6's EOL.

To a large extent, core already allows custom drivers to extend the core ones. Within settings.php, you can have:

$databases['default']['default'] = array (
  'namespace' => 'Drupal\\Driver\\Database\\mysql',
  'driver' => 'mysql',
  ...
);

which works as expected.

However, there are two places where the above namespace from the above connection info array is not checked:

1. In db_installer_object(), used by the installer before settings.php has been written.
2. In Database::convertDbUrlToConnectionInfo(), which can be called from places that only have a db URL and not a connection info array. In core, that's just tests and console commands.

In these two places, HEAD currently checks the core namespace first, and only checks the custom namespace for drivers that aren't in core. This would prevent, for example, a custom MySQL driver from being used during installation and tests.

Proposed resolution

Change the above two places to check for a driver in the custom namespace first, and then fall back to the core namespace.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Hello,

We are running a Drupal 8.6.2 multisite and users have been reporting over the last few weeks that the the contextual links are disappearing on them. When I investigate, the links appear for me as admin, but do not for the user.

I am getting this error in the WatchDogs:

Location http://site.com/contextual/render
Message Symfony\Component\HttpKernel\Exception\BadRequestHttpException: Invalid contextual ID specified. in Drupal\contextual\ContextualController->render() (line 76 of /core/modules/contextual/src/ContextualController.php).
Severity Error

Rebuilding the Drupal cache fixes the issue.

I'm just wondering how this is happening? it seems to be random.

Thanks!