Load pages from pager within active modal

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.

Rebased onto an MR and added additional tests.

So using views_test_modal module from core
When I click the link (which has class use-ajax)
Modal opens
Clicking a page items renders some errors

Applying the patch

I get the same results.

Using content view with ajax turned off ( as the issue summary didn't mention turning it on)

Posted review on the MR

Rebased onto 11.x and changed target. There was a conflict with 10.1.x that needed resolving first. Thanks to @larowlan for helping with the git foo.

Using only this condition:
\Drupal::request()->get(MainContentViewSubscriber::WRAPPER_FORMAT) === 'drupal_modal'
seems to fail in some use cases.
I have a modal form with ajax submit and tableselect element with pager. Applying this patch, pager links get ajaxified and work well until a validation error occurs. During submit, request wrapper format is "drupal_ajax", so after validation fails condition does not pass and links don't have use-ajax class and data attributes anymore.
Adding this:
in_array(\Drupal::request()->get(MainContentViewSubscriber::WRAPPER_FORMAT), ['drupal_ajax', 'drupal_modal'])
make pager work also after a failed validation, but i don't know if this can have unwanted side effects.

Tested with Drupal 10.2.6, it works well with pager inside modal and without views. I use pager render array like this :

[
        '#type' => 'pager',
        '#route_name' => '<current>',
]

Rebased and resolved the conflicts.

Ready for another review.

Left some comments in the MR.

Feedback addressed, I tried to find why we were using olivero and I think it was mainly to demonstrate the fix works there but I think Stark makes more sense.

Drupal\Tests\file\Functional\DownloadTest pretty sure unrelated.

Rest of the feedback appears to be addressed.

+1 RTBC, works fine when the modal has a pager.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

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

MR is rebased but core pipelines are having issues atm for subsystem maintainers. If someone can click rerun on the pipeline that'd be great.

Only change I wasn't sure was instantiating $link_attributes = []; vs $link_attributes = new attribute(). But seems to return the same.

Ran the test-only job here https://git.drupalcode.org/issue/drupal-3122526/-/jobs/5648445 which gave

1) Drupal\Tests\system\Unit\Pager\PreprocessPagerTest::testPagerModalAttributes
null does not match expected type "array".
/builds/issue/drupal-3122526/core/modules/system/tests/src/Unit/Pager/PreprocessPagerTest.php:218
--
1 test triggered 1 PHP warning:
1) /builds/issue/drupal-3122526/core/modules/system/tests/src/Unit/Pager/PreprocessPagerTest.php:218
Undefined array key "class"
FAILURES!
Tests: 7, Assertions: 9, Failures: 1, Warnings: 1, PHPUnit Deprecations: 7.

Appears to be 1 thread from 2 years ago but no follow up from the response. Also not sure how to do that outside the preprocess_function. Leaving thread open but don't want to hold the ticket.

Rest appears to be addressed, LGTM.

Needs a rebase.

Rebased and squashed the MR now that everything has changed.

Seems like a good rebase

Opened 📌 Move MainContentViewSubscriber::WRAPPER_FORMAT somewhere else Active because it felt odd seeing the event subscriber constant referenced.

Committed/pushed to 11.x, thanks!

catch → closed merge request !3558

Agree with #65, appreciate the commit on this one. I lost count of the number of times I rebased conflicts here xD

Automatically closed - issue fixed for 2 weeks with no activity.