Call to a member function filters() on a non-object in core/modules/text/text.module on line 83

Can't reproduce within current dev

$ drush scr test.php 
$node = entity_create('node', array(
      'type' => 'article',
      'title' => 'test',
      'body' => array(
        'value' => md5(uniqid(rand(), true)),
        'format' => 'filtered_html',
      ),
      'uid' => 1,
    ));
    $node->save();

The same via devel/php
I see no notices. Node test successfully created.

I ran into the same issue while working on a site migration. The fatal error only appears when the content is rendered as it tries to call the filters() method on a non-existing config entity. Attached patch fixes the issue.

Usually, we do no support broken configuration like this but clean-up the config instead. However, in the special case of filter formats I think this support of broken configuration is pre-existing but got broken. There is even already a comment for this case, but the check fails.

Agreed, this needs tests also.

Testbot, go.

I just ran into this upgrading to Drupal 8.1. The solution turned out to be that the Typogrify module, which does not have a D8 version yet, needed to be completely uninstalled, not just disabled, in D7. So if anyone else is reading this issue because you've into this problem, make sure you uninstalled any modules that provide input filters that aren't available in D8.

Just experienced this during an upgrade, and #6 pointed me in the right direction. For me, the quick fix was to add a text format with the same machine name as a custom one added to the D7 donor site.

I confirmed that this error occurs. And the patch #2 works for me.

I created a simple test for this and would like someone to review it.

I've rerolled the patch, the issue is still actual in Drupal 8.4.x. When the filter is invalid, I have this error: Error: Call to a member function filters() on null in .../core/modules/text/text.module on line 84

I have tested this and I can confirm it is working and fixes the error.

1. +++ b/core/modules/text/tests/src/Kernel/TextSummaryTest.php
   @@ -208,6 +208,19 @@ public function testLength() {
   +  public function testInvalidFormatter() {
   

   The word formatter has a different meaning in Drupal. We're testing an invalid filter format, we should name the test method testInvalidFilterFormat

2. +++ b/core/modules/text/tests/src/Kernel/TextSummaryTest.php
   @@ -208,6 +208,19 @@ public function testLength() {
   +    $invalid_format = 'text_invalid';
   +
   +    $text = $this->randomString(100);
   +    $expected = '';
   

   I don't think we need inline variables here, so

   $this->assertTextSummary($this->randomString(100), '', 'text_invalid');

   would suffice.

   But I think we should name the invalid filter format 'non_existent_format' to better reflect what is being tested here.

3. +++ b/core/modules/text/text.module
   @@ -81,13 +81,14 @@ function text_summary($text, $format = NULL, $size = NULL) {
   +    $format_config = FilterFormat::load($format);
   ...
   +    if (!$format_config) {
   ...
   +    $filters = $format_config->filters();
   

   Sorry to be pedantic, but can we name this variable filter_format as that better reflects what we're working with?

fixed the nit picks as per #17

I agree with @fago in comment #2 that we normally wouldn't fix this, however the comment makes the code incorrect. So we should either fix it or remove the comment. Since the fix is trivial, and already here, I think we should fix it.

+++ b/core/modules/text/text.module
@@ -81,13 +81,14 @@ function text_summary($text, $format = NULL, $size = NULL) {
-    if (!$filters) {
+    if (!$filter_format) {

We're now changing the behaviour of this function.

Previously, if we found the format, but it had no configured filters, we returned ''. Now we only return '' if the format doesn't exist.

I note however that the comment indicates it was supposed to be checking for the format, not the presence of filters on the format. So it is likely that the existing behaviour is unintended.

However, I think we should reinstate the previous behaviour.

So make the code

if (!$filter_format || !($filters = $filter_format->filters()) {

We can then remove the $filters = line.

It is unlikely that someone was relying on this behaviour, but we can't be sure, so we should err on the side of caution.

Improved the patch

Hi harsha012,
I have tested with above patch, which has posted in comment #21. The node creates and node view working fine.
But I got following error on the reports.
"Missing text format: filtered_html_invalid."

Fixed typo in issue summary.

@sureshcj that error is not related to this patch, but is the expected behaviour.

Whilst we normally don't give credit for screenshots unrelated to the patch, it does demonstrate that effort was spent manually testing the patch, so I'm going to add credit for @sureshcj in this instance.

for more information please see https://www.drupal.org/core/maintainers/issue-credit

Committed as 72c76b7 and pushed to 8.5.x.

Leaving at RTBC on 8.4.x.

Will cherry-pick to 8.4.x tomorrow after commit freeze for 8.4.4 is over.

Cherry-picked 8baec3f and pushed to 8.4.x

As per https://www.drupal.org/core/release-cycle-overview#current-development-c... 8.4 is in 'critical fixes only', so I reverted this from 8.4