Problem/Motivation

The help system needs search capability.

Proposed resolution

Probably, using the existing Drupal core Search module to build the search functionality would make the most sense.

Remaining tasks

a) Implement search indexing and searching, using the core Search module. The latest patch (#29) has this working, with some @todo items in the patch. Also, once it's finalized, we'll need to update its hook_help, and also add a Help Topic for it.

b) Add a search box to the main Help page, and possibly to each individual help topic page. Problem: This uses core Search and SearchPage config entities, meaning that the URL for searching is configurable, besides which a site builder can delete the help search page that this module provides. So... how to provide a search form, if we don't know whether a search page even exists? The core Search module only provides a block that searches the default search page... Probably the solution is to add a feature to core Search that would provide blocks attached to each search page (kind of like Menu does with blocks associated with each Menu). Then a site builder could add that block to any page. Probably need to spin this off to a separate issue. Then come back and provide default config that gives you this block on the admin/help page.

c) We discussed having a keyword functionality -- a field added to the HelpTopic plugin that would define keywords that could be emphasized in the search, but decided that would not be part of this patch.

d) Write a test. Things to test:
- If you install with Standard profile, you get the search block present on the help page.
- Search works for some keywords. Probably best to use the test module HelpSection plugin for that.
- Search permissions -- both the overall permission and the one that is used for a given help section. The existing help tests verify this with a section that has permissions, so we could make that HelpSection plugin searchable for further testing.
- Internationalization of search -- again with that test plugin... the HelpSection plugins have control over how to render items for indexing/results in a given language, so it would not be too hard to fake the internationalization bit in the test.
- Also add tests in the Help Topics module that verify that searching works with Help Topics in particular, and the internationalization of search works for Help Topics. But best to have the main tests independent of Help Topics I think?

User interface changes

Help topics provided by the Help Topics module will be searchable.

API changes

No.

Data model changes

None.

Original summary

It seems like a search feature or an index would be useful for the help topics system.

Search: could use core Search and index each topic's full text. It could also include hook_help() topics. The search could appear on the admin/help page as a "section".

Index: Could have a way to add index entries to each topic, and there could be an automatically-generated index that would be built during a cron job, which would list the index entries with links to the topics.

So this issue:
a) Decide on what feature(s) to add.
b) Build them.

Release notes snippet

To be determined, once we get the blocks sorted out.

Problem

Imported po files are treated as regular files, and so appear at admin/content/files. When they listed there they have a link, even though they do not have a public URL -by design. Clicking their link gives:

LogicException: PO files URL should not be public. in Drupal\locale\StreamWrapper\TranslationsStream->getExternalUrl() (line 55 of core/modules/locale/src/StreamWrapper/TranslationsStream.php).

file_create_url('translations://en.po')
Drupal\file\Plugin\views\field\File->renderLink('en.po', Object)

Solutions

1. Filter them out in the view, or
2. Soften the error, maybe returning an empty string instead of an Exception.

I was recently looking to modify the form for a content block entity that's placed as an inline block via Layout Builder.

This turns out to be quite difficult:

• The outer most form is either \Drupal\layout_builder\Form\AddBlockForm or \Drupal\layout_builder\Form\UpdateBlockForm, so that's what needs to be form_altered()
• Layout Builder's block form works similarly to core's \Drupal\block\BlockForm, in that it embeds configuration form for the block plugin inside of it. I guess this is called a "subform".
• For inline blocks in layout builder, there's a block plugin class \Drupal\layout_builder\Plugin\Block\InlineBlock. The configuration form for this block plugin is created by building an entity form display for the content block entity that you're trying to create. It does this in a #process callback

Because the actual block content entity form is rendered in a #process callback, a developer that implements a form_alter for layout builder will have a bad time, since the form elements for the block content entity are not actually built yet. Here's what the form array looks like in the form_alter:

Instead, I believe the developer must alter the form to add their own #process callback. And it cannot be added to the outer form array because it's still too early there. It needs to be added to the block_form, after the processBlockForm callback is done.

I wonder if there's a way to improve the developer experience here.

Under Drupal 8.6.5, after installing the module Field Layout, the filter function 'without' in the templates for my paragraphs, for example, is ignored. Once uninstalled the filter works fine again.

For example, if I put this in the twig template for a certain paragraph:

{{ content|without('field_label') }}

The field label is shown when the Field Layout module is installed.

Hi,

I am receiving the following error when adding new languages:
"Call to a member function set Weight() on null in Drupal\language\Configurable LanguageManager->updateLockedLanguageWeights()"

Drupal version 8.6.10.
PHP version 7.1

Steps to reproduce:
1. Enable translation modules
2. Add a new language. After a few second I'm receiving an error.
3. Language files do not get downloaded.

Related issue on 8.5.x - https://www.drupal.org/project/drupal/issues/3002532

Thanks,
Bez

Problem

After upgrading a site from Drupal Core 8.6.16 to 8.7.3 using composer, when taking the repo and reinstalling the Drupal installation, these errors are thrown:

TypeError: Argument 2 passed to Drupal\Core\Entity\ContentEntityStorageBase::onFieldDefinitionUpdate() must implement interface Drupal\Core\Field\FieldDefinitionInterface, null given, called in /home/vagrant/docroot/docroot/core/lib/Drupal/Core/Field/Entity/BaseFieldOverride.php on line 207 in /home/vagrant/docroot/docroot/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php on line 463 #0 /home/vagrant/docroot/docroot/core/lib/Drupal/Core/Field/Entity/BaseFieldOverride.php(207): Drupal\Core\Entity\ContentEntityStorageBase->onFieldDefinitionUpdate(Object(Drupal\Core\Field\Entity\BaseFieldOverride), NULL)
#1 /home/vagrant/docroot/docroot/core/lib/Drupal/Core/Entity/EntityStorageBase.php(491): Drupal\Core\Field\Entity\BaseFieldOverride->preSave(Object(Drupal\Core\Field\BaseFieldOverrideStorage))
#2 /home/vagrant/docroot/docroot/core/lib/Drupal/Core/Entity/EntityStorageBase.php(446): Drupal\Core\Entity\EntityStorageBase->doPreSave(Object(Drupal\Core\Field\Entity\BaseFieldOverride))
#3 /home/vagrant/docroot/docroot/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(263): Drupal\Core\Entity\EntityStorageBase->save(Object(Drupal\Core\Field\Entity\BaseFieldOverride))
#4 /home/vagrant/docroot/docroot/core/lib/Drupal/Core/Entity/EntityBase.php(394): Drupal\Core\Config\Entity\ConfigEntityStorage->save(Object(Drupal\Core\Field\Entity\BaseFieldOverride))
#5 /home/vagrant/docroot/docroot/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php(613): Drupal\Core\Entity\EntityBase->save()
#6 /home/vagrant/docroot/docroot/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(364): Drupal\Core\Config\Entity\ConfigEntityBase->save()
#7 /home/vagrant/docroot/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php(979): Drupal\Core\Config\Entity\ConfigEntityStorage->importCreate('core.base_field...', Object(Drupal\Core\Config\Config), Object(Drupal\Core\Config\Config))
#8 /home/vagrant/docroot/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php(765): Drupal\Core\Config\ConfigImporter->importInvokeOwner('', 'create', 'core.base_field...')
#9 /home/vagrant/docroot/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php(592): Drupal\Core\Config\ConfigImporter->processConfiguration('', 'create', 'core.base_field...')
#10 /home/vagrant/docroot/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php(496): Drupal\Core\Config\ConfigImporter->processConfigurations(Array)
#11 /home/vagrant/docroot/docroot/core/lib/Drupal/Core/Config/Importer/ConfigImporterBatch.php(30): Drupal\Core\Config\ConfigImporter->doSyncStep('processConfigur...', Array)
#12 /home/vagrant/docroot/docroot/core/includes/batch.inc(295): Drupal\Core\Config\Importer\ConfigImporterBatch::process(Object(Drupal\Core\Config\ConfigImporter), 'processConfigur...', Array)
#13 /home/vagrant/docroot/docroot/core/includes/form.inc(893): _batch_process()
#14 /home/vagrant/docroot/docroot/core/includes/install.core.inc(665): batch_process(Object(Drupal\Core\Url), Object(Drupal\Core\Url))
#15 /home/vagrant/docroot/docroot/core/includes/install.core.inc(583): install_run_task(Array, Array)
#16 /home/vagrant/docroot/docroot/core/includes/install.core.inc(118): install_run_tasks(Array, NULL)
#17 /home/vagrant/docroot/vendor/drush/drush/includes/drush.inc(727): install_drupal(Object(Composer\Autoload\ClassLoader), Array)
#18 /home/vagrant/docroot/vendor/drush/drush/includes/drush.inc(712): drush_call_user_func_array('install_drupal', Array)
#19 /home/vagrant/docroot/vendor/drush/drush/commands/core/drupal/site_install.inc(82): drush_op('install_drupal', Object(Composer\Autoload\ClassLoader), Array)
#20 /home/vagrant/docroot/vendor/drush/drush/commands/core/site_install.drush.inc(271): drush_core_site_install_version('cas', Array)
#21 /home/vagrant/docroot/vendor/drush/drush/includes/command.inc(422): drush_core_site_install('cas')
#22 /home/vagrant/docroot/vendor/drush/drush/includes/command.inc(231): _drush_invoke_hooks(Array, Array)
#23 /home/vagrant/docroot/vendor/drush/drush/includes/command.inc(199): drush_command('cas')
#24 /home/vagrant/docroot/vendor/drush/drush/lib/Drush/Boot/BaseBoot.php(67): drush_dispatch(Array)
#25 /home/vagrant/docroot/vendor/drush/drush/includes/preflight.inc(66): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#26 /home/vagrant/docroot/vendor/drush/drush/drush.php(12): drush_main()
#27 {main}
TypeError: Argument 2 passed to Drupal\Core\Entity\ContentEntityStorageBase::onFieldDefinitionUpdate() must implement interface Drupal\Core\Field\FieldDefinitionInterface, null given, called in /home/vagrant/docroot/docroot/core/lib/Drupal/Core/Field/Entity/BaseFieldOverride.php on line 207 in Drupal\Core\Entity\ContentEntityStorageBase->onFieldDefinitionUpdate() (line 463 of /home/vagrant/docroot/docroot/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php).
Drush command terminated abnormally due to an unrecoverable error.

The existing site works correctly with updated core, but any new builds do not work.

There are LOTS of bug reports in contrib for this crash in the translation system:

> Call to a member function getPath() on null in /core/modules/config_translation/src/ConfigNamesMapper.php on line 233

It's really easy to cause this if you don't set your entity type up properly. One way to do it is to define the 'field_ui_base_route' annotation property on an entity type, but not actually define the route elsewhere.

Adding a check to ConfigNamesMapper that the route exists and throwing an exception if it doesn't would be a big help to developers who hit this error, as currently it's really confusing and doesn't give you any indication of what's wrong. An exception that says which route name could not be found tells developers exactly where the problem is.

Problem/Motivation

There are many cases where running the database updates can be problematic with warm caches. #3052971: Notice: Undefined index: #include_fallback in Drupal\Core\Render\Element\StatusMessages::generatePlaceholder() is just a very recent example.

Proposed resolution

Decorate the cache_factory with a special update cache factory that uses memory based backend. The special update memory backend passes on deletes to the real backend so cache flushes occur as expected so once updates are not being done the caches are empty as expected.

Maybe a better fix would be to somehow swap back to the unmodified container - ie. one without UpdateServiceProvider prior to calling drupal_flush_all_caches(). The problemswith this are:

• How to determine this in UpdateKernel - use a query parameter?
• drupal_flush_all_caches() does a container rebuild so we’re going to end up with multiples of these.

Remaining tasks

Discuss/review.

User interface changes

Nope.

API changes

TBD.

Data model changes

Nope.

Release notes snippet

TBD.

Tentatively opening as bug report but might also be a support request to get direction for debugging in Markup module.

Problem/Motivation

A markup field does not show on nodes with layout builder enabled. It does show in the Layout Builder form, but not on the node view. The markup module Maintainer spent quite some time on debugging and couldn't find an error in the module.

Steps to reproduce:

- Set up a markup field on article content type, add some text to it
- Enable layout builder for article view mode default
- Open lb and see the markup field is rendered
- Create an article node
- See that on node view, the markup field is not being rendered

Proposed resolution

Let the field appear on node view.

Problem/Motivation

Making this a bug in the test helper trait as it is pretty useless like this now as phpunit fails on the first message:

this part:

    if (!$match) {
      debug('Unwanted cache contexts in response: ' . implode(',', array_diff($actual_contexts, $expected_contexts)));
      debug('Missing cache contexts in response: ' . implode(',', array_diff($expected_contexts, $actual_contexts)));
    }

    $this->assertIdentical($actual_contexts, $expected_contexts, $message);

The problem is that phpunit fails on the first error, which includes debug messages, and especially if the problem is *missing* cache contexts, then you only see the first useless message.

Proposed resolution

Just drop that debug stuff, phpunit shows a nice diff in case of assertIdentical() mismatches.

While we're at it, we should however also revert expected/actual so that the diff order makes sense.

Remaining tasks

User interface changes

API changes

Data model changes

drupal_realpath() was deprecated prior to the formal deprecation policy. We need to add a trigger_error() and a deprecation test.

Problem/Motivation

#2168333: Ensure custom EntityType controllers can be provided by modules introduced EntityHandlerBase (then EntityControllerBase) with an @todo to convert it to a trait. Since it was introduced, 2/3 of the class has already been replaced by traits, and all it does now is store a module handler dependency for the entity handler.

Originally we tried to do this deprecation but it ended up with more code and more deprecations. The main argument for removing the base class is:

the base class is a layer of misdirection we don't need, since it does not implement, nor reference, nor remotely resemble EntityHandlerInterface

However, @Berdir points out:

the gain from removing this is not really worth the effort and time that was already spent and would still need to be spent. It doesn't actually help us (enough) with our technical dept or complexity or so.

Proposed resolution

Remove the deprecation and revisit when we have a better plan.

Remaining tasks

User interface changes

None

API changes

EntityHandlerBase is undeprecated.

Release notes snippet

N/a

Problem/Motivation

#2403229: language.negotiation configuration can have overrides bleed in deprecated language_negotiation_url_prefixes() and language_negotiation_url_domains() before deprecation testing was a thing and it never removed all the usages.

Proposed resolution

• Remove all usages
• Add @trigger_error

No tests added because - the only existing usages are in tests and the functions are 1-liners with no logic.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/a

Problem/Motivation

#2724941: Need to be able to lookup destination IDs by partial source IDs deprecated \Drupal\migrate\Plugin\MigrateIdMapInterface::lookupDestinationId() before deprecation testing was a thing and it never removed all the usages.

Proposed resolution

• Remove all usages
• Add @trigger_error
• Think about testing

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/a

Problem/Motivation

Those two methods were not properly deprecated in #2916018: Allow the table mapping to be initialized from outside the storage (i.e. without a trigger_warning()), and further discussion brought up that they should me marked as internal instead.

Proposed resolution

Do it.

Remaining tasks

Review.

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope.

Release notes snippet

Nope.

Problem/Motivation

Preparation for Drupal 9

Proposed resolution

Properly deprecate the method

Remaining tasks

- replace usages;
- add CR;
- add legacy tests;

User interface changes

-

API changes

-

Data model changes

-

Release notes snippet

Problem/Motivation

LinkGeneratorTrait is deprecated but we still use it.

Proposed resolution

Add @trigger to the trait and it's methods and replace usages.

Remaining tasks

User interface changes

none

API changes

none

Data model changes

none

Release notes snippet

N/a

Followup to #2760883: API docs reference ModuleHandler::install() instead of ModuleInstaller

Problem/Motivation

In #2465887: Extract the install/uninstall functionality to a ThemeInstaller responsibility of [un]install of themes moved to theme_installer service but no CR filed and deprecated methods still used in core

Proposed resolution

Replace all usages of ThemeHandlerInterface::uninstall() and ThemeHandlerInterface::install() and trigger a silenced error.

Remaining tasks

patch, review & commit

User interface changes

None

API changes

None

Data model changes

None

Problem/Motivation

The test was deprecated in 8.4 in preference to \Drupal\Tests\migrate_drupal_ui\Functional\MigrateUpgradeTestBase. See
#2867304: Convert web tests to browser tests for migrate_drupal_ui module.

Proposed resolution

Remove it

Problem/Motivation

During the installation of Drupal we rebuilding and invalidate the caches a lot. This does a lot of queries on the database.

Proposed resolution

Use the MemoryBackend during installation - which results in the following comparison of installing standard via drush: https://blackfire.io/profiles/compare/9d742dcd-4160-45c2-96a9-09d2c5b56f...

Also during the interactive installer we are over 1.5 secs quicker and make at least one less query during the install. See #20 and #21.

The query count is also instructive - for a standard installer without this patch we do 17723 queries - with this patch we do 10733 queries.

Remaining tasks

User interface changes

None

API changes

CacheFactory gets a new boolean injected to determine whether or not drupal is installing.

Data model changes

None

Original issue summary

From comment #2294569-18: Determine cause of high memory consumption:

Performance wise I will open an issue to disable all caches during installation - this brings down to the time to install standard.profile from 35s to 9s.

Doing so! :)