Problem/Motivation

There is a method on ViewExecutable called getMenuLinks(). Its supposed to return menu links provided for the view, but technically this just doesn't make any sense, because
it always depends on the current display, and its not the responsiblity of the view executable to deal with it.

This is also only used ONCE in \Drupal\views\Plugin\Derivative\ViewsMenuLink.

Proposed resolution

Remove the function and instead use the existing methods on the display plugins directly.

Remaining tasks

- Move getMenuLinks from DisplayPluginInterface to DisplayRouterInterface, or a new one?
- Remove ViewExecutable::getMenuLinks

User interface changes

API changes

You can't no longer call getMenuLinks() on every display, but it never made really sense.
Additional new interface DisplayMenuInterface

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue category Task, because it fixes a stupid API and makes things sane
Issue priority Normal, because the impact is not high
Disruption No disruption, because noone will call that method anyway in contrib
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

damiankloip’s picture

Issue summary: View changes
damiankloip’s picture

Status: Active » Needs review
FileSize
4.27 KB

Something like this.

damiankloip’s picture

Talking to Daniel, moving this to a new interface if probably the best idea.

dawehner’s picture

Status: Needs review » Needs work

.

The last submitted patch, 2: 2498785.patch, failed testing.

damiankloip’s picture

FileSize
5.43 KB

Added DisplayMenuInterface. No interdiff...because.

damiankloip’s picture

Status: Needs work » Needs review
dawehner’s picture

Issue summary: View changes
Status: Needs review » Reviewed & tested by the community

Looks great for me. Added a beta evaluation

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 6: 2498785-6.patch, failed testing.

jibran’s picture

Fatal error: Call to undefined method Drupal\views\Plugin\views\display\Block::getMenuLinks() in /var/lib/drupaltestbot/sites/default/files/checkout/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php on line 2421
FATAL Drupal\block\Tests\Views\DisplayBlockTest: test runner returned a non-zero error code (255)

Fatal error: Call to undefined method Drupal\views\Plugin\views\display\DefaultDisplay::getMenuLinks() in /var/lib/drupaltestbot/sites/default/files/checkout/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php on line 2421

Fatal error: Call to undefined method Drupal\views\Plugin\views\display\DefaultDisplay::getMenuLinks() in /var/lib/drupaltestbot/sites/default/files/checkout/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php on line 2421
<h1>Uncaught exception thrown in shutdown function.</h1><p><em class="placeholder">Drupal\Core\Database\DatabaseExceptionWrapper</em>: SQLSTATE[42S02]: Base table or view not found: 1146 Table &#039;drupaltestbotmysql.simpletest993696search_total&#039; doesn&#039;t exist: SELECT t.word AS realword, i.word FROM {search_total} t LEFT JOIN {search_index} i ON t.word = i.word WHERE i.word IS NULL; Array
(
)
 in <em class="placeholder">search_update_totals()</em> (line <em class="placeholder">224</em> of <em class="placeholder">/var/lib/drupaltestbot/sites/default/files/checkout/core/modules/search/search.module</em>).<pre>search_update_totals()
call_user_func_array('search_update_totals', Array)
_drupal_shutdown_function()
damiankloip’s picture

Status: Needs work » Needs review
FileSize
6.63 KB
1.81 KB

?

Status: Needs review » Needs work

The last submitted patch, 11: 2498785-11.patch, failed testing.

damiankloip’s picture

Status: Needs work » Needs review
FileSize
6.84 KB
534 bytes

gah

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

Thank you for fixing the fatal ;)

damiankloip’s picture

Most welcome :)

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 13: 2498785-13.patch, failed testing.

damiankloip queued 13: 2498785-13.patch for re-testing.

dawehner’s picture

Status: Needs work » Reviewed & tested by the community

Meh

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs reroll

2498785-13.patch no longer applies.

error: patch failed: core/modules/views/src/Plugin/Derivative/ViewsMenuLink.php:8
error: core/modules/views/src/Plugin/Derivative/ViewsMenuLink.php: patch does not apply

damiankloip’s picture

Issue tags: -Needs reroll
FileSize
7.02 KB

Rerolled.

damiankloip’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 20: 2498785-20.patch, failed testing.

damiankloip’s picture

Status: Needs work » Needs review
FileSize
7.06 KB
757 bytes

damiankloip queued 23: 2498785-23.patch for re-testing.

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

Still applies.

Interdiff looks fine.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 23: 2498785-23.patch, failed testing.

jibran queued 23: 2498785-23.patch for re-testing.

jibran’s picture

Status: Needs work » Reviewed & tested by the community

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 23: 2498785-23.patch, failed testing.

damiankloip queued 23: 2498785-23.patch for re-testing.

tim.plunkett’s picture

Status: Needs work » Reviewed & tested by the community
xjm’s picture

Status: Reviewed & tested by the community » Needs work

Thanks, this looks like a sensible fix to me overall. Thanks also for the beta evaluation.

+++ b/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php
@@ -2612,6 +2593,13 @@ public function mergeDefaults() {
+   * {@inheritdoc}
+   */
+  public function remove() {
+
+  }

So I think we at least need an inline comment explaining why the base implementation is empty. However, it also makes me wonder if this method should also be on a separate interface if all display plugins don't actually need to implement it?

Also, looking into this further, I noticed that
\Drupal\views\Plugin\views\display\Block::remove() is still calling parent::remove(), which is now a null-op.

I thought about whether this should include a change record for the BC break. Given the assessment in the beta evaluation, maybe not, but maybe we should add one since there is technically a BC break, it was a public method on ViewExecutable, and maybe someone somewhere has some views menu manipulating code we didn't think of? What do you think?

Also gah at the testbot failures; looks like this issue got stuck in the eddies of the RTBC queue for a month.

dawehner’s picture

Thank you for your review xjm.

So I think we at least need an inline comment explaining why the base implementation is empty. However, it also makes me wonder if this method should also be on a separate interface if all display plugins don't actually need to implement it?

Well you know of our gigantic display plugin objects. Having empty base implementations there is no uncommon. ::execute() , ::newDisplay() are two examples for it. I see your point,
but I'm not sure what we would really from an additional interface at this point, given that there is no way you could start from scratch when you write a display plugin.

I thought about whether this should include a change record for the BC break. Given the assessment in the beta evaluation, maybe not, but maybe we should add one since there is technically a BC break, it was a public method on ViewExecutable, and maybe someone somewhere has some views menu manipulating code we didn't think of? What do you think?

In an ideal world I think we should have marked those stuff as @internal. Its just an implementation detail that the view executable was called to generate the menu items.

And there is obligatory smiley :)

damiankloip’s picture

No, I think I agree this is not really interface material. We then need to always check for another interface and that seems worse DX and more error prone. As much as people have tried to shoehorn new interfaces into views plugins, they are still basically dependent on the base class for a plugin type, especially displays.

I would imagine close to zero people will be using that, but sure, we could add a notice anyway. Can't hurt.

damiankloip queued 23: 2498785-23.patch for re-testing.

dawehner’s picture

Status: Needs work » Reviewed & tested by the community

Its still green.

damiankloip’s picture

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed 3c12e21 and pushed to 8.0.x. Thanks!

Thanks for adding the CR and the beta evaluation.

  • alexpott committed 3c12e21 on 8.0.x
    Issue #2498785 by damiankloip, dawehner: Remove ViewExecutable::...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.