- First commit to issue fork.
- last update
10 months ago 2 pass - Status changed to Needs review
10 months ago 8:24pm 10 March 2024 - 🇫🇷France guignonv
The default Drupal behavior is to list 50 entities per page (@see Drupal\Core\Entity\EntityListBuilder
protected $limit = 50;
). Currently, that value is hard coded in ExternalEntityListBuilder and ExternalEntityTypeListBuilder but it should rely on the inherited property (as proposed in the PR). It has nothing to deal with the default REST plugin pagination limit also set to 50 which sits there for another purpose (even if still, it's for a page limitation).If you look at the REST storage client implementation,
getPagingQueryParameters()
sets the limit to the $length variable if it is set and fallbacks to the default limit given in the storage client config. Therefore, you could set a default value of 100 in the storage client, it would not change the number of external entities displayed on the listing page as the limit value comes from Drupal entity listing system itself. The default limit provided by the storage client config is there when the client is called by other applications in other modules if the caller forgot to give a length limit. It avoids querying too many entities from the remote source at once, which may not work.However, we could argue that there should be a "hard limit" setting in the REST client because some REST services may force a limitation (ie. you ask 50 elements but the server only allows 10 at once for instance). Then, that limit should be taken into account by the storage client when
getPagingQueryParameters()
is called with a $length larger than that hard limit: the client would have to call the remote source several times with the lower limit to fulfill the requested number of items. But that's a different issue which should be a feature request. Feel free to submit it...