Problem/Motivation

After upgrading my site from Drupal 8.9.20 to 9.3.2, I found that various views I'd created were reporting relationships as "broken/missing handler". These broken relationships all involved Paragraph entities, which make use of Entity Reference Revisions.

Several other people have reported a similar problem following a D8 to D9 upgrade. See here and here and here.

Steps to reproduce

I haven't tried to reproduce this problem from scratch.

Proposed resolution

Others who have come across this problem have said that the solution is to simply delete the broken relationship, and recreate it. Whilst this solution is effective, it is rather tedious and error prone, especially if you have lots of views, or your views have lots of fields which use the broken relationship - all will need to be created again. Instead, I looked for a better way.

Having deleted the broken relationship and re-created it in one of my views, I examined the exported config file to see what had actually changed. I found that the difference was trivial. In the original (broken) config file, the relationship referred to "field_XXXXX_target_id" or "field_XXXXX_target_revision_id", whereas in the fixed config file, the relationship is simply "field_XXXXX". (There was also a difference to the admin_label for the relationship, but that's purely cosmetic.)

So, it seems that in D9, views (in some circumstances) store relationships differently to the way they were stored in D8. I would have expected an update hook to modify the definition for D8 views to make them D9 compatible. Writing such a hook is beyond me, but I've found that views can be updated by applying some simple text edits to their config files. Here are the steps that worked for me.

  1. Find the details of the broken relationships: Go to the view edit page, open the Advanced section, and look under Relationships to see where it says "Broken/Missing handler". Click on that link and you'll get details of the relationship. Take a note of the id - it will be something like "field_XXXXX_target_id" (or possibly "field_XXXXX_target_revision_id")
  2. If your view has multiple broken relationships, get the id for each one. (Ignore any bits about "broken/missing handlers" on fields or filters or otherwise - these are all just implications of the broken relationship.)
  3. Edit the view config file: Use your favourite text editor to open the config file for the view, and do a search/replace for the broken relationships. Search for " field_XXXXX_target_id", and replace with " field_XXXXX". (Note: include a space in front of the id to avoid picking up partial string matches relating to something else.)
  4. Re-import the revised view definitions: drush cim.

I did find that one view was so badly broken that I wasnt able to open the view edit page for it (the site crashed with a white screen of death). In this case, I simply looked in the config file, found the "relationships" section, and from that got the ids of all the relationships. I made a guess at which were the broken ones, and edited the file as above. When I re-imported the definition, all was well.

Remaining tasks

It would be nice to have a database update hook that can make the necessary changes to the view definitions.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

Comments

dabley created an issue. See original summary.

cilefen’s picture

cilefen commented

If there are 2-3 other open issues why do we need another?

dabley’s picture

dabley commented

The other issues are different - although they share similar error messages.

2829178 and 3259439 are about broken filters, and the errors apply to views created within D9. The problem I'm covering in this issue only applies to problems arising when migrating from D8 to D9.

I created this issue because it relates to a different problem, and the solution I found might be helpful to others.

(The other page I referenced isn't an open issue, its just someone describing problems they had while upgrading to D9.)

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

sam.foster’s picture

sam.foster commented

@dabley,

I've just come across this whilst doing a D8 (8.9.2) to D9 (9.4.8) updgrade. The admin/content View I have has multiple additional filters and it seems that the View thinks the same field is referred to by each filter. If I remove all but one filter all is well. The multiple filters each refer to different taxonomies - in the original site - but in the D9 view each filter shows as referring to the same, first vocabulary used by the first filter.

I'm pretty sure that's why this is being thrown....

The website encountered an unexpected error. Please try again later.
TypeError: Drupal\Core\Render\Element::children(): Argument #1 ($elements) must be of type array, null given, called in /var/www/html/docroot/core/modules/views/src/Plugin/views/filter/FilterPluginBase.php on line 955 in Drupal\Core\Render\Element::children() (line 72 of core/lib/Drupal/Core/Render/Element.php).

I also get RED warnings like this popping up on others pages - might be related to this issue - and if anyone can help based on that info please do!

Warning: Undefined array key "value" in Drupal\views\Plugin\views\filter\FilterPluginBase->buildExposedForm() (line 940 of core/modules/views/src/Plugin/views/filter/FilterPluginBase.php).
Drupal\views\Plugin\views\filter\FilterPluginBase->buildExposedForm(Array, Object) (Line: 111)
Drupal\views\Form\ViewsExposedForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 531)
Drupal\Core\Form\FormBuilder->retrieveForm('views_exposed_form', Object) (Line: 278)
Drupal\Core\Form\FormBuilder->buildForm('\Drupal\views\Form\ViewsExposedForm', Object) (Line: 134)
Drupal\views\Plugin\views\exposed_form\ExposedFormPluginBase->renderExposedForm() (Line: 1241)
Drupal\views\ViewExecutable->build() (Line: 392)
Drupal\views\Plugin\views\display\PathPluginBase->execute() (Line: 196)
Drupal\views\Plugin\views\display\Page->execute() (Line: 1633)
Drupal\views\ViewExecutable->executeDisplay('page_2', Array) (Line: 81)
Drupal\views\Element\View::preRenderViewElement(Array)
call_user_func_array(Array, Array) (Line: 101)
Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #pre_render callbacks must be methods of a class that implements \Drupal\Core\Security\TrustedCallbackInterface or be an anonymous function. The callback was %s. See https://www.drupal.org/node/2966725', 'exception', 'Drupal\Core\Render\Element\RenderCallbackInterface') (Line: 772)
Drupal\Core\Render\Renderer->doCallback('#pre_render', Array, Array) (Line: 363)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 241)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 564)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 242)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 132)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 164)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 709)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Here's a shout out into the darkness to see if anyone (including perhaps you) have come across this same error and have any magical fixes I could apply. I'm happy to edit the view config yaml file if that's the easiest. I really hope I don't need to edit the View manually. patly this is because I have a large number of other such Views and I don't want to have to fix them all in the GUI in some tedious way!

Thanks in advance

Sam (in rainy Wales, UK)

dabley’s picture

dabley commented

Sam,
Sorry to hear you're having trouble. Your problem looks different to mine - it relates to filters rather than relationships, and you're getting different error messages. You could try a similar fault-finding approach to the one I used, though. Try editing one of the views, remove all the filters, and then put them back again. Does it work properly now? Export the config, and check the differences with the original config. If you can easily spot the config file differences, then you can probably work out how to edit the config files of all your views to get them to work properly.
David

sam.foster’s picture

sam.foster commented

Dear all

Just by means of closure...I didn't find a code based solution to my problem. I ended up editing the Views themselves. It seemed that during the upgrade the Views that used taxonomy terms (usually exposed as filters) had got confused over which taxonomy they were supposed to refer to - I changed each one to refer to what it was supposed to refer to (manually using the Views GUI) and that fixed the issue.

Maybe one day I'll stuble on the root cause/fix - but not today....

Sam

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.