🇩🇪Germany @SerkanB

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?

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

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');
      }
    }

Well, if you need that I'm sure others will as well, so a MR is always welcome.

And it seems to be simple enough, shouldn't interfere with anything else.

serkanb → created an issue.

serkanb → created an issue.

I updated the info.yml, D10 is now in there.

Nice, thanks for that :D

Lets see if I get the whole "givin credits" thing right...

Another confirm on patch #6, works for me as well.

hmmm nope, not that I know of. I just didn't test it yet with a clean D10 install, as I was working on D9.

Hadn't have time to finalize it even for D9. I'll try to test it on D10, and if it works there as well, I surely can add a D10 release/add d10 as compatible.

So anyone who is looking for this, I've turned my first working state into a module : https://www.drupal.org/project/lpb/ →

It's still not 100% ready, hence the dev-release, but it works... basically.

Right now it's overriding the route to use a new Controller... but I would like to implement the whole thing as a seperate Widget for the layout_paragraphs-field, that somehow keeps the layout-functionality intact.

Issues and Patches are of course welcome :D And once we have the browser running, maybe we can integrate the browser_previewer in that module... maybe.

Sounds a lot like this issue here just with fields instead of permissions:
https://www.drupal.org/project/config_split/issues/3310931 🐛 Role/Permission are added to multiple splits Fixed

And there are probably other configurations where this happens. Anything that's shared between different entities/stuff™. It seems to be a difficult problem to solve.

Changing status to active, as my go on a fix didn't change anything :(

The easiest fix would be to implement the form_alter with the new ID and call the old form_alter...

function focal_point_form_media_library_add_form_dropzonejs_alter(array &$form, FormStateInterface $form_state) {
  focal_point_form_media_library_add_form_upload_alter($form, $form_state);
}

But this feels wrong, having some hook of a random contrib module. Is this the way to go?

Looks like this is caused by a recent change on the dropzonejs side.
There is already an issue ( https://www.drupal.org/project/focal_point/issues/3344369 🐛 Compatibility with DropzoneJS Active ) linking to the issue that caused the change ( https://www.drupal.org/project/dropzonejs/issues/3341846 🐛 Set custom form id for media library form Fixed )

So I would close this as duplicate.

@jonathan1055 you sir are correct!

Removing the patch and adding those {} works just fine.

Well then, forget what I said. Reading the docs properly would've saved me from all this.

If I remember correctly, the issue just was: if I add "@inheritdoc", I do that because there is already a doc-comment somewhere, I don't want to replicate that.

Without the return there, it did his job and told you "please write a comment!", which isn't the point of "@inheritdoc" :D (maybe even @inheritDoc ... should've added that in there as well.)

Fix for #1 works fine.

#2 I wasn't that easy, simply doing it as I described skips all the assets. That's because in the copyPath()-method the path is being altered before file_exists() is called. I left it as is (for now)

SerkanB → created an issue.