Ajax link flag does not work in view with ajax enabled.

Hi topsiteweb,

May I ask you to confirm something about the error report?

Path: / lag/flag/bookmark/401?

Is that correct "space" lag/flag --- that is suspicious -- things stand no chance of working with that mistake in code.

I was having this same issue and it turned out to be because of the Views Ajax History module

This patch fixed it for me for anyone stumbling on this issue https://www.drupal.org/project/views_ajax_history/issues/2913388#comment...

@drclaw, thanks for posting.

I just want to be careful when unpicking what maybe multiple bugs or different user experiences seeing different things

Here is a timeline

1) This issues is created.

2) We have revamped -flag's usage of Drupal.ajax.WRAPPER_FORMAT ( #2834455 )

3) drclaw's confirmation of the problem.

Can you post what version of flag you are using.. is it latest HEAD [ ie after 2834455 ] or a tagged version?
I am trying to discern if it is a recent change to routing, in a later issue (2) , that is causing a second separate problem.

Can you comment on the URL that was causing problems
I wonder in relation to the "*slash* *space* lag" string problem I was talking about in #2. Was that also a problem for you

Hey @martin107

I'm on the 8.x-4.x development branch at commit dd511975ef69acafd8381fe0e230ae5a7e60d900

I can confirm that I don't have the same url issue that the OP has in the issue summary /flag/unflag/bookmark/1234?[query params etc...]. I really think that's a typo or some kind of copy and paste error in the IS because the issue they're describing fits the bug I was having exactly. Basically the views_ajax_history module was overriding every ajax request's url with view's ajax path instead of just views ajax requests. It's done in the beforeSend callback which makes for a couple of confusing error messages because of the way views validates the ajax requests and the way jQuery reports ajax fails.

• First, the ajax request url is replaced with /views/ajax?_wrapper_format=drupal_ajax
• Then the views ajax controller looks for a view name and display id in the request but can't find it so returns 404 (seems like the wrong error code IMO)
• THEN JQuery reports the error on the original path

The patch I linked to just validates that the ajax request is a views ajax request before replacing the url and the problem goes away.

Hope this helps!
drclaw

I'm on the 8.x-4.x development branch at commit dd511975ef69acafd8381fe0e230ae5a7e60d900

... it was before the recent commit rejigging of control logic using WRAPPER_FORMAT

Thanks also for the detailed report... is did help.

As well as fitting the bug in the views_ajax_history module - There a plenty of ways of triggering a 404 response

- in terms of bad code and developer / infrastructure error.

6 years without any activity. I think we can close it as outdated. Please reopen if needed.

I am not sure how you tested this but I am seeing the exact same issue. I am trying to create a bookmark by code for groups. From what I see I should be able to just use a hook preprocess group then add the flag to the twig template.

After writing the code I ended up with the same results as the title of this issue:

Type page not found
Date Tuesday, March 11, 2025 - 13:54
Location https://localhost/flag/flag/bookmark/2860?_wrapper_format=drupal_ajax&de...
Referrer https://localhost/admin/reports/dblog/event/703
Message /flag/flag/bookmark/2860?_wrapper_format=drupal_ajax&destination=/customer/acquisition-service-fas&token=Yz12EQbsQsAf4Ro5JtQyYDUAAbO2mpC1en24tGZjt5A

I thought I would give more context around how this was replicated. I found that I can save a bookmark by writing out the save object. The problem seems to come from trying to create a link. The following is the code I'm using to create that link:

function [hook]_preprocess_group(&$variables){

$group = $variables['group'];

// add a flag link for bookmarks
$flag_link = [
'#lazy_builder' => ['flag.link_builder:build', [
'group', //also tried with $group->getEntityTypeId(),
$group->id(),
'bookmark',
]],
'#create_placeholder' => TRUE,
];
$variables['flag_link'] = $flag_link;

This creates the link from the template by using {{ flag_link }}. After clicking on that link however I get the error described on this issue. I found that if I create my own save it seems to save the flag just fine with the following code:

$flag = \Drupal\flag\Entity\Flag::create([
'id' => $group->id(),
'entity_type' => 'group',
'bundles' => [
'customer',
],
'flag_type' => 'entity:group',
'link_type' => 'reload',
'flagTypeConfig' => [],
'linkTypeConfig' => [],
]);
$flag->save();

So it would seem if I want to bypass this issue I'll have to create my own links to save and remove. I hope this helps debug the issue for others.

Having updated from 8.x-4.0-beta5 to 8.x-4.0-beta6, we've started seeing this.

We do have a patch applied for #3062604: Allow AjaxResponse to be altered - possibly related?

Looking at the difference between beta5 and beta6, one significant difference seems to be the changes in flag.routing.yml.

The 404 errors that we are seeing are on the old paths, e.g. /flag/unflag/favourite/269851

Having dug a little further, we are using flag_block, so our problem seems to be with that module - see #3515138: Compatibility with Flag 8.x-4.0-beta6

The patch on #3515138: Compatibility with Flag 8.x-4.0-beta6 solved the problem for us.

Yes, 8.x-4.0-beta6+ versions of Flag have a viewmode parameter. Please update your custom code or ask the maintainers to update the contrib modules for compatibility with Flag 5.x