I recently upgraded our Drupal install from 8.3.7 => 8.4.5. A major issue I am having is that any Twig templates with an attach_library call throws the below error:

LogicException: Render context is empty, because render() was called outside of a renderRoot() or renderPlain() call. Use renderPlain()/renderRoot() or #lazy_builder/#pre_render instead. in /vagrant/drupal-8.4.5/core/lib/Drupal/Core/Render/Renderer.php:241 [error]
Stack trace:
#0 /vagrant/drupal-8.4.5/core/lib/Drupal/Core/Render/Renderer.php(195): Drupal\Core\Render\Renderer->doRender(Array, false)
#1 /vagrant/drupal-8.4.5/core/lib/Drupal/Core/Template/TwigExtension.php(380): Drupal\Core\Render\Renderer->render(Array)
#2 /vagrant/drupal-8.4.5/sites/default/files/php/twig/5a9f160ada026_file-link.html.twig__xP4ZKUjMG1Br_4AamdWV9Fbb/MO6fCVev6wq08Go5uaIPMEZ5_r-uQk-YHGauA3DKccg.php(43): Drupal\Core\Template\TwigExtension->attachLibrary('classy/file')

This error is produced when running 'drush -d twigc'. The biggest issue with this is that this stops once it gets to this error. So when I make a change to a template and clear cache, that twig template renders empty on the page and I can never get it back again since the twig templates cannot be recompiled successfully. I have tested this with Drush 8 and Drush 9. Of course the 'twigc' command is only in Drush 9, I can still replicate this issue using Drush 8 when rebuilding cache. This errors is being thrown in core template files as well, not just installed modules or any custom stuff.

Replace the get('entity.manager') with get('entity_type.manager') in Action module.

The action.post_update.php file is wrongly named as "action.post_udate.php".

Problem/Motivation

Revisionable entities with custom layout override only track layout changes incidentally when an entity is saved via the entity's edit form. In order to provide full layout revisioning, we should check that the entity type's bundle is revisionable and whether or not a new revision should be created before calling entity save in the Section Storage object.

Proposed resolution

Section storage for the field should determine if the entity's bundle is RevisionableEntityBundleInterface and check shouldCreateNewRevision(). If this is "true" then a new revision should be set on the entity before saving.

Remaining tasks

Write a patch
Write tests
Convince people

User interface changes

No direct changes to the UI. Layout saves for entity override would prompt the creation of new revision which would display the entity's revision tab. That "ui change" is incidental and expected.

API changes

None

Data model changes

None

Problem/Motivation

Currently LB has a @todo, which when resolved would introduce dataloss and integrity issues with content revisions:

      if ($entity instanceof RevisionableInterface) {
        // If the parent entity will have a new revision create a new revision
        // of the block.
        // @todo Currently revisions are never created for the parent entity.
        //   This will be fixed in https://www.drupal.org/node/2937199.
        //   To work around this always make a revision when the parent entity
        //   is an instance of RevisionableInterface. After the issue is fixed
        //   only create a new revision if '$entity->isNewRevision()'.
        $new_revision = TRUE;
      }

Work is already underway to fix that in #2937199: Track Layout override revisions on entities which support revisioning. The patch that resolves the @todo goes completely green, despite the actual solution being problematic.

Proposed resolution

Resolve the @todo by removing it and proving with tests why it's actually a required component of the current revisioning model.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

SubformState doesn't work properly if the subform doesn't have #tree = TRUE. That's because without that, the subform's form values are the top of the values array, and SubformState::getValues() won't find them.

So if you do something like this:

  public function submitForm(array &$form, FormStateInterface $form_state) {
    $subform_state = SubformState::createForSubform($form['plugin_form'], $form, $form_state);
    $plugin->submitConfigurationForm($form['plugin_form'], $subform_state);

then the plugin's submitConfigurationForm() won't find the values it expects.

Given this is a requirement for SubformState to work properly, I think it should throw an exception in createForSubform() if $form is non-empty and doesn't have #tree set.

It needs to allow an empty array, because in buildForm() you typically do this:

      $form['plugin_form'] = [];
      $subform_state = SubformState::createForSubform($form['plugin_form'], $form, $form_state);
      $form['plugin_form'] = $action->buildConfigurationForm($form['plugin_form'], $subform_state);
      $form['plugin_form']['#tree'] = TRUE;

Not sure if it's a bug or it's just me. When the form has the #tree property set to FALSE to get rid of the tree structure, the getValues or getValue method returns nothing in the submit handler. In my case it's in the blockSubmit method. I was expecting a flat array of keys and values. When the #tree is set to TRUE, everything returns as expected in a tree structure.

What am I doing wrong? Or is this a bug?

Problem/Motivation

Realized when trying to drag blocks into a custom layout that some of my CSS classes cause havoc in the layout builder mode.

landing-banner.html.twig

{% if content %}
  <div{{ attributes.addClass('landing-banner') }}>
    {% if content.image %}
      <div{{ region_attributes.title.addClass('layout__region', 'landing-banner__image', 'extend–background') }}>
        {{ content.image }}
      </div>
    {% endif %}
    {% if content.title %}
      <div{{ region_attributes.title.addClass('layout__region', 'landing-banner__title') }}>
        {{ content.title }}
      </div>
    {% endif %}
  </div>
{% endif %}

Proposed resolution

Add a variable in_layout_builder or something using the routing context potentially to let the templates know where they are and they can remove/add classes as needed to fix this up.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

PHP 7 introduces (return and scalar parameter) type declarations. In #2928856: Adopt the PSR-12 standard for PHP7 return types once Drupal 8 drops PHP 5 support there is discussion going on about adopting the PSR-12 standard for using return type declarations. However, as noted by drunken monkey implementing type hints in existing code in any form would be a breaking change.

The problem comes down to the fact that introducing type-hints in code that is used will make PHP complain that the contract isn't properly implemented by extending objects (see example 1). Implementing the type hints ahead of time does not break but produces warning because the extending case may be stricter (so not drop-in compatible) than the extended object (see example 2).

Issue #2928856: Adopt the PSR-12 standard for PHP7 return types once Drupal 8 drops PHP 5 support talks about implementing type declarations for new code. However, this still leaves us with a large codebase where the power of strict typing is not yet used to catch bugs ahead of time. The issues mentioned above means that changes both ways will be considered BC breaking and will need to happen in a major update.

Introducing this in a major update will make the update experience more difficult because more code needs to be changed at the same time. However, this jump will have to be made at some point if we want to let Drupal take advantage of the benefits that type hints bring.

Examples

Example 1

Adding type-hints in code that is extended without adding code to those extensions is problematic.

class Base {
    public function foo(int $x) : array {
        return [];
    }
}

class Child extends Base {
    public function foo($x) {
        return ["array"];
    }
}

$c = new Child();

echo $c->foo("bar");

Produces:
Fatal error: Declaration of Child::foo($x) must be compatible with Base::foo(int $x): array in [...][...] on line 13

Example 2

The opposite is also sort-of true, introducing type hints when the extended object has not already done so produces warning.

class Base {
    public function foo($x) {
        return [];
    }
}

class Child extends Base {
    public function foo(string $x) : string {
        return "great " . $x;
    }
}

$c = new Child();

echo $c->foo("bar");

Warning: Declaration of Child::foo(string $x): string should be compatible with Base::foo($x) in [...][...] on line 13

Proposed Solution

One saving grace that we have is that our coding standards already tell us to use PHPDoc type declarations all over Drupal. This means that we could use (an improved version of) a tool such as https://github.com/dunglas/phpdoc-to-typehint. Building this tool means that it can be used to convert Drupal core (possibly in reviewable chunks as sub-tasks of this issue) as well as contrib modules. It can then also be used for any downstream dependencies that we utilise.

I believe now is a good time to open this discussion if we want to see whether this is a feasible "big bang" step for Drupal 9.0 or whether we can do this in Drupal 10.0 not too long after.

1. Install 8.7.1
2. Go to /admin/modules
3. Expand the Description for JSON:API

Notice there is no Version: 8.7.1 listed with the other requirements/details.

Adding "version: VERSION" to jsonapi.info.yml solves the problem.

Problem:

Using a contextual filter for taxonomy in a view. The 'Specify validation criteria' is enabled and 'Taxonomy term name' is selected. There are two vocabularies and only one of them is selected. There are two terms with the same name. When that name is used in the URL the filter fails Drupal\taxonomy\Plugin\views\argument_validator\TermName:77 because it finds two terms and one of those fails because it doesn't belong to the selected bundles.

Solution:

There are two ways to fix that - either return true if at least one of the terms succeeds in the validation (don't like that).
Or simply select only the terms from the vocabularies which are selected in the configuration.

Attached is the patch for the second one.

Hope this isn't a dupplicate - I tried searching for it but no luck.

I created a content type teaser display with layout builder (two column) and a View page to display the teasers ( Unformatted list ).
In Drupal 8.6.15 it displayed correctly, but after i upgraded to 8.7.1 i get

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

In the logs i get this message:

InvalidArgumentException: Invalid UUID "3e74246b-025b-47dd-8111-9f6d5dffde19" in Drupal\layout_builder\Section->getComponent() (line 177 of /.../web/core/modules/layout_builder/src/Section.php)

.

I have and PHP Notice every time I open node (not bundle) layout settings.

Notice: Undefined index: region in Drupal\field_layout\FieldLayoutBuilder->buildForm() (line 109 of core/modules/field_layout/src/FieldLayoutBuilder.php).

And stackstrace:

Drupal\field_layout\FieldLayoutBuilder->buildForm(Array, Object) (Line: 64)
field_layout_form_alter(Array, Object, 'node_page_layout_builder_form') (Line: 539)
Drupal\Core\Extension\ModuleHandler->alter('form', Array, Object, 'node_page_layout_builder_form') (Line: 835)
Drupal\Core\Form\FormBuilder->prepareForm('node_page_layout_builder_form', Array, Object) (Line: 29)
Drupal\webprofiler\Form\FormBuilderWrapper->prepareForm('node_page_layout_builder_form', Array, Object) (Line: 277)
Drupal\Core\Form\FormBuilder->buildForm('node_page_layout_builder_form', Object) (Line: 93)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 38)
Drupal\webprofiler\StackMiddleware\WebprofilerMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
require('/var/www/drupal/app/index.php') (Line: 4)

I just created new node type and enable layout builder for it. Then I created a node with layout override.

My env:

Installation profile: Minimal (minimal-8.7.1)
Database updates: Up to date
Entity/field definitions: Up to date
PHP: 7.2.13
It's not clean drupal setup.

This issue has a history starting in D6 #245990: HTTP request testing unreliable and may be undesirable

Problem/Motivation & Proposed resolution

(Note: this is the original summary)
Summary of Problem: Drupal's attempts to detect and report when a site cannot make outgoing HTTP requests do not always work correctly, and probably never will. The problem in Drupal is a result of the function system_check_http_request() reporting that the connection isn't working when it actually is. As a result dependent features, such as update status, aggregator, adding new feeds etc. fail and performance substantially slows (~30 seconds) on admin pages when it runs.

What to do about the check function system_check_http_request()
D8: Patch to remove system_check_http_request
- Suggest dependent contrib modules log to watchdog on fails
- Update function to delete drupal_http_request_fails variable addressed in issue#
D6/D7: Leave system_check_http_request for dependent modules
but patch to add a timeout to the drupal_http_request() call to improve performance

What to do about failed HTTP requests:
- D6/D7/D8: When drupal_http_request fails apply patch to log message to watchdog instead of using variable_set('drupal_http_request_fails')
- Need to address potential security issues related to logging urls with possible presence of passwords/tokens/etc.

Remaining tasks

7.x-dev
• Currently working on the backport to D7
• Consider the comments in #70 as part of the code review.
• Needs further discussion concerning the security implications of logging full URLs in D7.
  This issue should remain open while those discussions are on-going.

8.x-dev
• The patch from #46 was reviewed and tested (RTBC).
• The patch from #46 was commited in #58 here is the commit information (from 8.x repo)

User interface changes

None, but some additional watchdog error messages might appear in the system error log.

API changes

The function system_check_http_request() has been marked as deprecated but only in the Doxygen comments, the original code remains intact.

Related Issues

(Note: Intentionally not including closed/fixed issues and duplicates -- please see comments for those)
#1635882: Remove stale drupal_http_request_fails variable
#2012468: Add trusted roles recommendation to 'access site reports'

Problem/Motivation

1. The class is set to SplString which is a PECL only class. It simply doesn't exist. Try php --rc SplString.
2. Consequently, PublicStream::basePath can not be called with an argument because it's typehinted with a nonexisting class. It is not called indeed, only the doxygen suggests doing that.
3. The factory is set to app.root.factory:get which returns a string violating the Container::get contract where services return objects.

Proposed resolution

Actually find/write a class with __toString ...

Remaining tasks

User interface changes

API changes

Data model changes

I added my theme css using the following in the *.info.yml:

ckeditor_stylesheets:
  - css/style.css

While updating the css/style.css I found that my changes wasn't reflecting into the WYSIWYG editor. Watching at the html head of the editor iframe I found that my css file was include as follow:

<link type="text/css" rel="stylesheet" href="/my_project/docroot/themes/unepmap/css/style.css">

That is, the above isn't included with any cache busting as any of the other css includes!?...

Now, not sure what is supposed to do CKEDITOR.timestamp included in #2679903: CKEditor uses separate cache-busting query string from Drupal's but it doesn't seems to cover the the above...

Updated a small, simple, brochure site from 8.6.12 to 8.7.0.

composer update drupal/core webflo/drupal-core-require-dev --with-dependencies had no complaints.

update.php produced three identical notices:

Notice: Undefined index: #include_fallback in Drupal\Core\Render\Element\StatusMessages::generatePlaceholder() (line 59 of ... Core\Render\Element\StatusMessages.php)...

The site's few pages all look good.

I confess I'm learning to theme, but I don't know much about Core. I looked up that error and found it happens in a lot of PHP code. Is this a problem?

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the media module.

Proposed resolution

Take the information that is currently in the hook_help module overview section for this module, and make sure the information is in one or more Twig help files. Steps:

1. Find the hook_help() implementation function in the media.module file. For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module. So, read the help and figure out a good way to logically divide it up into tasks. Each task will need to be in its own topic.
4. See if some of these tasks are already documented in existing topics. Existing topics could be in one of the following directories:
   

   core/modules/help_topics/help_topics
   core/modules/media/help_topics
   core/help_topics
   

   Note that to see existing topics, if the patch for #2920309: Add experimental module for Help Topics is not in your testing environment yet (because it has not yet been committed or was committed after you did your git pull or git clone command), you will also need to apply that patch.

5. For each task that needs to be written up, either add it to an existing topic, or create a new Twig topic file (see examples in the above locations). New Twig templates should be created in this module's help_topics directory, or in the core area if the information spans several modules or if the information should be visible before the module is installed. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in Core), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module).
6. For new topics, file names must be media.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig . Also, attached to the parent issue there is a sample help topic Twig file that you can use as a template when making your patch (you will need to change the file name and extension and save it in the correct directory).
7. Do not just copy the text of the old module overview word-for-word. We don't want an overview of the module -- we want one or more topics that are task-centered, that would be useful for someone managing or building a Drupal site. If you need to explain a concept, put that in a separate section or sections within the related task topic, with headers like "What is/are...?" question, such as "What are actions?".
8. Add metadata to the top of the Twig topic (see examples) -- it will need to either be a top-level topic, or marked as "related" to an existing topic.
9. Make a patch file that adds/updates the Twig templates in Core. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).
b) Review the patch:

1. Apply the patch. (If the patch for #2920309: Add experimental module for Help Topics is not in your testing environment yet, you will also need to apply that patch).
2. Turn on the experimental Help Topics module in your site.
3. Review each topic that is created or modified in this patch. Make sure the text is clear and does not contain grammar/punctuation errors, and that the links within the text work and the instructions for tasks work. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/action/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Also verify that it is task-based help, and that concepts that need to be explained are in separate sections with "What is/are" questions as headers (such as "What is an action?").
5. Read the old "module overview" topic for the module, at admin/help/MODULENAME. Verify that all the tasks described in that overview are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

The taxonomy terms used in the Recipe Category vocabulary are all singular:

This is ok for tagging, but when that tag is used to generate a list page, the tag being singular is odd because we're listing things.

If we updated the terms in this vocabulary to be plural - Main Courses, Desserts etc, it would still make sense from a tagging point of view, but the listing pages would make more sense.

Proposed resolution

Update all the terms in this vocabulary to be plural.

Remaining tasks

All the things.

User interface changes

None.

API changes

None.

Data model changes

None.

Hi,

When I trying to update Drupal core to 8.7.0 using composer I am getting the following error.

$ composer require drupal/core:8.7.0 --update-with-dependencies

Your requirements could not be resolved to an installable set of packages.

Problem 1
- Can only install one of: egulias/email-validator[2.0.x-dev, 1.2.14].
- Can only install one of: egulias/email-validator[2.0.x-dev, 1.2.14].
- Can only install one of: egulias/email-validator[2.0.x-dev, 1.2.14].
- drupal/core 8.7.0 requires egulias/email-validator ^2.0 -> satisfiable by egulias/email-validator[2.0.x-dev].
- Installation request for drupal/core 8.7.0 -> satisfiable by drupal/core[8.7.0].
- Installation request for egulias/email-validator (locked at 1.2.14, required as ^1.2) -> satisfiable by egulias/email-validator[1.2.14].

When I try to update the egulias/email-validator[ package separately it shows:
$ composer require egulias/email-validator:2.0.1 --update-with-dependencies

Your requirements could not be resolved to an installable set of packages.

Problem 1
- Installation request for egulias/email-validator 2.0.1 -> satisfiable by egulias/email-validator[2.0.1].
- Can only install one of: egulias/email-validator[2.0.1, 1.2.x-dev].
- Installation request for egulias/email-validator ^1.2 -> satisfiable by egulias/email-validator[1.2.x-dev].

Drupal 8.6.15 reqquires email-validator with ^1.2 version and 8.7.0 requires ^2.0 email-validator.

Any solution? help please.