AI Request Logs: column “move left / move right” has no effect

[Trushiv04]

What?

Closes #667

Fixes the AI Request Logs table so that "move left / move right" column reordering persists instead of snapping back to the default order.

Why?

In LogsTable.tsx, onChangeView ran sortFieldsByCanonicalOrder() on every view update, which re-sorted the fields back to DEFAULT_VIEW_FIELDS immediately after the user reordered a column. As a result, column order changes had no effect.

How?

Removed the canonical resort from onChangeView so the user's chosen field order (nextView.fields) is preserved. The initial field order is already set to DEFAULT_VIEW_FIELDS when state is initialized, so canonical ordering on the first render is unaffected. The now-unused FIELD_ORDER map and sortFieldsByCanonicalOrder helper were removed.

Use of AI Tools

AI assistance: Yes
Tool(s): Claude
Used for: Locating the cause in onChangeView and drafting the fix. Final implementation and manual testing were done by me.

Testing Instructions

1. Open AI Request Logs in wp-admin with at least one log entry
2. Open the column header menu on any column (e.g. Provider)
3. Choose "Move left" or "Move right"
4. Confirm the column order changes and persists (no snap-back to default)

Screenshots or screencast

After the fix column reordering now persists:

Screen.Recording.2026-06-04.at.6.59.45.PM.mov

Changelog Entry

Fixed - Column reordering in the AI Request Logs table now persists instead of resetting to the default order.

[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.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @alexWinterjuice.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

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

Unlinked contributors: alexWinterjuice.

Co-authored-by: Trushiv04 <trushiv@git.wordpress.org>
Co-authored-by: dkotter <dkotter@git.wordpress.org>
Co-authored-by: hbhalodia <hbhalodia@git.wordpress.org>

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.68%. Comparing base (64e8032) to head (873de11).
⚠️ Report is 2 commits behind head on develop.

Additional details and impacted files

@@              Coverage Diff              @@
##             develop     #669      +/-   ##
=============================================
+ Coverage      74.57%   74.68%   +0.10%     
  Complexity      1754     1754              
=============================================
  Files             85       85              
  Lines           7548     7549       +1     
=============================================
+ Hits            5629     5638       +9     
+ Misses          1919     1911       -8     

Flag	Coverage Δ
unit	74.68% <ø> (+0.10%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[dkotter]

In testing, this does now allow you to change the order of these columns but unless I'm missing something, the order does not persist beyond the first page load. If I change the order and refresh, the order reverts back. Should we be trying to save the order for future page loads?

[hbhalodia]

In testing, this does now allow you to change the order of these columns but unless I'm missing something, the order does not persist beyond the first page load. If I change the order and refresh, the order reverts back. Should we be trying to save the order for future page loads?

Hi @dkotter, I guess yes that's the ask in issue ticket. If we notice the DataViews in the Appearence --> Editor --> Pages, the column order you change and then reloads it would be persistent for that user on page loads.

IMO, if we are providing this order, then we should same this somewhere else, we can remove the order field and make it fixed. The UX would be better either ways.

[Trushiv04]

thanks! @dkotter You're right the previous version only kept the order for the current page view.

I've updated the PR to persist column order across page loads. The order is now saved to localStorage as part of logsQuery (the same mechanism that already persists filters and search), so it survives refreshes.

Changes:

• Added fields to the LogsQuery type and default query
• Added validation in normalizeLogsQuery so only known fields are restored (falls back to default order if the stored value is incomplete or corrupt)
• viewToQuery now captures the field order, and queryToView reads it back

Tested by reordering columns, refreshing, and confirming the order persists.

[hbhalodia]

Hi @Trushiv04, Thanks for the PR. Can we also update the column visibility in the same PR?

For example, please refer the screencast. When I update the column to hide, and refresh it again, the column is visible again. If we can land a fix within the scope of this PR would be good IMO. Because both are same issue and would use similar logic, so we can include this in PR.

Before Fix (with this PR change)

Screen.Recording.2026-06-05.at.11.32.02.AM.mov

After Fix (Just visibility change)

Screen.Recording.2026-06-05.at.11.20.15.AM.mov

Can you please update the PR with a fix. This is because, if the user update any column to hide, then loads the page, the column order changes are lost they are not persisted.

I would add the same thing in issue description, so issue author can update the description.

Thanks,

[Trushiv04]

Thanks @hbhalodia! You're right they're the same underlying issue, so it made sense to handle both here.

The root cause was in normalizeFields: it required the stored field list to match the full default length, otherwise it reset to all columns. When a user hid a column, the shorter list was treated as invalid and all columns came back on reload.

I've updated it so a shorter field list is treated as valid (the user may have intentionally hidden columns). It now only falls back to the default order when the stored value is missing or contains nothing valid.

So both column order and column visibility now persist across reloads.

Tested:

• Reorder columns → refresh → order persists
• Hide a column → refresh → column stays hidden