Add next and previous buttons to database log entry pages

According to #2015149: Replace dblog recent log entries with a view comment #142 this is by design:

According to #1909474: Use light (lite) pager by default: Use light (lite) pager by default all core listings are now using minipagers. So agree with jibran. Lets keep the mini pager for logs too. Users can configure it to use the full pager if they need it.

I think @longwave refers when you are viewing a particular event page page, not the listing page. I think this is a valid feature request.

Working on this Feature request.

Hi,
I've submitted a merge request for review that implements navigation between database log event pages using "Next" and "Previous" buttons.

Please review and share any feedback. Thanks!

Will need UX sign off, but the issue summary seems to be void of screenshots to assist the UX team. Tagging for such

Thanks!

Thanks for the update!

I've added some screenshots showing the new navigation links added to the DB log detail page:

- Example of the “Next” and “Previous” links at the bottom of a log entry.

- Behavior at the first and last entry to show correct disabling/hiding of links.

Let me know if further clarification is needed.

@vinaygawade Thanks. Looks really good. I think the symbols next to Next > and < Prev will have to live outside the text buttons, so we can reuse translations.

I also checked if would be possible to have only one query instead of 2. But it requires the use of UNION, and there is no real gain there.

Finally would be good to have a test when there is only one entry in the logs. To verify no buttons and no errors are rendered.

Thank you @dagmar,

- Good point about the arrow symbols — I’ve removed them for simplicity, so the translatable strings can be reused.
- I agree on the single-query idea — not worth the added complexity for minimal gain.
- I also tested the case with only one log entry. On the event details page, no Previous or Next buttons are rendered, and everything works without errors.

Let me know if you have any other feedback!

Added prev/next ID handling in overview() to avoid extra DB queries in eventDetails(). Uses query params for faster navigation between log entries.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. 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.

Added updated screenshots for review.

    Db Log (Drupal\Tests\dblog\Functional\DbLog)
     ✘ Db log
       ┐
       ├ Behat\Mink\Exception\ResponseTextException: The text "Deleted user: m2oadm70 ." was not found anywhere in the text of the current page.
       │
       │ /builds/issue/drupal-3163716/vendor/behat/mink/src/WebAssert.php:907
       │ /builds/issue/drupal-3163716/vendor/behat/mink/src/WebAssert.php:293
       │ /builds/issue/drupal-3163716/core/tests/Drupal/Tests/WebAssert.php:981
       │ /builds/issue/drupal-3163716/core/modules/dblog/tests/src/Functional/DbLogTest.php:534
       │ /builds/issue/drupal-3163716/core/modules/dblog/tests/src/Functional/DbLogTest.php:422
       │ /builds/issue/drupal-3163716/core/modules/dblog/tests/src/Functional/DbLogTest.php:89

It seems one test is not passing now.

Usability review

We discussed this issue at #3523597: Drupal Usability Meeting 2025-05-16. That issue will have a link to a recording of the meeting.

For the record, the attendees at the usability meeting were benjifisher, rkoller, shaal, simohell, and worldlinemine.

We have based todays discussion on MR12089, in the following a list of details we’ve noticed:

• Previous and Next are styled as buttons, but they are actually links.
• In the current state each button only contains a button label, the user is required to read/skim the label, there are no visual cues like additional iconography.
• Since the two buttons link to other pages, strictly speaking SC2.4.4 (Link purpose - in context) applies here - after the labels Previous and Next are missing some sort of context.
• When you are on a details page and press the Previous or Next button repeatedly, you will notice that the column with the row labels is sort of uneasy and shifting constantly in width in between log messages - on some page the column gets even that narrow that the label wraps to a second line. From a readability point of view, you don’t have a fixed starting point for your eyes, you have to adjust on every page, which leads to an increased cognitive load if you are clicking through several error messages in a row (see column_width.mp4).
• If you consider the use case of a site with thousands of recent log messages, there is the problem that the Previous and Next button are not respecting the applied filters. If you filter your log messages for example for a particular error message, and then click on one of the filter results, the filter scope is being reset - pressing Previous or Next on the details page will not bring you to the next/previous log message of your filter results, but to the next log message overall.

Aside the aforementioned points we’ve also asked ourselves if there is already a pattern in Core using such a Previous and Next pattern to step through instances - but we were unable to come up with one - there is only the remotely related Pager pattern used on Views (for example on /admin/content). In conclusion, these are the points the group reached a consensus on to suggest in scope for this issue:

1. Instead of displaying links as buttons, style them as actions links (see Drupal Design System) - that would be semantically more appropriate since each of the two point to a new page. Also re-add those single forward and backward step icons shown on the Figma link.
2. Add some context to the button label by using the slightly more verbose Previous log message & Next log message as the label for the action links.
3. Let the Previous and Next action links respect a set filter value. If you are for example filtering for the type “php” with a severity of “error” and you get four matches, log message number 25, 126, 134, 175, and you click on the detail view for number 126, the behavior on the detail page should be as follows:
   • There should be a button with the label Clear filter
   • Clicking Next, forwards you to log message number 134
   • Clicking Previous twice, forwards you to log message number 25
   • Clicking the Clear filter button, the button would get hidden, and in this case the previous button would get shown again (since in the scope of the filter results 25 is the first available message and Previous button hidden) - clicking the Previous button would forward you to log message number 24, clicking the Next button to log message 26, instead of going through the four available numbers of filter results.
   • Through the display of the Clear filter button it should be self explanatory that the current scope of displayed log messages are filter matches, while when the Clear filter button is not shown the scope is all the existing log messages. But ideally that could be validated in user tests, perhaps additional (visual) cues might be necessary.

In regard to the problem with the shifting column width, we’ve thought that is not “directly” related to this issue and should probably be moved to a followup issue instead.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

In regard to the problem with the shifting column width, we’ve thought that is not “directly” related to this issue and should probably be moved to a followup issue instead.

Created the follow up for https://www.drupal.org/project/drupal/issues/3525492

In regard to the problem with the shifting column width, we’ve thought that is not “directly” related to this issue and should probably be moved to a followup issue instead.

Good point. This will be interesting to implement. Not sure if this will also require extract the logic of filtering from the dblog controller so we can reuse the logic in both the dblog details and the listing.

Also, I'm thinking this will create some caching issues to consider as well.