Views contextual filter's title override is invisible to TitleResolver

I have the same bug, with 8.1.7

Well, to be honest the default implementation is sort of designed to not provide that level of flexibility in exchange for better performance.

There are contrib modules which have more flexibility, like https://www.drupal.org/project/crumbs, but its not available in 8.x yet :(

This is still present as an issue.

From a user's point of view, one would assume if the view's title is correctly shown in the breadcrumb then when it is overridden in a contextual filter, the overridden title would also be shown in the breadcrumb.

Given how long this issue has been open, unless someone's feeling motivated to fix this in core, I can fix this in easy breadcrumb:

https://www.drupal.org/project/easy_breadcrumb/issues/2927421

Cool. I haven't dug into this one yet, but working around a bug in page manager was only a few lines of code in Easy Breadcrumb. So, I am expecting something similar on this one. I'll update here when we have a decent patch for Easy Breadcrumbs incase folks wanna steal it :)

~G

Any updates on this for core Greg?

Attached a proposed patch

new version of the patch with the missing dockblock

#16 work nice for me

I have applied the patch in #16 but that still does not fix the issue for me. I have a view that shows content instead of fields but it is using a contextual filter with the override title option. The title of the page is properly overriden but that is not reflected in the breadcrumb nor the title attribute of the browser window.

Works for me.

* Drupal 8.5.6 (last stable release).
* menu_breadcrumb 1.6

Languages:

* Basque (default)
* Spanish

I tried #16 against Drupal 8.5.6 and I am experiencing the same issue as #18. Title shows overridden, breadcrumb does not.

If anyone is looking for a workaround, I was able to get the desired effect by adding twig directly to the view's title field (not overriding the title with the contextual filter itself. )

Example: My Title {{ arguments.name }}, where the arguments is the name of a taxonomy term.

The following thread pointed me in the right direction.
https://www.drupal.org/project/drupal/issues/2912332

Drupal 8.6.2

Sorry for my bad english.

I'm in a new project and I found that my patch #2787051-16: Views contextual filter's title override is invisible to TitleResolver doesn't work for me when I have a views path like news/%

in this case I set the {{ arguments.name }} in the contextual filter title override and, for breadcrumb, I need to set the display title as: "%arg_0" (without apply the patch)

@see: PathBasedBreadcrumbBuilder::build() and TitleResolver::getTitle()

Hi,

It doesn't work for me too. When you are using a contextual filter, you have to set the arguments in order to see the overridden title.
I just tried a new patch which is working for the current view.

I get the parameters from the current route, but this is probably not the good way to do it. Indeed, if you have several views like this in your breadcrumb, it will probably break the other view names that are not your current view.

The parameters maybe should be passed to the title function in order generate the correct title. I put the patch that is working with the current view but I will try to find some time to dig into this and check that the bug I suspect is really here.

@mrshawntucker For me the twig is working only in the Title block of the page but not in the breadcrumb or in the title tag that defines the name of the browser tab.

I have just noticed that the route_match was already there, I should sleep it's really late around here ^^

So, there is a better patch that should apply the override title in the breadcrumb and in the head html tag.
Tell me if it works for you :)

Concerning using the argument name in the override title, there are plenty of issues concerning this and it's a different problem:
#2915934 #2640994

Ok I have just found out that this code contains also "view_id" and "display_id".

$parameters = $route_match->getParameters();

But when we set the arguments, we only should have arg_0, arg_1 etc... So I had to remove those two in order to correct a bug when I had multiple contextual filters in the same view URL. But I don't even know how it was working for one before....

Anyway, I have removed these two parameters manually because I haven't found a function in the core that do something like that, but I am sure there is some code I have not found that could help.

In this Feed.php class from the core (line 287), they build the title with the same way we did.

    $clone->setArguments($this->view->args);
    $clone->setDisplay($this->display['id']);
    $clone->buildTitle();

This blog post's solution works: https://medium.com/@philw_/enable-views-contextual-filter-page-title-overriding-in-drupal-8-493b61512343

@juampynr Thanks for the tip :) But it should work without this fix. And I am not sure that it's working in the breadcrumb when the view is a parent of the current page.

Makes sense that the replacements need this context, nice work on this.

+++ b/core/modules/views/src/Plugin/views/display/PathPluginBase.php
@@ -130,6 +130,7 @@ protected function getRoute($view_id, $display_id) {
       '_title' => $this->view->getTitle(),
+      '_title_callback' => 'Drupal\views\Routing\ViewPageController::title',

_title is redundant like this I think.

In \Drupal\views\Plugin\views\display\PathPluginBase::getRoute there is a fair amount of logic to figure out if the view uses arguments. Can we not use that to switch between _title and _title_callback, so we only do the callback if there is a chance this is needed? So maybe we can avoid the additional overhead of the callback when we can?

Also, this needs tests.

#28 just makes my pages spin. I was running into this issue as well when I tried taking a stab at figuring this issue out. Seems like the site gets Router gets in recursive loop or something. My logs have thousands upon thousands of these dependent on how long I let it go for.

Notice: Trying to get property of non-object in Drupal\views\ManyToOneHelper->addTable() (line 88 of /var/www/html/drupal/web/core/modules/views/src/ManyToOneHelper.php) #0 /var/www/html/drupal/web/core/includes/bootstrap.inc(584): _drupal_error_handler_real(8, 'Trying to get p...', '/var/www/html/d...', 88, Array)
#1 /var/www/html/drupal/web/core/modules/views/src/ManyToOneHelper.php(88): _drupal_error_handler(8, 'Trying to get p...', '/var/www/html/d...', 88, Array)
#2 /var/www/html/drupal/web/core/modules/views/src/ManyToOneHelper.php(187): Drupal\views\ManyToOneHelper->addTable(Object(stdClass))
#3 /var/www/html/drupal/web/core/modules/views/src/Plugin/views/argument/StringArgument.php(224): Drupal\views\ManyToOneHelper->ensureMyTable()
#4 /var/www/html/drupal/web/core/modules/views/src/ViewExecutable.php(1111): Drupal\views\Plugin\views\argument\StringArgument->query(false)
#5 /var/www/html/drupal/web/core/modules/views/src/ViewExecutable.php(1873): Drupal\views\ViewExecutable->_buildArguments()
#6 /var/www/html/drupal/web/core/modules/views/src/Routing/ViewPageController.php(86): Drupal\views\ViewExecutable->buildTitle()
#7 [internal function]: Drupal\views\Routing\ViewPageController->title('track_systems_t...', 'page_vehicle_ma...', Object(Drupal\Core\Routing\RouteMatch))
#8 /var/www/html/drupal/web/core/lib/Drupal/Core/Controller/TitleResolver.php(58): call_user_func_array(Array, Array)
#9 /var/www/html/drupal/web/core/modules/system/src/PathBasedBreadcrumbBuilder.php(177): Drupal\Core\Controller\TitleResolver->getTitle(Object(Symfony\Component\HttpFoundation\Request), Object(Symfony\Component\Routing\Route))
#10 /var/www/html/drupal/web/core/lib/Drupal/Core/Breadcrumb/BreadcrumbManager.php(83): Drupal\system\PathBasedBreadcrumbBuilder->build(Object(Drupal\Core\Routing\RouteMatch))
#11 /var/www/html/drupal/web/core/modules/system/src/Plugin/Block/SystemBreadcrumbBlock.php(72): Drupal\Core\Breadcrumb\BreadcrumbManager->build(Object(Drupal\Core\Routing\CurrentRouteMatch))
#12 /var/www/html/drupal/web/core/modules/block/src/BlockViewBuilder.php(203): Drupal\system\Plugin\Block\SystemBreadcrumbBlock->build()
#13 [internal function]: Drupal\block\BlockViewBuilder::preRender(Array)
#14 /var/www/html/drupal/web/core/lib/Drupal/Core/Render/Renderer.php(378): call_user_func('Drupal\\block\\Bl...', Array)
#15 /var/www/html/drupal/web/core/lib/Drupal/Core/Render/Renderer.php(450): Drupal\Core\Render\Renderer->doRender(Array)
#16 /var/www/html/drupal/web/core/lib/Drupal/Core/Render/Renderer.php(195): Drupal\Core\Render\Renderer->doRender(Array, false)
#17 /var/www/html/drupal/web/core/lib/Drupal/Core/Template/TwigExtension.php(490): Drupal\Core\Render\Renderer->render(Array)
#18 /var/www/html/drupal/vendor/twig/twig/lib/Twig/Environment.php(467) : eval()'d code(319): Drupal\Core\Template\TwigExtension->escapeFilter(Object(Drupal\Core\Template\TwigEnvironment), Array, 'html', NULL, true)
#19 /var/www/html/drupal/vendor/twig/twig/lib/Twig/Template.php(215): __TwigTemplate_17ef12ba4632907f82cb69beada9aa4240f6340c59c25a2858778e287d3fcde4->block_content(Array, Array)
#20 /var/www/html/drupal/vendor/twig/twig/lib/Twig/Environment.php(467) : eval()'d code(96): Twig_Template->displayBlock('content', Array, Array)
#21 /var/www/html/drupal/vendor/twig/twig/lib/Twig/Template.php(432): __TwigTemplate_17ef12ba4632907f82cb69beada9aa4240f6340c59c25a2858778e287d3fcde4->doDisplay(Array, Array)
#22 /var/www/html/drupal/vendor/twig/twig/lib/Twig/Template.php(403): Twig_Template->displayWithErrorHandling(Array, Array)
#23 /var/www/html/drupal/vendor/twig/twig/lib/Twig/Template.php(411): Twig_Template->display(Array)
#24 /var/www/html/drupal/web/core/themes/engines/twig/twig.engine(64): Twig_Template->render(Array)
#25 /var/www/html/drupal/web/core/lib/Drupal/Core/Theme/ThemeManager.php(384): twig_render_template('themes/custom/t...', Array)
#26 /var/www/html/drupal/web/core/lib/Drupal/Core/Render/Renderer.php(437): Drupal\Core\Theme\ThemeManager->render('page', Array)
#27 /var/www/html/drupal/web/core/lib/Drupal/Core/Render/Renderer.php(195): Drupal\Core\Render\Renderer->doRender(Array, false)
#28 /var/www/html/drupal/web/core/lib/Drupal/Core/Template/TwigExtension.php(490): Drupal\Core\Render\Renderer->render(Array)
#29 /var/www/html/drupal/vendor/twig/twig/lib/Twig/Environment.php(467) : eval()'d code(88): Drupal\Core\Template\TwigExtension->escapeFilter(Object(Drupal\Core\Template\TwigEnvironment), Array, 'html', NULL, true)
#30 /var/www/html/drupal/vendor/twig/twig/lib/Twig/Template.php(432): __TwigTemplate_0149a65ec4c3c07bf3023ca49566395837322b1f8708b4127d0d6f71bbc47e75->doDisplay(Array, Array)
#31 /var/www/html/drupal/vendor/twig/twig/lib/Twig/Template.php(403): Twig_Template->displayWithErrorHandling(Array, Array)
#32 /var/www/html/drupal/vendor/twig/twig/lib/Twig/Template.php(411): Twig_Template->display(Array)
#33 /var/www/html/drupal/web/core/themes/engines/twig/twig.engine(64): Twig_Template->render(Array)
#34 /var/www/html/drupal/web/core/lib/Drupal/Core/Theme/ThemeManager.php(384): twig_render_template('themes/custom/t...', Array)
#35 /var/www/html/drupal/web/core/lib/Drupal/Core/Render/Renderer.php(437): Drupal\Core\Theme\ThemeManager->render('html', Array)
#36 /var/www/html/drupal/web/core/lib/Drupal/Core/Render/Renderer.php(195): Drupal\Core\Render\Renderer->doRender(Array, false)
#37 /var/www/html/drupal/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(147): Drupal\Core\Render\Renderer->render(Array)
#38 /var/www/html/drupal/web/core/lib/Drupal/Core/Render/Renderer.php(582): Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}()
#39 /var/www/html/drupal/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(148): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#40 /var/www/html/drupal/web/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch))
#41 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#42 /var/www/html/drupal/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#43 /var/www/html/drupal/vendor/symfony/http-kernel/HttpKernel.php(156): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent))
#44 /var/www/html/drupal/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#45 /var/www/html/drupal/web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#46 /var/www/html/drupal/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#47 /var/www/html/drupal/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(99): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#48 /var/www/html/drupal/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(78): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#49 /var/www/html/drupal/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#50 /var/www/html/drupal/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#51 /var/www/html/drupal/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#52 /var/www/html/drupal/web/core/lib/Drupal/Core/DrupalKernel.php(669): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#53 /var/www/html/drupal/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#54 {main}.

#29 works for me. Thanks @juampynr

Just in case anyone is looking for a workaround

 /**
  * Implements Hook_preprocess_breadcrumb.
  */
 function HOOK_preprocess_breadcrumb(&$variables)
 {
     $route = \Drupal::routeMatch()->getRouteName();
     if ($route && $variables['breadcrumb'] && 'your_view_route_name' == $route) {
         $variables['breadcrumb'][2] = array(
                    'text' => ucwords(\Drupal::routeMatch()->getParameters('node')->get('arg_0'), '-'),
                    'url' => 'add_the_url or leave blank',
                   );
     }
     $variables['#cache']['contexts'][] = 'url';
 }

#28 works for me, but i will stick with the pre-process till it is fully tested for all scenarios.

This issue also affects views with config translation titles.

I have updated the code so that it fetches the $args using the same logic that Drupal\views\Routing\ViewPageController::handle uses, as well as caching the title statically for the issue raised in #31.

Unfortunately the use of _title isn't feasible due to potential issues with language config overrides. I think it's still worth keeping the property for API reference purposes.

Re-roll for the latest patch

At the moment special chars are double encoded to html entites. $view->getTitle() returns allready encoded html entites.
For the _title property of the route this did work, because it's value is passed through t() which implicitely converts it to a markup object. This does not hapen with _title_callback. As far as I can see there are two options: return a #marjup render array od pass the title through t(). I decided for the latter because it also enables translation... Attached is a new patch, an interdiff and a backport for the current 8.8 release.

@extralooping I would follow TitleResolver::getTitle's suggestion and return a render array instead.

I think the recommended way is to do the view translations on the config level as it's a config entity and the view title is flagged as translatable - adding the t call will trigger unnecessary translations for each language config override, and there'd be no context for the translation.

What led me to this issue was that language config title overrides were being cached in _title for all languages (e.g. if the views route cache was regenerated on language site B, site B's view title would be used on language site A,B,C,D), whereas they were meant to be language/site specific. Using the dynamic callback addresses that.

#40 works really good for me, with one issue other than the one in #41.
I think it would make sense in the _title_callback to cache the view title by the arguments as well. In a scenario when multiple breadcrumb items link to the same view and display, but with different arguments, both of the items get the same title.

The $view->buildTitle() is called for the same view two times in the same request and currently the second time it uses the cached $view_title, which is fine, but the two calls having different arguments, the title could be different also, therefore the arguments should be used as well when caching the title.

Here are the patches with the changes I mentioned in my previous comment and also with changes regarding returning a render array as metniond by @codebymikey.

Since drupal 8.9 got a beta release, this patch will need to be ported to drupal 9, but I didn't have time yet to test it so now I'm just uploading patches for 8.8 and 8.9.

The patch was re-rolled up to 9.1.x

I confirm that #44 works for me on a Drupal 8.8.x site with multiple languages.

It uses the right Views config and contextual filter argument translation depending on the selected language (in my case, a translated taxonomy term name).

Also, it fixes the issue in other places in addition to the breadcrumb.

It makes TitleResolver::getTitle() to return the correct title from everywhere it is used, as you can see with something like:

$route = \Drupal::service('current_route_match')->getRouteObject();
$request = \Drupal::request();
var_dump(\Drupal::service('title_resolver')->getTitle($request, $route));

For instance, using drupal_block() from Twig Tweak in a Twig template to display the page_title_block will now return the correct overridden title instead of the default Views one.

Updating the issue title to better reflect what is is about, it's not only breadcrumbs.

Latest patch still needs work since it's breaking substitutions in Views.

To reproduce:

• Create a taxonomy term view
• Add a term ID field
• Make it hidden
• Add a "Global: Custom text" field
• As text, put "{{ tid }}"
• Watch the view crash

When the patch is applied, the tid substitution becomes a Markup object, which creates an error because _views_query_tag_alter_condition() thinks it's a query object.

Might this get fixed by #2716019: View titles in breadcrumb and metatag title don't get properly translated?

Just tested #2716019: View titles in breadcrumb and metatag title don't get properly translated, it doesn't work with overridden Views titles AFAICS. "Static" views titles work though.

@mdupont, it did not crash when I followed your steps given in #49, after applying patch from #44. My Drupal is 8.8.6, maybe it happened on a D9?

Thanks @junaidpv, I indeed tried to reproduce on a clean install of 8.8.9-dev and did not encounter any crash.

I don't remember the setup I used last time, so maybe something else was causing the issue. Putting the status back to Needs Review, my mistake.

Note: with a multilingual site, the correct, translated views title is used in the breadcrumbs. However, when using Contextual Filters and a title override which should be an entity label, the overridden title is not translated. To determine whether it should be fixed here or in #2716019: View titles in breadcrumb and metatag title don't get properly translated.

So this time, these are the steps I took:

• Get a fresh copy of Drupal 8.8 source from git
• Launch it in a new DDEV environment
• Use the URL it gives me to install Drupal (standard profile)
• Enable the Language, Content Translation, Configuration Translation and Interface Translation modules
• Add a second language in /admin/config/regional/language (I chose French)
• Make taxonomy terms translatable in /admin/config/regional/content-language
• Create a taxonomy term, with a title like "My Term EN"
• Translate the taxonomy term to give it another label in the second language, e.g. "My term FR"
• Create a view listing taxonomy terms, showing label and ID, with a Page display with a path (e.g. /viewpath)
• Give a title to the view, e.g. "My View EN"
• Filter results to only the ones with Translation Language = current language
• Add a Contextual Filter of type Taxonomy Term ID
• Enable title override when a value is provided for this filter
• Put {{ arguments.tid }} as the title override
• Save the view
• Translate the view in the second language, translate its title to e.g. "My View FR"
• Visit /viewpath
• The title should be "My view EN"
• Visit /viewpath/1 (or whatever the term ID is)
• The title should be overridden to "My term EN". The breadcrumb may show "My view EN" as a parent, depending on your config
• Visit /fr/viewpath
• The title should be "My View FR"
• Visit fr/viewpath/1 (or whatever the term ID is)
• The title will still be "My term EN", untranslated. The breadcrumb may show "My view FR", translated correctly as a parent, depending on your config

It is indeed a must have fix.

We also require the ability to override breadcrumb with contextual filters, not just view title. That feature is present in D7. I created a thread for that #3156711: Bring back overriding breadcrumb with contextual filter and already submitted a patch. Please have look if anyone is interested.

I applied the latest patch and was then able to override the title of my view with TX term labels. Thank you for your work so far!

However @mdupont is right – the titles are not translated and that's logical knowing that the overriding value is derived from the args/contextual filter value and not from the term entity or the URL alias of the route (e.g. both /news/term-EN and it's URL alias for DE /news/term-DE will get the same 'term-EN' title override). But maybe this is out of scope here?

I think we should update this PHPDoc since we are returning an array instead of a string:

+++ b/core/modules/views/src/Routing/ViewPageController.php
@@ -3,12 +3,15 @@
+   *
+   * @return string
+   *   The view title.
+   */
+  public function title($view_id, $display_id, RouteMatchInterface $route_match) {

Updated the docs.

Hello,
I made the patch compatible for version 9.2

Tried to fix the issue in #59. Uploaded the patch.

Patch 62 cannot work.

In the latest versions of drupal, the title function has been added to ViewPageController. However, it does not take into account the contextual filter.

A getTitle function has been added in the patch to allow the contextual filter to be taken into account. Without that, the patch will be useless.

Ideally, it would probably be better to integrate the getTitle code into the title.

Here is a patch which addresses feedback from #63 and reuses the work done in previous patches.

Please review

Tested #65 and it works great for me, thank you!

The QuickEdit test failures look random to me, maybe related to some timing issues? Triggering the bot again.

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

The static caching and returning of the $view_title variable results in HTML entities not being decoded - altering to solve.

Corrected

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

This could use an issue summary update with proposed solution, remaining tasks, etc.

Still needs a test case.

Patch #74 is working. Thanks.

Typically reviews should provide more detail.

But this was tagged for tests and issue summary updates both which still need to happen.

Thanks

I know there are other tasks before this can be RTBC, but just chiming in to say that #74 worked perfectly for us on 10.2.0, thank you so much for the fix!!

Was also experiencing the same issue where the breadcrumb would refuse to use the views title defined by the override in the contextual filter settings, even with "Easy Breadcrumb" enabled.

The patch in #74 seems to work fine.

Patch from #74 works on Drupal 10.4 for us. Thanks all!

#74 unfortunatly does not apply to D11.2.0 and also not D11.2.1

This small edit to the patch of #74 should make it work on D11 (and still work on D10).

The patch stopped working because it also attempted to add a missing dot in the "handle"-functions description that was since already added in D11.

#85 applies and works with D10.5.2