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

@@              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     

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.

• ❄️ 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.

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.

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.

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)

After Fix (Just visibility change)

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,

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

@alexWinterjuice if you're able to confirm your WordPress.org username (and ideally link it with your GitHub account), then I can ensure its properly credited in the AI plugin release (and associated AI Contributor badge)... thanks!