feat(plugins): add where filter to ContentListOptions#540
feat(plugins): add where filter to ContentListOptions#540ascorbic merged 2 commits intoemdash-cms:mainfrom
Conversation
Exposes `where: { status?, locale? }` on the plugin-facing
ContentListOptions so plugins can narrow `ContentAccess.list()` results
at the database layer. The underlying ContentRepository.findMany
already supports both filters (plus authorId) — this PR only plumbs
the commonly-needed subset through the public API.
Without these, plugins either (a) filter in userland, which still pays
for pulling every row across the plugin boundary, or (b) drop to raw
`ctx.db` access, which defeats the purpose of the typed API.
Follow-up to Discussion emdash-cms#530.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: 4ff98d0 The changes in this PR will be included in the next version bump. This PR includes changesets to release 9 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
@emdash-cms/admin
@emdash-cms/auth
@emdash-cms/blocks
@emdash-cms/cloudflare
emdash
create-emdash
@emdash-cms/gutenberg-to-portable-text
@emdash-cms/x402
@emdash-cms/plugin-ai-moderation
@emdash-cms/plugin-atproto
@emdash-cms/plugin-audit-log
@emdash-cms/plugin-color
@emdash-cms/plugin-embeds
@emdash-cms/plugin-forms
@emdash-cms/plugin-webhook-notifier
commit: |
There was a problem hiding this comment.
Pull request overview
Adds plugin-facing query narrowing to the plugin content API by introducing a where filter on ContentListOptions, allowing ContentAccess.list() to push common filters down into ContentRepository.findMany() (SQL-layer filtering, pre-pagination).
Changes:
- Introduces
ContentListWhereand addswhere?: ContentListWheretoContentListOptions. - Plumbs
options.wherethroughcreateContentAccess().list()intoContentRepository.findMany(). - Adds a changeset bumping
emdashminor for the new plugin API surface.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| packages/core/src/plugins/types.ts | Adds ContentListWhere and exposes where on ContentListOptions for plugins. |
| packages/core/src/plugins/context.ts | Forwards ContentListOptions.where to ContentRepository.findMany() during listing. |
| .changeset/content-list-where-status.md | Declares a minor release and documents the new where option for plugins. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| const result = await contentRepo.findMany(collection, { | ||
| limit: options?.limit ?? 50, | ||
| cursor: options?.cursor, | ||
| orderBy, | ||
| where: options?.where, | ||
| }); |
There was a problem hiding this comment.
ContentAccess.list() now forwards options.where down to ContentRepository.findMany(), but the integration tests for plugin content access currently only cover unfiltered listing. Please add a test that asserts where.status and/or where.locale actually narrows results (and that pagination/cursor behavior is consistent when filtering).
There was a problem hiding this comment.
Added 5 integration tests in tests/integration/plugins/capabilities.test.ts covering where.status, where.locale, combined filters, and cursor pagination with filters applied (4ff98d0).
ascorbic
left a comment
ascorbic
left a comment
There was a problem hiding this comment.
Can you add a test too please
- Removes the verbose docblock on ContentListWhere per @ascorbic review. - Adds five integration tests covering where.status, where.locale, the combined filter, and cursor pagination under a where clause (per Copilot review).
Done. |
What does this PR do?
Adds
where: { status?, locale? }to the plugin-facingContentListOptions, letting plugins narrowContentAccess.list()results at the database layer instead of pulling every row and filtering in userland.The underlying
ContentRepository.findManyalready acceptswhere.status/where.locale/where.authorId(packages/core/src/database/repositories/types.ts:66) — this PR only plumbs the commonly-needed subset through the public API.authorIdis left out for now since no current ask requires it; easy follow-up if someone needs it.Why: today, a plugin that wants "published items only" has to pull every row (drafts, trashed, everything), filter in memory, and discard most of them. On a site with thousands of drafts this is wasteful and paginates wrong (the cursor counts pre-filter rows). A
where.statusfilter pushes the narrowing into the SQL query, which is what the repository was designed to do.Discussion: #530. Companion PR #539 handles the
localefield addition toContentItem.Type of change
Checklist
pnpm typecheckpasses (core)pnpm formatrunemdashminor)AI-generated code disclosure