Hello,

Thanks for this wonderful module !

I was wondering if its possible to configure exposed operators.

Problem:
When we expose operator, all available operators are visible to users. I want only specified operators to be visible to users. For example, for a field_xyz I have following operators available:

• Is one of
• Is all of
• Is none of
• Is empty (NULL)
• Is not empty (NOT NULL)

I only want users to see follwings:

• Is one of
• Is all of
• Is none of

I don't want users to see NULL and NOT NULL operators.

It would be great if we have an option to do so.

Thanks in advance!

Problem/Motivation

While working on #2505283: Handle import of private files a number of faults were discovered in Drupal\Tests\file\Kernel\Migrate\d7\MigrateFileTest. These faults are being corrected for MigratePrivateFileTest in that ticket, but the same corrections should be applied to MigrateFileTest. These faults include (but not limited to):

• Use of \Drupal::service() rather than $this->container->get().
• Redundant register of public stream wrapper.

Proposed resolution

Wait for #2505283: Handle import of private files to be fixed and then copy any improvements into MigrateFileTest.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Even after we get the last couple i18n issues resolved, there are still many unknowns and areas for i18n could get improved. Rather than rushing and stating all i18n migrations are ready because we just need to get things out the door, let’s take off the pressure. Give us a little more time to do things properly. Having a separate marking module let’s us mark i18n stable when it is really more stable.

Proposed resolution

• Add a new migrate_drupal_i18n module
• In all i18n source plugins, add to the existing checkRequirements function a call to \Drupal::service(‘module_handler’)->moduleExists(‘migrate_drupal_i18n’).
• If the module doesn’t exist (i.e. it isn’t installed) then it fails requirements and will not be available for migrations.
• Then mark migrate_drupal_i18n as experimental. And mark migrate_drupal as stable.
• Profit

Remaining tasks

• Roll a patch.
• Discuss if this can land as Experimental into 8.5. That way we could mark migrate drupal and the UI as stable sooner.

User interface changes

API changes

Data model changes

With Firefox, the small expand/collaps triangles on collapsible fieldsets are not displayed:

It should look like this:

Hi there!

I experienced weird behaviour after upgrading our site from 8.4.2 to 8.5.1. I'm not sure what exactly caused this issue.
Also this issue could be connected to this issue - https://www.drupal.org/project/drupal/issues/2905295

Description.

I set up Drupal 8.4.2 site in English, then I enabled Ukrainian, which is set as default. I configured few views (pages and blocks) and added translations. View's pages have menus.

As it was recommended to upgrade Drupal because of security issue - https://www.drupal.org/SA-CORE-2018-002 - I decided to upgrade our site to 8.5.1.

After upgrade of Drupal core and translations, via Available translation updates page, I noticed that in English version of site menus which had been created through Views are shown in Ukrainian.
I opened /en/admin/structure/views page and noticed that most of the views titles and descriptions are shown in Ukrainian while interface language is English as seen from the path. It's worth to mention that not only those views I created shown in Ukrainian, some of the out of the box too, for example, Watchdog, who_s_online etc. But, for example, taxonomy_term, comments_recent and content_recent are shown in English.

I had to recover View's Administrative names, pages and blocks titles, and page's menus.

That's all for now.

Right now Drupal is unusable with filesystem (POSIX) ACLs. It's been broken for years. This was previously #944582: ./sites/default/files directory permission check is incorrect during install AND status report and #1333390: file_prepare_directory() / is_writable() on Linux don't support ACLs which are/were doomed to failure.

Steps to reproduce in Drupal 7 (change apache to your web server user):

1. Build a clean Drupal 7 development environment
2. In /sites/default:
   • mkdir files
   • chmod -R 700 files
   • setfacl -R -m user:apache:rwx files/
   • setfacl -Rd -m user:apache:rwx files/
3. Install Drupal
4. Do anything that calls file_prepare_directory('public://', FILE_CREATE_DIRECTORY). For instance, install the IMCE module and open its file browser from your "My Account" page.

Anything that calls file_prepare_directory('public://', FILE_CREATE_DIRECTORY) will fail, claiming that the directory (sites/default/files) is not writable.

Problem/Motivation

The install.php script and the "Reports > Status" Report both check for the files directory to have read/write permissions, but they should be checking for read/write/execute permissions instead.

This can cause various hard-to-troubleshoot permission-related errors with the files directory, including on Docker environments.

Steps to reproduce

• Drupal is already installed
• (goof up permissions) chmod 766 ./sites/default/files
• Click Reports > Status Report
• File System is green (should be red here, directory is not executable). No big deal yet
• Click on Configuration > Performance
• Click either Aggregate checkboxes under Bandwidth optimization or both
• Clear all caches
• You'll notice the CSS problem right away if that's what you selected to aggregate

Results

The specified file temporary://file6GnL0E could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.

Proposed resolution

Install.php and Reports > Status should check for read/write/execute permissions (x77) on the directory in question

Remaining tasks

• The patch needs to be rerolled for the latest version of Drupal 8.
• It is not possible to add a reliable automated test for this issue.

Related issues

• #484554-7: Stop relying on Apache for determining the current path

User interface changes

• None known.

API changes

Two functions will be added to the API:

• file_directory_is_writable($uri)
• drupal_is_executable($uri)

Original report by [mlehner616]

The install.php script checks for the files directory to have read/write permissions (x66), should be checking for read/write/execute instead (x77).
If the files directory is created with just read/write permissions, turning on caching/compression strips off CSS and displays errors regarding temporary files.

Install.php should check for this correctly, as well as the status report script.
Basically these two scripts don't care if execute permissions are set on ./sites/default/files

This may be a critical issue but I'll let someone more technical triage this one.
Tested multiple times and was able to reproduce this behavior:

Scenario 1

Drupal is already installed
(goof up permissions) chmod 766 ./sites/default/files
Click Reports > Status Report
File System is green (should be red here, directory is not executable). No big deal yet
Click on Configuration > Performance
Click either Aggregate checkboxes under Bandwidth optimization or both
Clear all caches
You'll notice the CSS problem right away if that's what you selected to aggregate

Here are the errors:
The specified file temporary://file6GnL0E could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
The specified file temporary://fileNY1O4m could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
The specified file temporary://fileSsnd94 could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
The specified file temporary://fileV3PZdN could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
The specified file temporary://fileSFTvjv could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
The specified file temporary://fileLB2jpd could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
The specified file temporary://fileSKgNvV could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
The specified file temporary://file1KkKCD could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
The specified file temporary://fileCHUVJl could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
The specified file temporary://fileNcdmR3 could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.

What's expected:
Install.php and Reports > Status Report should red flag the non-executable files directory (permissions must be 777)

Install.php actually does the same thing. It doesn't care that ./sites/default/files directory is 766 when it should be 777

I'm having a problem with my website after an update. Website is currently running DRUPAL 6, after an update from PHP 5.5 to PHP 7.1 I can't login with my admin credentials

Error Message: Sorry, unrecognized username or password. Have you forgotten your password?

I added a new role on a site and when I went to admin/config/development/configuration the new role's config was listed under the headline "removed", when in reality it's just not yet exported to code. A less confusing name would be good here – maybe "not exported to code".

Also the headline "changed" could be confusing to someone new to config synchronization. How about "changed since last export to code"?

In order to trigger this bug, you need to be importing config which contains a theme uninstall. In that case, the system.theme config object gets updated during the processExtensions sync step. This update gets tracked in ConfigImporter but the totalConfigurationToProcess property is not incremented. The net effect is that you successfully import config, but your last config change is not imported. If you import again, you will have one pending change and that runs successfully.

The attached patch increments totalConfigurationToProcess in this case so that the final config item gets imported on first try, as it should

This obscure bug was non-trivial to find.

Problem/Motivation

Date objects in Drupal are of type DrupalDateTime, which inherits from DateTimePlus, which is a wrapper around PHP's native DateTime class. Yet, sometimes we need to work directly with the DateTime object when dealing with libraries that expect DateTimeInterface.

For example, I'm working with datetime field data and the Recurr library, but I run into various problems when I the use field's DrupalDateTime object because it doesn't implement DateTimeInterface.

// DrupalDateTime object that doesn't implement DateTimeInterface.
$node->field_some_date_field[0]->date;

Unfortunately, there's no way to access the protected $dateTimeObject directly. Thus, I'd have to rebuild a new DateTime object from various pieces of the DateTimePlus object, and that's just sloppy.

Proposed resolution

I propose a simple DateTimePlus::getPhpDateTime() method to return the protected DateTime object.

// DateTime object that *does* implement DateTimeInterface.
$node->get('field_some_date_field')->date->getPhpDateTime();

Remaining tasks

• Agree on the method name #6 - #10
• Write patch #2 - #15
• Add tests #12
• Write change record #20
• Answering the question on #32, "Is there a reason we don't implement DateTimeInterface?" #42

User interface changes

None

API changes

New method DateTimePlus::getPhpDateTime()

Data model changes

None

Problem/Motivation

You cannot create a view and try to list rendered entities using relationship.

Steps to reproduce (based on Standard profile):

1. Add an entity reference field named "field_content" to the "page" content type. Allow content > article references.
2. Create and edit a content view.
3. Add a relationship for "Content using field_content." or "Content referenced from field_content."
4. The row style plugin is "Content" by default.
5. Click on "Teaser" in order to change the view mode, nothing happens.
6. You can't choose a view mode even if you don't want to actually use a relationship, just having one on your view triggers this.

The problem is a fatal AJAX error triggered when RowPluginBase::buildOptionsForm() calls RelationshipPluginBase::init() while providing a wrong argument type (Array instead of DisplayPluginBase).

Argument 2 passed to Drupal\views\Plugin\views\relationship\RelationshipPluginBase::init() must be an instance of Drupal\views\Plugin\views\display\DisplayPluginBase, array given, called in /app/web/core/modules/views/src/Plugin/views/row/RowPluginBase.php on line 93

Proposed resolution

Fix it, by passing along the relationship as needed and using it.

Remaining tasks

None.

User interface changes

None

API changes

None

Problem/Motivation

In Drupal 8, node translations are all stored in the same node as their default language node while in Drupal 6 & 7 they were stored in separate nodes. After a migration, entity reference field may now reference non-existent node translations, as show here:

Proposed resolution

Write a new deriver that will generate a migration for every entity bundle containing an entity reference field. These migrations will then update the entity reference field values with the new IDs found in the mapping tables using the migration_lookup process plugin.

Since those migrations need to be derived based on the migrated fields, we can't derived them at the same time as the other migrations since the fileds won't exists on the D8 site at that time. We need the migrations on which they depend to generate them after they have been succesfully executed.

Remaining tasks

Write the test and patch
Test it some more
Review it
Commit it!

User interface changes

N/A

API changes

New interface MigrationWithFollowUpInterface for migrations with follow-up migrations.

Data model changes

N/A

Problem/Motivation

The #2671964: ContextHandler cannot validate constraints introduced a new method called isSatisfiedBy(ContextInterface $context) which checks if given context satisfies context deifinition.

There is a following condition in this method:

    elseif ($definition instanceof static) {
      $values = $definition->getSampleValues();
    }

This condition fails if the ContextDefinition object is an instance of inherited class in which case it becomes:

    elseif ($definition instanceof SomeClassExtendingContextDefinition) {
      $values = $definition->getSampleValues();
    }

In a real life, the Rules module replaces context definition plugins with it's own, extending core.

Proposed resolution

The condition above should be checking 'instanceof self' instead of 'instanceof static'.

Remaining tasks

Review.

User interface changes

None.

API changes

None.

Data model changes

None.

I have a very simple functional test that checks if we can create a user and log in:

/**
 * Test login.
 */
public function testLogin() {
  $web_user = $this->drupalCreateUser();
  $this->drupalLogin($web_user);
}

This worked fine on 8.4.6 but after upgrading to 8.5.1 this fails with the following message:

1) Drupal\Tests\login_example\Functional\LoginExampleLoginTest::testLogin
User <em class="placeholder">sud6Y9W6</em> successfully logged in.
Failed asserting that false is true.

/var/www/html/docroot/core/tests/Drupal/KernelTests/AssertLegacyTrait.php:31
/var/www/html/docroot/core/tests/Drupal/Tests/BrowserTestBase.php:783
/var/www/html/docroot/modules/custom/login_example/tests/src/Functional/LoginExampleLoginTest.php:26

Another note of importance is that we're running this in a Docker setup with php:7.1-fpm and nginx:1.12. I tried the same code on php:7.1-apache and it worked there. This makes me unsure if it's nginx, php-fpm or Drupal that is the issue. But seeing as this worked on 8.4.x and not 8.5.x I'm guessing Drupal.

I have tracked it down to the GoutteDriver not having the cookie for the session ID, but not sure on how to debug it further.
To illustrate the problem and help others debug I have set up a repository with the example code:
https://bitbucket.org/johnzzon/login-example-nginx

Sincerely grateful for any help on this matter!

[Will enrich the ticket with proper description soon]

In core/modules/content_moderation/src/Entity/Handler/NodeModerationHandler.php, there is no check done if the node bundle is actually under workflow moderation or not and create new revision is forced. We need to have better check here to ensure we don't force this.

This issue is spun off from #2908282: Throw exception for source plugins without a source_module property.

Problem/Motivation

There are several implicitily required properties to destination, source and process plugins. Rather than waiting for someone to WSOD when they miss one of these implicit requirements, we should throw a loud exception.

The MigrateDestination annotation defines a destination_module property which needs to identify the system which will contain the processed, migrated data. In Migrate Drupal's case, this property is used to identify the D8 module which will "own" the migrated data.

When providing a strong API, it's important to tell consumers when they are doing something wrong. For Migrate Drupal's purposes (our main use case), this property is required in order to inform users whether their D6/D7 data will be migrated into Drupal 8. Therefore, this blocks the completion of the core migration path to Drupal 8, and is Migrate-critical.

Proposed resolution

• Port the destination-specific code from #2908282-53: Throw exception for source plugins without a source_module property into this issue
• Iterate on it until it's ready to commit. Consider inputs from:
  • #2908282-64: Throw exception for source plugins without a source_module property,
  • #2908282-65: Throw exception for source plugins without a source_module property&
  • #2908282-66: Throw exception for source plugins without a source_module property
  • Commit it.

  Remaining tasks

  That thing I just said.

  User interface changes

  None.

  API changes

  The destination_module property will be required on all Migrate destination plugins. So this constitutes a BC break.

  Data model changes

  None.

For now five times of drupal updates since last autumn I have to fix the same here described problem:
https://www.drupal.org/project/drupal/issues/2913971

with the patch
https://www.drupal.org/files/issues/entity-field-get-value-null-2913971-...

Is it possible to implement this patch into the next version of Drupal 8.5.1? The affected file is /core/modules/views/src/Plugin/views/field/EntityField.php

If I can help please tell me!
Thank You very much!

Follow-up to #2225681: Migrate D6 i18n blocks translated strings

Problem/Motivation

A migration for custom block (D6 boxes) translated strings is needed. The translations for the title and body of custom blocks is in the i18n strings module.

Proposed resolution

Write a custom source plugin. Note the translation for the title and body of custom blocks are on different rows in the locales_target source. The source plugin needs to keep track of what item is being translated on a row.
And, of course, tests.

Problem/Motivation

In Drupal 6, you can use the I18n Taxonomy module to translate a taxonomy vocabulary and taxonomy terms.

At this time, they cannot be migrated into Drupal 8. If you have a Drupal 6 site with this setup, you get the English terms migrated in, and the English name for the vocabulary, but the translations are not migrated.

Note that #2784371: Migrate D6 i18n taxonomy term language (but not yet translations) migrated term language, and #2225781: Migrate D6 i18n taxonomy vocabularies migrated vocabulary language, but neither of them migrated translations. Also, once this is done, we can look at also making sure the translated nodes get the translated taxonomy terms, on #2859297: Migrate d6 translated nodes with translated taxonomy.

Proposed resolution

Migrate taxonomy vocabulary and term translations.

Remaining tasks

User interface changes

API changes

Data model changes