Load default 403/404 meta tags when node is used for those pages

Tried to apply the patch 2904468-13.patch , getting this error :

Checking patch src/MetatagManager.php...
Hunk #2 succeeded at 495 (offset 2 lines).
Checking patch tests/src/Functional/MetatagHelperTrait.php...
error: while searching for:

use Drupal\Component\Render\FormattableMarkup;
use Drupal\Component\Utility\Html;
use Drupal\taxonomy\Entity\Term;
use Drupal\taxonomy\Entity\Vocabulary;
use Drupal\user\Entity\User;

error: patch failed: tests/src/Functional/MetatagHelperTrait.php:4
error: tests/src/Functional/MetatagHelperTrait.php: patch does not apply

Re-rolled the patch in #14 to apply cleanly to 1.x-dev

Applied the Patch (#18) metatag-2904468-load_default_404_tags-18.patch , working as expected now the metatag values are rendering from backend 404/403 metatag settings , rather than node which is specified in 404 and 403 page settings.
Adding the screenshot for the same. We can move this to RTBC+1.

Setting to "Needs Work" because
* the latest patch seems to have lost the tests from #7
* the latest patch doesn't apply on the 1.x branch, but should probably just go on the 2.x branch anyway.

Upping to "normal" because the module is not doing what it says that it's going to do.

Rerolled for v2 and includes original tests.

My apologies. I was misusing phpcs locally and didn't catch those coding standard errors. Take 2!

Prashant.c → made their first commit to this issue’s fork.

Utilized the patch supplied in #24 🐛 Load default 403/404 meta tags when node is used for those pages Needs work , generated an MR containing phpcs corrections, and performed a minor code refactor.

Thanks!

Created patch file from MR 96.

Rebased the MR and rerolled the patch file.

@ckng MR needs to target 2.1.x - can you change that? I don't have permission.

Maybe I'm the only one with this issue/request... but don't we want to show the metatags for 403/404 on the paths themselves as well?

Like when I have a node/123 configured as 404-page and gave it the alias "/404-not-found". With the newest patch I get the metatags for 404 when I visit a alias that doesn't exist, which triggers the exception and everything. But when I go to "/404-not-found" I still get the default node metatags.

My case might be a bit special, as we're doing a (kind of) static pages export. And for that I need to have the metatags on /404-not-found as well, so that page is exported with those and I can set up nginx to serve that page on a 404.

For now I'll just have a patch for me, but if you guys think that makes sense in general, I can update the MR of course.

Here is what I added to the MetatagManager.php (for anyone ending here, just like I did)

...
      elseif ($exception instanceof NotFoundHttpException) {
        $metatags = $this->metatagDefaults->load('404');
      }
    }
// below are the new cases.
    else {
      $current_path = $this->request->getPathInfo();
      $path_alias_manager = \Drupal::service('path_alias.manager');
      $system_path = $path_alias_manager->getPathByAlias($current_path);

      if ($this->pathMatcher->matchPath($system_path, $this->configFactory->get('system.site')->get('page.403'))) {
        $metatags = $this->metatagDefaults->load('403');
      }
      elseif ($this->pathMatcher->matchPath($system_path, $this->configFactory->get('system.site')->get('page.404'))) {
        $metatags = $this->metatagDefaults->load('404');
      }
    }

Attaching the patch, which is based on the patch #29, in case anyone else is in the same position as I am right now.

Why am I not just adding that into the MR? I'm not sure about the performance implications on sites that aren't exported.
Resolving the alias to the system path and comparing that agains the configures 403/404 paths... on every request (apparently multiple times). Sounds like trouble, if the page is on a prod-server with lots of requests.

So you non-export guys decide if you want that in the MR or not :D

Just found out I have to get the current request using the requestStack... TOME does magic™ with the requestStack, but since the MetatagManager was invoked before that magic™ it has loaded the old "request" into $this->request...

Yeah, this is getting more and more TOME-export-specific I guess. Can we have an event/hook in getSpecialMetatags() maybe? So other modules could also decide if it's a special request or not?