Guidelines: Improve guideline revision UX

[aswasif007]

What?

Related issue: #76384

Improves the Content Guidelines revision history UX: revision list is now server-side paginated via the API, the revision-history screen persists in the URL so it survives page refresh, and a column alignment regression is fixed while removing fragile CSS overrides.

Why?

Revision history previously loaded all revisions in one request, which does not scale. Navigation to revision history was not reflected in the URL, so refreshing the page would lose the current screen. Column alignment in the revision table had regressed and was being patched with brittle CSS overrides.

How?

• Pagination: RevisionHistory calls fetchContentGuidelinesRevisions with page and perPage from the current DataViews view. The API response’s total and totalPages are passed as paginationInfo to DataViews so the table shows correct pagination and fetches only the current page. When filters are active, client-side filterSortAndPaginate is still used and its pagination is shown.
• URL persistence: The Navigator’s initialPath in stage.tsx is derived from the view URL search param (e.g. ?view=revision-history). When opening revision history, actions-section sets view=revision-history via history.replaceState before goTo('/revision-history'). When leaving revision history, the back button clears the view param. Refreshing with ?view=revision-history keeps the user on the revision history screen.
• Column alignment: Revision history layout and DataViews wrapper styles in style.scss are adjusted so column alignment is correct without fragile overrides; redundant or problematic CSS is removed.

Testing Instructions

1. Open the Content Guidelines page (e.g. from the relevant admin entry point).
2. In the Actions section, click View history to open Revision history.
3. Confirm the URL includes ?view=revision-history and the revision table loads with pagination (if there are enough revisions).
4. Change page in the table and confirm the list updates (API is called for the new page).
5. Refresh the page and confirm you remain on the Revision history screen.
6. Click the Revision history back link and confirm the URL no longer has view=revision-history and you are back on the main guidelines view.
7. Confirm the Date and User columns in the revision table are aligned correctly and the layout looks correct.

Visual Changes

State	SS
Before
After
Before
After
Before
After

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: aswasif007 <aswasif007@git.wordpress.org>
Co-authored-by: aagam-shah <aagam94@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[aagam-shah]

Thanks for the PR Wasif, let me look into it!

[aagam-shah]

Thanks for working on this, @aswasif007 ! The pagination and URL persistence are great improvements. I've left a few comments inline — nothing major, mostly around hardening the URL param handling and keeping filtering consistent while we move to server-side.

[aagam-shah]

🚢

[andrewserong]

This looks pretty good to me. The only real concern I had is that the URL params and window history appear to be manually updated in a fairly granular way. Was there a reason to do it that way, versus either a) re-using the @wordpress/route hooks like useNavigate and useSearch or b) constructing things using the @wordpress/url helpers if you need to do things manually?

While the manual approach is probably okay in the shorter-term (I know we're only dealing with on sub-screen here), there've been a couple of other times when subtle bugs have been introduced in Gutenberg due to manual routing behaviour, so I wondered if we can re-use other patterns here.

Probably only really a concern if you wind up adding more complex behaviour / screens / nesting, etc, but just thought I'd mention it as sometimes these bits of complexity can creep up as features expand. Apologies if I'm being a bit nitpicky!

This is all testing well, though, and not a blocker to landing IMO.

---

Separately to this PR (it isn't introduced here) but I think I noticed a bug where the revision datetime is being displayed in UTC rather than the local time. Can you replicate or is it just me?

I.e. I did this revision at 4:47pm in my local time (UTC + 10), but it's showing at 6:57am:

[andrewserong]

I'm curious, why is this needed? I haven't seen it elsewhere in the Gutenberg repo aside from the content guidelines routes, so I assumed this would already be set in the build environment?

I.e. here:

gutenberg/packages/babel-preset-default/index.js

Line 91 in 4f85281

runtime: 'automatic',

And wp-build should be setting it, too, I think:

gutenberg/packages/wp-build/lib/build.mjs

Line 1349 in a473a4c

jsx: 'automatic',

[aswasif007]

We added this to fix this lint error:

'React' refers to a UMD global, but the current file is a module. Consider adding an import instead.

We couldn't figure out why this error was happening....but it doesn't happen to any other module in the repo. We'd appreciate it if you have some insights.

[andrewserong]

We couldn't figure out why this error was happening....but it doesn't happen to any other module in the repo. We'd appreciate it if you have some insights.

Interesting! I wasn't able to reproduce that, but I've put up a PR over in #77255 to try removing the pragma. Let's see where the linting issue shows up, as that might help us debug!

[andrewserong]

Having a separate function for determining the initialPath feels a tiny bit overkill to me. I'd almost be inclined to set this kind of thing up in route.ts, and/or use a simple useSearch at the top of this component instead of requiring a full getInitialNavigatorPath function.

But just a thought, not a blocker.

[aswasif007]

I couldn't get useSearch to work here. Not sure if it has to do with the new admin-ui layouts. useSearch doesn't catch the param.