I am getting a stack trace when installing module to enable language translation

The steps to reproduce

in the search box on

http://dev.drupal.co.uk/admin/modules

type 'trans' this will bring up the tree module I want to install in one step

Configuration Translation
Content Translation
Interface Translation

selecting all three and pressing install, for me caused this stack trace ( See languageStackTrace.png )

Anyways here is the error, I am looking into this but I posting early just in case someone knows the answer.

[04-May-2016 11:47:19 Europe/Berlin] TypeError: Argument 1 passed to Drupal\language\LanguageNegotiator::updateConfiguration() must be of the type array, null given, called in /XXX/drupal/core/modules/language/language.module on line 320 in /XXX/drupal/core/modules/language/src/LanguageNegotiator.php on line 292

<nolink> and <none> are two routes provided by core that can be used to create empty links, without urls. This can be done through the menu system by creating a menu item with a link route:<nolink>.

However, because these urls are empty, Drupal currently considers these link to be going to the front page.
This means two things:

1. The links are generated with "data-drupal-link-system-path=<front>"
2. The links are generated with class="is-active" when on the homepage.

What is the expected behaviour? Nolinks should not contain either data-drupal-link-system-path or is-active on any page.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Problem/Motivation

Original discovered in #2380389-169: Use a single vendor directory in the root.

rebuild.php bypasses autoload.php and includes core/vendor/autoload.php directly.

Proposed resolution

Add test coverage for rebuild.php similar to \Drupal\system\Tests\Update\UpdateScriptTest.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

This is the Umami version of #2990776: Remove config-editing parts from standard_install() in favor of exported configuration.

demo_umami_install() manually updates various bits of configuration instead of shipping with proper configuration exports in config/install. This promotes a bad practice for other installation profile authors.

Proposed resolution

Remove all configuration updates in favor of exported configuration files.

I tried switching an Umami site to a right-to-left language (Hebrew) and it didn't look good.

Some issues visible in the screenshots below include:
1. The theming of the menu links near the top of the page is messed up.
2. The front page recipe content is missing (and the "No front page content has been created yet" message is displayed instead).

The first problem above seems to happen no matter what. The second only happened for me if I switched languages after installing in English (i.e., by manually enabling the core Language module and then going to admin/config/regional/language to add a new language and switch to it); if I installed from scratch in Hebrew, the front page content was shown correctly.

So this needs some investigation to figure out which parts of this are problems caused by Umami and which aren't.

Here is what the site looked like in a right-to-left language:

Image may be NSFW.
Clik here to view.

And here is what it looked like in English/left-to-right:

Image may be NSFW.
Clik here to view.

Problem/Motivation

Original report:
I migrated content from my D7 site to a D8 clean install following the handbook. I did not install any other module except from the one already present in the clean install.
If I enable layout builder the sites goes blank (front and admin), giving the following error:

The website encountered an unexpected error. Please try again later.
Error: Call to a member function getLabel() on null in Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver->getDerivativeDefinitions() (line 111 of core/modules/layout_builder/src/Plugin/Derivative/FieldBlockDeriver.php).

The FieldBlockDeriver iterates over the results of \Drupal\Core\Entity\EntityFieldManagerInterface::getFieldMap() and later retrieves corresponding definitions via \Drupal\Core\Entity\EntityFieldManagerInterface::getFieldDefinitions().
Every field listed in the field map should have a valid field definition, even more so because they are returned by the same service.
However, these two lists can get out of sync with each other under certain circumstances (migrations, bundle creation).

Fields, base fields, and extra fields are all cached using the entity_field_info tag as well as the entity_types tag.
The field map info is only cached by the entity_types tag.
The ::clearCachedFieldDefinitions() method in this service only clears the entity_field_info tag.

Additionally, while \Drupal\Core\Entity\EntityBundleListener::onBundleDelete() calls the ::clearCachedFieldDefinitions() method,
\Drupal\Core\Entity\EntityBundleListener::onBundleCreate() does not.

Proposed resolution

Cache the field map with the entity_field_info tag, to match everything else in this service, as well as the cache clearing method.
Add a call to \Drupal\Core\Entity\EntityFieldManagerInterface::clearCachedFieldDefinitions() in \Drupal\Core\Entity\EntityBundleListener::onBundleCreate().

Remaining tasks

N/A

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Fresh Drupal 8.5.x install. I've added a Media Video and I try to mute it in its display mode.
Unfortunately, the video is rendered without the attribute therefore, it's not muted.

How to reproduce
- Install Drupal 8.6.x
- Enable the Media module
- Create a Media Video type
- Edit the Display Mode and select the "Muted" attribute to YES.
- Create a new video and see it on front end.

Expected result
- On front, the video is muted.

Actual result
- On front, the video is NOT muted - muted attribute is not printed in the HTML markup.

I've attached a patch.
This is a quick fix.

Problem/Motivation

Follow up to #2949964: Add an EntityOwnerTrait to standardize the base field needed by EntityOwnerInterface.

Because of a bug in our test coverage, the Comment entity requires that the default owner is the anonymous user for the tests to pass. In order to provide better API and REST support for automatically associating the logged in user with created comments, we should ensure new comments are owned by the logged in user by default.

Proposed resolution

Delete getDefaultEntityOwner, which requires no deprecation because it was introduced at the start of the 8.7.x cycle and has never made it into a stable release.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

A created translatable content type added to the install config of a module or an install profile results in SQL error "Unknown column 'content_translation_source' in 'field list'" when attempting to add new content of that type.

Steps to replicate:
1. Create a content type with 'Enable translations' checked
2. Export content type as a feature
3. Add feature to install profile's info.yml dependencies along with language and content_translation modules
4. Install site profile
5. Log in, Add content of this type, Save

Error returned:

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

Drupal\Core\Entity\EntityStorageException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'content_translation_source' in 'field list': INSERT INTO {node_field_data} (nid, vid, type, langcode, title, uid, status, created, changed, promote, sticky, revision_translation_affected, default_langcode, content_translation_source, content_translation_outdated) 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, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14); Array ( [:db_insert_placeholder_0] => 2 [:db_insert_placeholder_1] => 2 [:db_insert_placeholder_2] => page [:db_insert_placeholder_3] => en [:db_insert_placeholder_4] => asdf [:db_insert_placeholder_5] => 1 [:db_insert_placeholder_6] => 0 [:db_insert_placeholder_7] => 1445445894 [:db_insert_placeholder_8] => 1445445901 [:db_insert_placeholder_9] => 0 [:db_insert_placeholder_10] => 0 [:db_insert_placeholder_11] => 1 [:db_insert_placeholder_12] => 1 [:db_insert_placeholder_13] => und [:db_insert_placeholder_14] => 0 ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 757 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Proposed resolution

Instead of manually creating/updating the content translation fields in a number of places (UI/Migration/Config Import) react to saving of the Content Language Settings config entity directly in content_translation.module. This both allows removing/consolidating code as well as covers the previously missing case of installation of module/profile config.

Problem

Using the module filter on the module list page a module can only be found by system name if the description ends in a dot. This is caused by the fact that jQuery's .text() method doesn't add any spaces. Therefore the Regex in Drupal.behaviors.tableFilterByText showModuleRow which uses word boundaries only recognizes the word if the description contains a period to end the sentence and make the machine name its own word.

This is why for example searching for "dblog" works currently but searching for "yoast" doesn't show the Real-Time SEO module in the 8.x-2.0-alpha3 release.

Proposed Solution

Make the showModuleRow slightly more elaborate by ensuring the values of the different possible search sources are separated by a space.

Problem/Motivation

In order to address #2937984-15: [meta] Symfony 4.0 compatibility

We should at least do the following:

1. Identify all the deprecated code that Drupal 8 relies on and update for it, opening issues for anything not straightforward

2. Have an issue with a patch that updates to Symfony 4 so we can see if it passes or not.

3. Potentially, relax our composer.json requirements to allow Symfony 4 to be installed, once the above two are done, if it's feasible to do so.

Proposed resolution

As a first step let's bump core dependencies to PHP 7.0.8.

Remaining tasks

Fix fails.
Fix BC issues.

User interface changes

None

API changes

Unknown

Data model changes

None

I'm trying to uninstall "Field Layout" but I'm having errors in my terminal :

www.s1biose.com@vps000000 ~/public_html $ drush pm-uninstall field_layout
 [error]  TypeError: Argument 1 passed to {closure}() must implement interface Drupal\field_layout\Display\EntityDisplayWithLayoutInterface, instance of Drupal\Core\Entity\Entity\EntityViewDisplay given in {closure}() (line 34 of /home/www.s1biose.com/public_html/web/core/modules/field_layout/field_layout.install) #0 [internal function]: {closure}(Object(Drupal\Core\Entity\Entity\EntityViewDisplay))
#1 /home/www.s1biose.com/public_html/web/core/modules/field_layout/field_layout.install(37): array_map(Object(Closure), Array)
#2 [internal function]: field_layout_uninstall()
#3 /home/www.s1biose.com/public_html/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(391): call_user_func_array('field_layout_un...', Array)
#4 /home/www.s1biose.com/public_html/web/core/lib/Drupal/Core/Extension/ModuleInstaller.php(403): Drupal\Core\Extension\ModuleHandler->invoke('field_layout', 'uninstall')
#5 /home/www.s1biose.com/public_html/web/core/lib/Drupal/Core/ProxyClass/Extension/ModuleInstaller.php(91): Drupal\Core\Extension\ModuleInstaller->uninstall(Array, true)
#6 /home/www.s1biose.com/public_html/vendor/drush/drush/src/Drupal/Commands/pm/PmCommands.php(106): Drupal\Core\ProxyClass\Extension\ModuleInstaller->uninstall(Array, true)
#7 [internal function]: Drush\Drupal\Commands\pm\PmCommands->uninstall(Array, Array)
#8 /home/www.s1biose.com/public_html/vendor/consolidation/annotated-command/src/CommandProcessor.php(235): call_user_func_array(Array, Array)
#9 /home/www.s1biose.com/public_html/vendor/consolidation/annotated-command/src/CommandProcessor.php(181): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
#10 /home/www.s1biose.com/public_html/vendor/consolidation/annotated-command/src/CommandProcessor.php(150): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#11 /home/www.s1biose.com/public_html/vendor/drush/drush/includes/annotationcommand_adapter.inc(242): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#12 /home/www.s1biose.com/public_html/vendor/drush/drush/includes/command.inc(196): annotationcommand_adapter_process_command('field_layout')
#13 /home/www.s1biose.com/public_html/vendor/drush/drush/src/Boot/BaseBoot.php(92): drush_dispatch(Array)
#14 /home/www.s1biose.com/public_html/vendor/drush/drush/includes/preflight.inc(80): Drush\Boot\BaseBoot->bootstrapAndDispatch()
#15 phar:///usr/local/bin/drush/bin/drush.php(159): drush_main()
#16 /usr/local/bin/drush(10): require('phar:///usr/loc...')
#17 {main}. 
TypeError: Argument 1 passed to {closure}() must implement interface Drupal\field_layout\Display\EntityDisplayWithLayoutInterface, instance of Drupal\Core\Entity\Entity\EntityViewDisplay given in /home/www.s1biose.com/public_html/web/core/modules/field_layout/field_layout.install on line 34 #0 [internal function]: {closure}(Object(Drupal\Core\Entity\Entity\EntityViewDisplay))
#1 /home/www.s1biose.com/public_html/web/core/modules/field_layout/field_layout.install(37): array_map(Object(Closure), Array)
#2 [internal function]: field_layout_uninstall()
#3 /home/www.s1biose.com/public_html/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(391): call_user_func_array('field_layout_un...', Array)
#4 /home/www.s1biose.com/public_html/web/core/lib/Drupal/Core/Extension/ModuleInstaller.php(403): Drupal\Core\Extension\ModuleHandler->invoke('field_layout', 'uninstall')
#5 /home/www.s1biose.com/public_html/web/core/lib/Drupal/Core/ProxyClass/Extension/ModuleInstaller.php(91): Drupal\Core\Extension\ModuleInstaller->uninstall(Array, true)
#6 /home/www.s1biose.com/public_html/vendor/drush/drush/src/Drupal/Commands/pm/PmCommands.php(106): Drupal\Core\ProxyClass\Extension\ModuleInstaller->uninstall(Array, true)
#7 [internal function]: Drush\Drupal\Commands\pm\PmCommands->uninstall(Array, Array)
#8 /home/www.s1biose.com/public_html/vendor/consolidation/annotated-command/src/CommandProcessor.php(235): call_user_func_array(Array, Array)
#9 /home/www.s1biose.com/public_html/vendor/consolidation/annotated-command/src/CommandProcessor.php(181): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
#10 /home/www.s1biose.com/public_html/vendor/consolidation/annotated-command/src/CommandProcessor.php(150): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#11 /home/www.s1biose.com/public_html/vendor/drush/drush/includes/annotationcommand_adapter.inc(242): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#12 /home/www.s1biose.com/public_html/vendor/drush/drush/includes/command.inc(196): annotationcommand_adapter_process_command('field_layout')
#13 /home/www.s1biose.com/public_html/vendor/drush/drush/src/Boot/BaseBoot.php(92): drush_dispatch(Array)
#14 /home/www.s1biose.com/public_html/vendor/drush/drush/includes/preflight.inc(80): Drush\Boot\BaseBoot->bootstrapAndDispatch()
#15 phar:///usr/local/bin/drush/bin/drush.php(159): drush_main()
#16 /usr/local/bin/drush(10): require('phar:///usr/loc...')
#17 {main}
TypeError: Argument 1 passed to {closure}() must implement interface Drupal\field_layout\Display\EntityDisplayWithLayoutInterface, instance of Drupal\Core\Entity\Entity\EntityViewDisplay given in {closure}() (line 34 of /home/www.s1biose.com/public_html/web/core/modules/field_layout/field_layout.install).
 [error]  Drush command terminated abnormally due to an unrecoverable error. 

When the layout_builder module is enabled, trying to view a term page crashes with:

Drupal\Component\Plugin\Exception\ContextException: Assigned contexts were not satisfied: entity in Drupal\Core\Plugin\Context\ContextHandler->applyContextMapping() (line 101 of /var/www/html/web/core/lib/Drupal/Core/Plugin/Context/ContextHandler.php).

Steps to reproduce

1. Activate layout_builder
2. Create a vocabulary and term
3. View the term page

Problem

The empty text "No content available" appears twice in the content view:

Image may be NSFW.
Clik here to view.

Steps to replicate:

1. Install the minimal profile.
2. Enable Views
3. Go to admin/content

Proposed resolution

Make sure it only appears once.

Remaining tasks

Repair. Test. Commit.

User interface changes

None.

API changes

None.

Data model changes

None.

Right now it is hard to get a real validation error but with #2948064: Layout Builder should support inline creation of Custom Blocks using entity serialization there is more chance to get validation error.

Problem/Motivation

The core migrate system needs a way to import things from CSV files.

Immediate use case is for the Umami Demo profile now in core in 8.6.x. The imported content is in CSV files and we have code to read it and create the relevant entries. Having migrate_source_csv in core would allow us to remove that code and use migrate instead.

See #2809635-37: Create experimental installation profile for where @larowlan suggested bring migrate_source_csv into core.

Other good reasons to have CSV as a migration source in core:

• "I use this constantly. I've seen it forked into the Contenta distro, and a few of my own projects (I just want the source plugin, not another module.) It'll also be vital to Commerce integrations as CSV is a common way to import data from an ERP." @mglaman (#4)
• "CSV format is the first format used by non technical professionnals who need to import data and to generate/edit those datas thanks to software they knew (MS Excel without mention it). It's also the easiest way to export data from many ERP and big solutions with datas." @GoZ (#5)
• "CSV is simply a really common used format and it would make migrate more usable by default for many usecases. One could say: Oh it is easy to parse CSV, but it turns out it is not. On top of that the module also doesn't load the entire CSV file upfront, but rather reads line by line. I think this makes it a good candidate also for bigger migrations out there." @dawehner (#14)
• "This would help the Out of the Box Initiative. Let's do it! Consider this my maintainer +1 :)" @phenaproxima (#18)

Proposed resolution

The migrate_source_csv module has a stable release (2.0), has been downloaded almost 100k times, and comes complete with tests. The contenta CMS has been using this for their migrations, too.

Rename the files/namespaces, and move it in, as-is, to the core migrate module.

Since this is a straight port from contrib, discussions about fetchers, etc. are postponed to follow-ups. See #16, #36 and #37 for some of the highlights of the discussion.

Follow-up: #2962091: Adopt fetchers/parsers logic for use by source csv plugin

Remaining tasks

1. Patch that renames files/namespaces and moves the contrib code into core Done.
2. Tests Done.
3. Word-smithing PHPDocs Done.
4. Decide if we're okay with a straight port (done), or if we need to hash out all the fetcher/parser stuff first, figure out the design, class names, avoid conflicts, possible BC hell, etc. Done. See comments #80 through #83. Punted to #2962091: Adopt fetchers/parsers logic for use by source csv plugin.
5. Finish cleaning up the docs and tests.

None.

User interface changes

None.

API changes

Adds a new migrate source plugin called "csv" in migration yml definition files. The class providing the plugin (\Drupal\migrate\Plugin\migrate\source\CSV) is heavily commented with PHPDoc.

Adds a \Drupal\migrate\CSVFileObject class (which extends \SplFileObject).

Existing users of this plugin from contrib are unharmed. The name is the same, but we haven't changed anything about how it works. Contrib users simply disable migrate_source_csv module before upgrading to core 8.X.Y and none of their migration files have to be changed to continue working.

Data model changes

None.

Original report by @smaz

In #2809635: Create experimental installation profile, we are using CSV files to provide default content for a demo installation profile of Drupal.

In a review, @larowlan suggested bringing the CSV migration sources into core:
https://www.drupal.org/project/drupal/issues/2809635#comment-12381619

I agree that a CSV migrate source would be a very useful feature for core.

The migrate_source_csv module has a stable release (2.0), has been downloaded almost 100k times (not sure if that includes composer stats?), and comes complete with tests. The contenta CMS has been using this for their migrations, too.

So would it be ok to look at moving this into Core's migrate module? If so, I'm happy to try and turn the module into a patch.

The ban module enables you to store single IP-addresses, from which any access of the website will be prevented.
In some cases spammers uses IP-ranges from where they spam contact forms. So it would be nice to have a comfortable opportunity to block IP-ranges or if the usage of wildcards would be supported.

Hi, I'm not sure if this is a core issue or a theme issue, but when you visit a page like anonymous user (after cache rebuild) where breadcrumb must not display any links, it's disappear from all pages.

This issue is not about that (and it's not a duplicate): https://www.drupal.org/node/2722093

We can avoid this issue excluding breadcrumbs-block from pages where breadcrumbs does not have any links.

Thanks.

Problem/Motivation

Right now each content entity type needs to define its set of permissions from scratch, then declare a matching access handler. This is pure boilerplate, an entity type's permissions can very precisely be guessed based on the interfaces it implements and the permission granularity it specifies. Furthermore, requiring each developer to create a new access handler each time leaves room for frequent bugs, such as wrong cacheability metadata.

Proposed resolution

The permissions currently vary based on two factors:

• EntityOwnerInterface
• Permission granularity (bundle / entity_type)

Future iterations of the patch / issue followups would also take into account EntityPublishedInterface.

Generated permissions:

• "administer $entity_type_id" (god mode permission)
• "access $entity_type_id overview" (the basic permission for listings)
• "view $entity_type_id" OR "view own $entity_type_id" / "view any $entity_type_id" depending on EntityOwnerInterface
• create/update/delete permissions per bundle or per entity type, also taking into account EntityOwnerInterface

Note that view permissions are never per-bundle cause we have no way to enforce it, we'd need query access for that (ala node access).

Just like we did for route providers, we introduce the concept of permission providers. That makes this generation opt-in.
Each participating entity type would define the core's permission provider, and the matching access handler. Core calls the permission provider of each entity type when building permissions.

The proposed solution was implemented in the Entity API contrib module (#2801031: Provide a generic entity access handler and permissions) and is used by Commerce and other contrib modules.

Remaining tasks

Roll the patch

I created a View of content revisions. We added a field to the view (a taxonomy reference in this case) and selected the "historical data" value (to show the revision value vs the current node value). We also added an Edit link for the node.

When displaying the view we get the following warning:

Warning: assert(): Tokens need to be valid Twig variables. failed in Drupal\views\Plugin\views\PluginBase->viewsTokenReplace() (line 371 of core/modules/views/src/Plugin/views/PluginBase.php).

When debugging this, we discovered the token it is complaining about is "field_category-revision_id". This is not a valid Twig variable because of the "-". In [#2548291] core changed usage of "-" to "__". However, Views still uses a "-" when adding "revision_id" to a field.

Tracked this down to core/modules/views/views.views.inc in views_field_default_views_data() (using 8.5.x core here):

    if ($type == EntityStorageInterface::FIELD_LOAD_CURRENT) {
      $group = $group_name;
      $field_alias = $field_name;
    }
    else {
      $group = t('@group (historical data)', ['@group' => $group_name]);
      $field_alias = $field_name . '-revision_id';
    }

This needs to be changed to "__revision_id" but not sure what else in core or contrib relies on this.