Add opt-in default for "Always open List View" in the Block Editor (#32) - #57
Open
roshniahuja wants to merge 3 commits into
Open
Add opt-in default for "Always open List View" in the Block Editor (#32)#57roshniahuja wants to merge 3 commits into
roshniahuja wants to merge 3 commits into
Conversation
itzmekhokan
suggested changes
Jul 10, 2026
Closes WordPress#32. WordPress persists this preference server-side under a shared "core" preferences scope (same for the post editor and Site Editor), so a new options-page toggle dispatches through the editor's own preferences store to turn it on for the signed-in user across every WordPress site — the same store update a manual click on that Editor Preferences toggle performs. Off by default; only ever turns the preference on, never off, and never touches the REST API or the stored JSON directly.
…, sync Safari - content.js/background.js: add a per-origin "already applied" marker so the List View default is only ever nudged on once per site, never re-forced after a user turns it back off themselves. background.js now captures the MAIN-world dispatch's actual result and only records the marker on a confirmed success. - Confirmed body.block-editor-page is present on site-editor.php at document_idle (server-rendered, already in the initial HTML) — no selector change needed. - scripts/sync-safari.sh: add the missing lib/editor-preferences.js copy and re-sync the Safari Resources mirror, which was missing the file entirely and would have thrown in the Safari service worker.
roshniahuja
force-pushed
the
feature/32-list-view-default
branch
from
July 10, 2026 17:26
aac1cde to
6946a29
Compare
scripts/package-chrome.sh copies lib/* file-by-file and was missing lib/editor-preferences.js — the Chrome counterpart of the sync-safari.sh fix. Without it, npm run package:chrome fails the verify-package integrity gate (referenced file missing), so no Chrome Web Store zip can be produced. Verified: the packaged zip now contains the file and the gate passes (23 files).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #32. Adds an opt-in, off-by-default option that turns on "Always open
List View" for the current user across every WordPress site's Block Editor
(post editor + Site Editor) — a one-time toggle instead of the per-site
manual step the issue describes.
How it works
"core"preferences scope (getPreference("core", "showListViewByDefault")— same call in both edit-post.js and edit-site.js), not purely
localStorage as the issue's acceptance criteria suggested. localStorage
is still involved as a local write-through cache with timestamp-based
conflict resolution, but the source of truth is server-side user meta,
and both are read/written together through one preferences store.
lib/editor-preferences.jsreads WordPress's own already-inlinedpreferences snapshot from the DOM (the same data
wp.datahydrates from)to check, with no REST call, whether the preference is already on.
wp.data.dispatch('core/preferences').set('core', 'showListViewByDefault', true)in the page's MAIN world — the same store action a user's own click on
that Editor Preferences toggle triggers. WordPress's own existing
debounced local-cache + REST persistence handles the actual save, so the
extension never touches the REST API or the stored JSON directly — no
risk of clobbering other saved preferences (dark mode, panel state, etc).
Data & privacy / permissions
manifest.jsonpermissions —storageandscriptingwerealready granted; the write happens through the page's own
already-authenticated
wp.data, not a new endpoint the extension calls.defaults in
wp_preferences_v1._global— no new storage keys.Open question for maintainers
The issue's phrasing implies "just make it always on." I made it an
explicit opt-in toggle instead, matching the Site Info panel / admin-bar
precedent in this repo, since it writes to the signed-in user's own
account preferences. Happy to flip it to on-by-default if you'd rather
match the issue literally.
Test plan
cd test && npm test— new smoke coverage forlib/editor-preferences.js(DOM snapshot parsing, the "needs it" gate,new-account edge case, missing-preference-key edge case)
npm run build— cleaneditor session: baseline
showListViewByDefault: false→ enable the newoption → reload the editor →
true, confirmed persisted server-side viaa fresh page load re-reading WordPress's own hydrated snapshot (not
leftover client state) → reload again, stable, no repeat writes, no
console errors