Reenable custom Views admin pages

Exact same error here.

I'm working on a fix for this, stay tuned :)

Please review the attached patch.

The problem was that the robots metatag needs processing before it can be saved. This processing was added to the ViewsDisplayExtender, but not to the custom administration forms that metatag_views provides. This is probably the reason why the error was not reported more widely.
You might need to update the base metatags before translating works correctly, I haven't tried that.

Strange, the patch does not touch the routes at all. Have you rebuilt the cache after enabling metatag_views?

@mytko: Please remove your current files from the metatag directory and expand this archive instead, then clear the caches and see if the problem persists. Thanks.

Are you sure the Metatag Views module is still enabled?

Hi guys,

I can not reproduce the bug in these versions.

Please see screencast below.

The "RouteNotFoundException" error happens to me on the Metatag Views page: /admin/config/search/metatag/views

Upon enabling the Metatag Views module, that page works fine.
But, after adding metatags to a view (as shown in the screencast in comment #13), if I try to re-visit the Metatag Views page, I get the error.

I suspect the module has an implicit dependency to config_translation. MetatagViewsController does not seem to check it before trying to load the translations route.

Do you have config_translation enabled?

Dietrich

Adding the metatag works fine now, but it's then on viewing the subsequent /admin/config/search/metatag/views page that the missing route error shows up, because one of the 'operations' links for each view is to the translate_overview page. That will only exist if the config_translation module is enabled (which it's not for me), so I agree with dietr_ch.

Here's a patch :-)

Adding a test.

It's kinda annoying that it's saying the branch tests fail when the default test instance for the 8.x-1.x branch is against 8.3.x, which fully pass, rather than the 8.4.x tests which fail. Grr. I've set the module tests against 8.3.x to rerun, so hopefully them passing will kick it back into gear.

Ok, the tests are green. This is strange, though, as it was suggested the error was because the config translation module was required, which doesn't seem to be the case. Any thoughts?

Thanks DamienMcKenna, patch worked for me.

Before committing this I'd like to find exactly what is causing the failures. The tests-only fine in #20 isn't failing, so there's an additional aspect to this that I'm not catching quite yet. Any thoughts?

• I received the error above after attempting to add a meta tag to a view via the admin/config/search/metatag/views route.
• I managed to add a tag via Views UI
• The added tags were not then visible via admin/config/search/metatag/views
• I then applied patch #20
• I could then see the added tag config in admin/config/search/metatag/views
• I then got this when I clicked the edit button against the now visible entry in admin/config/search/metatag/views:

Symfony\Component\Routing\Exception\RouteNotFoundException: Route "metatag_views.metatags.translate_overview" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (line 190 of core/lib/Drupal/Core/Routing/RouteProvider.php).

Solved by uninstalling and reinstall metatags_views (with patch #20 still). So far seems to be working as expected.

HTH

For anyone who hasn't fixed their site yet ;-) could you please test clearing your site's caches after applying the patch to see if the route error mentioned in #25 is still there or if the cache-clearing skips past that problem. Thanks.

I ran into the same issue as #25 after applying the patch in #20.

Clearing the cache does not resolve the issue.

I uninstalled and reinstalled the views_metatags module (without reverting my configured displays) and it still did not work. The previously configured displays were still there after reinstallation. Reverting and recreating still produced the breaking error.

Reverting all displays before uninstalling and reinstalling and reconfiguring did not work either.

Full error when trying to edit a display:

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


Symfony\Component\Routing\Exception\RouteNotFoundException: Route "metatag_views.metatags.translate_overview" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (line 190 of core/lib/Drupal/Core/Routing/RouteProvider.php).

I get this behavior for each display that I create.

Can confirm the same issue as #25 and #27

I've just spent some time testing Metatag Views on a copy of a production site with 8.3.4 that has translations running and have not run into any problems, and then did the same on both barebones 8.3.x and 8.4.x installations. None of the installations had any problems.

Both of the barebones installations had the latest core releases, they just had the "Standard" installation profile applied and then Token, Metatag and Metatag Views were installed. The production site last had its contrib modules updated in April-ish (CTools was still 8.x-3.0-alpha27).

This doesn't mean I do not believe you about there being a problem, it means I want to spend more time digging through to working out what the actual cause us so that we can have a test that demonstrates the error and then show how the patch fixes it.

I'm getting the exact same error out of the box

> drush dl drupal
Project drupal (8.3.5) downloaded to /var/www/html/drupal-8.3.5.                                        [success]
Project drupal contains:                                                                                [success]
 - 1 profile: standard
 - 14 themes: testing_config_import, testing_missing_dependencies, testing_multilingual_with_english,
minimal, testing_multilingual, testing_config_overrides, drupal_system_listing_compatible_test,
testing, stable, classy, bartik, twig, seven, stark
 - 73 modules: book, breakpoint, migrate, tour, block_place, link, content_translation, forum,
shortcut, ban, language, comment, datetime_range, responsive_image, config, options, tracker,
automated_cron, action, node, migrate_drupal_ui, serialization, field_layout, contextual,
dynamic_page_cache, datetime, search, dblog, text, system, path, statistics, syslog, menu_ui, file,
views_ui, hal, help, views, block_content, big_pipe, ckeditor, rdf, quickedit, history, taxonomy,
block, entity_reference, content_moderation, inline_form_errors, workflows, contact, color,
page_cache, editor, image, rest, aggregator, user, field_ui, toolbar, update, field,
menu_link_content, telephone, locale, outside_in, filter, simpletest, config_translation, basic_auth,
layout_discovery, migrate_drupal

> drush en metatag
> drush en metatag_views
[go to /admin/config/search/metatag/views/add enter some values and hit submit]
> drush ws --tail
 45  11/Jul 11:44  error   php     InvalidArgumentException: The configuration property                          
                                   display.page_1.display_options.display_extenders.metatag_display_extender.met 
                                   atags.robots.index doesn't exist. in Drupal\Core\Config\Sc

Oh wow, I hadn't noticed that entire section existed. Doh.

Yeah, that system needs some tests.

What I suggest doing for now is to add meta tags directly to the views themselves rather than via the separate config pages.

Was facing the same InvalidArgumentException kind of error when trying to enable 'follow, noindex' on my views. Patch #20 fixed the issue for me. Thanks!

I'm trying to track down the cause of an error I'm getting after upgrading to 8.4 and running drush updb. The pattern is exactly as described in https://www.drupal.org/node/2914958 (that is, I update core and then run drush updb), but the error-message I'm getting is identical to the one in the description of this issue (with the exception of the name of the view that is).

Any chance the two are related? Could there be something in 8.4 that provokes the this issue?

The patch in #20 does not help.

Just to clarify. The site I where getting the exception on has two views with a metatag configuration on a view. The site is currently running on (core) 8.3, and if I upgrade to 8.4 and do a drush updb I get the exception even with the patch from #20. The exception is thrown in the last part of update-db where core re-saves amongst other things all views.

The patch _does_ allow me to save the view manually both on 8.3 and 8.4. In other words, the patch seems to be handling the situation where the view is saved from the backend, but not the case where it is saved programmatically. The post update-db save of views seems to be handled from views_post_update_revision_metadata_fields() which triggers a $view->save() on all views on the site.

My current workaround to get the site upgraded is
- Save a copy of relevant metatag_display_extender sections in the views exported .yml files
- Remove the metatag configuration from the configuration
- Re-import the configuration
- Upgrade to 8.4 and run the update-hooks
- Reapply the metatag_display_extender configurations

This way I get a site that works just fine just as long as no-one saves any views programatically :)

Look forward to progress on this issue, please advice if I can help with eg. more tests.

Hi @danquah, please can you confirm exactly what the error message you get is?

Ah yes, sure thing:

Failed: InvalidArgumentException: The configuration property display.overview.display_options.display_extenders.metatag_display_extender.metatags.robots.index doesn't exist. in Drupal\Core\Config\Schema\ArrayElement->get() (line 76 of /var/www/web/core/lib/Drupal/Core/Config/Schema/ArrayElement.php).

And just to set the context, the view in question has a display called "overview" which is why the config-string reads "display.overview" and not "display.default" as the one in the description of this issue.

The error means that the data the system is trying to save for the robots metatag (likely the array ['index' => 'index'] as created by the checkboxes form element) does not match the configuration schema (which expects a string 'index').

This is ususally the case if form values are stored directly, without processing by the MetatagTagManager. We do this when saving the core View form or the metatag specific form, using the following checks:

      foreach ($metatags as $tag_id => $tag_value) {
        // Some plugins need to process form input before storing it.
        // Hence, we set it and then get it.
        $tag = $this->metatagTagManager->createInstance($tag_id);
        $tag->setValue($tag_value);
        if (!empty($tag->value())) {
          $tag_values[$tag_id] = $tag->value();
        }
      }

If you run into this error when running update scripts, you either had a broken configuration before updating the view, or we missed a way of saving the view. The views_post_update_revision_metadata_fields update hook only re-saves the View using Entity::save, we should be able to handle that.
I am wondering ... is your View translated, and have you maybe just edited one language version but one of the others still contains invalid values?

The site does have translation and configuration translation enabled, but I just checked and we only have a configuration for that view in the "root" configuration folder and not in the language/da subfolder. Might that be a problem?

With regards to the view already being broken, it might very well be, anything in particular I should be looking for in the config export (I can also attach the .yml if it helps and is relevant for the issue).

As far as I can tell from our SCM we where running metatag 1.0-beta12 when the configuration for that view was last exported, so that might also be a source of the problem.

That being said, I still get the Exception if I apply the patch from #20, export the configuration, and then upgrade to core 8.4 and run updb....

we only have a configuration for that view in the "root" configuration folder and not in the language/da subfolder. Might that be a problem?

That shouldn't be a problem.

With regards to the view already being broken, it might very well be, anything in particular I should be looking for in the config export

If you could post the metatag_display_extender section, that might help.

Here you go

views.view.badges.yml:

display
...
  overview:
...
    display_options:
      display_extenders:
        metatag_display_extender:
          metatags:
            title: '[ddsdk:badge-overview-title]'
            description: '[ddsdk:badge-overview-description]'
            abstract: ''
            keywords: ''
            geo_placename: ''
            geo_position: ''
            geo_region: ''
            icbm: ''
            canonical_url: ''
            content_language: ''
            robots:
              index: 0
              follow: 0
              noindex: 0
              nofollow: 0
              noarchive: 0
              nosnippet: 0
              noodp: 0
              noydir: 0
              noimageindex: 0
              notranslate: 0
            shortlink: ''
            news_keywords: ''
            standout: ''
            generator: ''
            image_src: '[ddsdk:badge-overview-topimage]'
            original_source: ''
            referrer: ''
            rights: ''
            og_determiner: ''
            og_site_name: ''
            og_type: ''
            og_url: '[current-page:url]'
            og_title: '[ddsdk:badge-overview-title]'
            og_description: '[ddsdk:badge-overview-description]'
            og_image: '[ddsdk:badge-overview-topimage]'
            og_video: ''
            og_image_url: ''
            og_image_secure_url: ''
            og_video_secure_url: ''
            og_image_type: ''
            og_video_type: ''
            og_image_width: ''
            og_video_width: ''
            og_image_height: ''
            og_video_height: ''
            og_updated_time: ''
            og_latitude: ''
            og_longitude: ''
            og_see_also: ''
            og_street_address: ''
            og_locality: ''
            og_region: ''
            og_postal_code: ''
            og_country_name: ''
            og_email: ''
            og_phone_number: ''
            og_fax_number: ''
            og_locale: ''
            og_locale_alternative: ''
            article_author: ''
            article_publisher: ''
            article_section: ''
            article_tag: ''
            article_published_time: ''
            article_modified_time: ''
            article_expiration_time: ''
            fb_admins: ''
            fb_pages: ''
            fb_app_id: ''
      path: maerker
      display_description: ''

Yeah, that's definitely the broken structure that was used while we were still working on the metatag_views feature (see #2563647-105: Views integration). To fix it, you can repeat what @Peacog did or directly edit your View's configuration and change the robots part to just robots: ''. To edit, you can use Devel's "Config Editor" feature or the core import/export.
Re-submitting the metatag part on the View or in the separate metatag form might also work.

That did the trick. I removed the metatag section from the view, configured it manually again and did an export. The newly exported configuration survived the updatedb without any problems.

Thanks! :)

So, we're now back to #31: Adding tests for the Metatag custom UI at /admin/config/search/metatag/views.

I can confirm patch 20 worked for me, thanks.

It's horrible that this patch isn't still included in the module. This is a default necessary.

Using Drupal 8.4.3, I applied this patch (#20) to the latest dev branch of Metatag and got the following error on my site:
Fatal error: Class 'Drupal\metatag\Plugin\Field\FieldType\MetatagFieldItem' not found in mysite/docroot/core/modules/field/src/FieldStorageConfigStorage.php on line 159.

Disregard the above error, it was because the patch would not apply to the metatag dev version I was trying to apply it to.

I applied the patch manually, and it fixed the issue. However, the patch does need to be re-rolled if used against the latest dev branch.

The attached patch is my version of #20 re-rolled against the latest dev version that I downloaded via git clone.

Thanks :-)

Lets check in with the testbot again.

Another re-roll of #20.

Looks ok.

I can also confirm this issue.

I could not create metatags for views from /admin/config/search/metatag/views, which resulted in the error from the issue's description. After successfully adding some metatags from the views UI the config page /admin/config/search/metatag/views was not available anymore resulting in the error from #10.

The patch from #52 applied against 8.x-1.4 and brought the config page back, showing me the view overridden from within the views UI, but still gives me the error after trying to edit it using the dropbutton.

Symfony\Component\Routing\Exception\RouteNotFoundException: Route "metatag_views.metatags.translate_overview" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (Zeile 190 in /Applications/MAMP/htdocs/mypage/htdocs/core/lib/Drupal/Core/Routing/RouteProvider.php).

Confirm the issue. Patch #52 is not fix it. When I press apply, AJAX returns 500 error:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "website" plugin does not exist. in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 52 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php). 
Drupal\Core\Plugin\DefaultPluginManager->getDefinition('website') (Line: 16)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance('website', Array) (Line: 84)
Drupal\Component\Plugin\PluginManagerBase->createInstance('website') (Line: 104)
Drupal\metatag_views\Plugin\views\display_extender\MetatagDisplayExtender->submitOptionsForm(Array, Object) (Line: 2004)
Drupal\views\Plugin\views\display\DisplayPluginBase->submitOptionsForm(Array, Object) (Line: 476)
Drupal\views\Plugin\views\display\PathPluginBase->submitOptionsForm(Array, Object) (Line: 467)
Drupal\views\Plugin\views\display\Page->submitOptionsForm(Array, Object) (Line: 109)
Drupal\views_ui\Form\Ajax\Display->submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 255)
Drupal\views_ui\ViewUI->standardSubmit(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 585)
Drupal\Core\Form\FormBuilder->processForm('views_ui_edit_display_form', Array, Object) (Line: 314)
Drupal\Core\Form\FormBuilder->buildForm('views_ui_edit_display_form', Object) (Line: 212)
Drupal\views_ui\Form\Ajax\ViewsFormBase->Drupal\views_ui\Form\Ajax\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 214)
Drupal\views_ui\Form\Ajax\ViewsFormBase->ajaxFormWrapper('Drupal\views_ui\Form\Ajax\Display', Object) (Line: 123)
Drupal\views_ui\Form\Ajax\ViewsFormBase->getForm(Object, 'list', 'ajax') (Line: 44)
Drupal\views_ui\Form\Ajax\Display->getForm(Object, 'list', 'ajax', 'metatags')
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}()
call_user_func_array(Object, Array) (Line: 153)
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: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 657)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

subscribe

Confirm the described issue.

We've strayed quite a bit from the original report, so I'll try to summarize what we've discovered so far.

1. The original issue was related to a schema change for robots
   This was fixed in #5.
2. Then a routing error with metatag_views.metatags.translate_overview popped up in #6
   This was due to an assumption that the config_translation is always available (it's not) and has been addressed in various patches since then, #52 being the most recent.
3. Now we have a website plugin error in #55
   This has not been addressed yet. We should first figure out if this is related, or maybe a different issue altogether.

This whole issue is further complicated by the fact that there are two locations for configuring views metatags, and thus two locations for translating them.

1. The standalone metatag configuration
   at /admin/config/search/metatag/views/{VIEW_ID}/{DISPLAY_ID}/edit
   and translation at /admin/config/search/metatag/views/{VIEW_ID}/{DISPLAY_ID}/translate if using config_translation
2. The view configuration
   at /admin/structure/views/view/{VIEW_ID}/edit/{DISPLAY_ID} in the middle column under "Meta-Tags"
   and translation at /admin/structure/views/view/{VIEW_ID}/translate if using config_translation

To further investigate the issue, please post which error you encounter, and under which conditions (which config form, with or without config_translation etc.). Please also be aware that modules that extend the metatag tags might influence your problem. Otherwise we might never get to the bottom of this.

Clarifying the problem to make it easier to find as it keeps coming up.

FYI I'm working to hide the separate Metatag-Views admin pages in #2956199: Remove separate admin pages for Views integration, as a way of avoiding this problem until we can fix it properly.

Just to be clear: the next release (8.x-1.5) will not have the separate admin pages for managing configurations for Views as a temporary solution until we can fix this issue.

Here are two patches - one file just recovers the removed Yaml files, and another combines that with the patch from #52.

I split off the test change from #20 into #2956227: Test improvements from 2883718-20 because as-is it's not really related to this problem.

Thinking out loud here - does anyone actually want to use the separate Views admin pages or should we just replace it with a single configurable default listed on the main defaults page, then leave the individual views to be managed on their own?

Personally, having a separate config just for the metatags allows us to pass setting up metatags (or translating them) to project management or in some cases even to the client themselves. We wouldn't give either access to edit our views, as there's a lot more that could go wrong.

@ckaotik: Ok, that's a valid use case.

Lets focus this on just making all those pages work properly again.

Rerolled #60 against HEAD. It looks like the following code is already committed (which causes #60 to fail to apply):

diff --git a/metatag_views/tests/src/Functional/MetatagViewsBasicsTest.php b/metatag_views/tests/src/Functional/MetatagViewsBasicsTest.php
index ed221c9..3aa3e80 100644
--- a/metatag_views/tests/src/Functional/MetatagViewsBasicsTest.php
+++ b/metatag_views/tests/src/Functional/MetatagViewsBasicsTest.php
@@ -131,6 +131,11 @@ public function testSiteStillWorks() {
 
     // Confirm what the page title looks like now.
     $this->assertTitle('Metatag title');
+
+    // Load the Metatag admin page to confirm it still works.
+    $this->drupalGet('admin/config/search/metatag');
+    $this->assertResponse(200);
+    $this->assertText('Add default meta tags');
   }
 
 }

Thanks @ChrisBurge.

Thanks @ChrisBurge for the reroll!

I've a suggestion to make: How about we use the default metatag translation ui that editors already know from content edit forms? I've attached a patch and some before/after screenshots for how this could work (unless I've messed up the patch file). This would allow for more complex form elements by providers and allows to use the regular tag groups.
Groups for tags that have not been set in the original language are displayed but without any inputs - or we could of course remove those groups. We could also disable the original language, but either way changes on that side of the form are not saved. We could also apply this to the views ui.

How do you feel about this? (we can always fallback to #65)

Please note the following: #2981549: Separate Metatag configuration from Views definition

Rerolled #65 against 8.x-1.7. Parts of the code have been moved or are already committed.

Thank you for the patch. Unfortunately, we still had a few problems: Originally we were using Metatag 8.x-1.2 and enabled metatag_views when we got the error message shown in the issue summary. We then updated to metatag 8.x-1.7 and applied the patch from #2883718-69: Reenable custom Views admin pages. After clearing all caches, the views tab appeared on the metatag settings page and we were able to add a new configuration for a view. After adding a configuration, we were redirected to the views tab and got a success message, but the configuration did not appear on the page. Also, the metatags we configured were not added to the view in question. We cleared all caches again, but that didn't help. Upon looking at a configuration export, we saw that the metatags we configured were successfully added to the views configuration. We then uninstalled the metatag_views module and enabled it again immediately. Now, the configuration we added earlier was displayed on the views tab and the metatags were visible on the views page as configured. When we exported the configuration again, an update was shown for the views.settings.yml. Is the patch maybe missing an update hook to work with earlier existing installations of metatag_views?

With the patch in #69 I get a RouteNotFoundException: Route "metatag_views.metatags.translate_overview" does not exist. when editing metatag_views configuration, if the config_translation module is not enabled. Attached is a patch to fix this. #70 still needs to be addressed, though.

Thanks FeyP, that works well for me. It's interesting that the local task didn't used to cause the problem in the same way; but I could totally imagine something has changed in Drupal/Symfony's route/task handling since my patch back in #19.

Rerolled #71 against 8.x-1.9.

Rerolled #71 against 8.x-1.9.

Sorry, #73 was not fully exported.

Rerolled #71 against 8.x-1.9 - full.

Rerolled #71 against 8.x-1.9. Missing empty line at the end of patch fix.

Rerolled #71 against 8.x-1.9.

#77 seems to work however displays a duplicate admin/config/search/metatag tab.

Here in French:

So, I think this is back to the olde Needs Tests thing. With test coverage we can plan out exactly what we expect to happen, then make sure the code does that.

This patch doesn't install for me on 8.x-1.13.

Rerolled for 8.x-1.13, still needs tests.

Added a functional test as per the steps to reproduce. Please review!

I have been testing the UI and the translation tab for views meta-tags does not work. It throws like this:
Error: Call to undefined method Symfony\Component\HttpFoundation\RequestStack::get() in Drupal\metatag_views\Controller\MetatagViewsTranslationController->itemPage() (line 85 of modules/contrib/metatag/metatag_views/src/Controller/MetatagViewsTranslationController.php).

The reason is this commit:
https://git.drupalcode.org/project/metatag/-/commit/f76d3fa9008bd91bd18c...

which replaces

    $view_id = \Drupal::request()->get('view_id');
    $display_id = \Drupal::request()->get('display_id');

with:

    $view_id = $this->requestStack->get('view_id');
    $display_id = $this->requestStack->get('display_id');

in metatag_views/src/Controller/MetatagViewsTranslationController.php

$this->requestStack is instantiated like this: $container->get('request_stack') in the create method of the controller, whereas \Drupal::request() is actually doing this:

  public static function request() {
    return static::getContainer()->get('request_stack')->getCurrentRequest();
  }

The patch simply adds the ->getCurrentRequest() part in the controller as well as a simple test just for this case. It also adds a helper method to the trait to create a view (might be helpful for other tests).

There are still more tests to be written, but just adding a small brick :).

I did not add the new files to the patch... Reuploading.

I have fixed the doubled tabs problem - it was caused by the duplicated entries in the yaml files. Also added Views to the menu (next to Global and Settings).

reroll...

Re-Roll against 2.0.x/2.0.0