[Pagination] Lower the default max_page_size from 1000 to 200 - #4113
Merged
Merged
Conversation
1000 was picked arbitrarily and sits five times above anything else in the codebase: the workflow elements endpoint caps at 200, object dependencies at 100, the largest default option is 100 and the icon selector tops out at 120. The generic listing endpoint has no cap of its own, so this ceiling is what stops any user of any listing from asking for a page that size. 200 matches WorkflowElementsParameters::MAX_PAGE_SIZE, the highest the API accepts anywhere, and is still twice the largest default option. Admins who need more raise it; that is what the setting is for. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
🟢 Approved
The reviewed configuration, frontend fallback, tests, and documentation are consistent.
Pull request overview
This PR lowers the default pagination maximum from 1000 to 200 and synchronizes configuration, frontend fallback, tests, and documentation.
Changes:
- Updates PHP and TypeScript defaults to 200.
- Adjusts configuration tests.
- Updates the pagination documentation example.
File summaries
| File | Description |
|---|---|
tests/Unit/DependencyInjection/ConfigurationTest.php |
Updates expected defaults and validation input. |
src/DependencyInjection/Configuration.php |
Sets the backend default to 200. |
doc/03_Configuration_and_Administration/01_Configuration/08_Pagination.md |
Documents the new default. |
assets/js/src/core/app/config/app-config.ts |
Synchronizes the frontend fallback. |
Review details
- Files reviewed: 4/4 changed files
- Comments generated: 0
- Review effort level: Lite (auto)
Note
Copilot is running an experiment and ran this review at Lite.
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Changes in this pull request
Follow-up to #4109 (pimcore/platform-version#306), which introduced
pimcore_studio_ui.pagination.max_page_sizewith a default of1000.That value was picked arbitrarily and sits about five times above anything else in the codebase:
WorkflowElementsParameters::MAX_PAGE_SIZEObjectDependenciesServiceInterface::MAX_PAGE_SIZEpage_size_optionsentrymax_page_sizeis what stops any user of any listing from entering a page size in the changer, not just what an administrator may configure, and the genericCollectionParameterscarries no upper bound of its own (#[Positive]only). A ceiling of 1000 therefore lets a user ask any listing for a thousand rows, which is well past what the endpoints behind those listings are built to serve.This lowers the default to
200: the highest page size the API accepts anywhere, and still twice the largest default option. Installations that want more raise the setting, which is what it is for.Also updates the two affected
ConfigurationTestcases and the YAML sample in the documentation page.Additional info
No behaviour change for a default installation, whose options top out at 100. It only narrows the range of custom page sizes a user can type.
Verified the config tree against PHP 8.4 in a container: defaults resolve to
200, an option above the ceiling is rejected at container build, and raisingmax_page_sizealongside a larger option still validates. Codeception and the rest rely on CI.🤖 Generated with Claude Code