CoolCMS API

ArticleListTrait uses trait:short, trait:short

Table of Contents

Constants

LIST_INCLUDES  : mixed = ['translations', 'asset.translations', 'categor...
Includes of the list, the same for the plain DB path and the search endpoint.

Methods

actionList()  : void
paginationInit()  : Paginator|null
renderList()  : void
requirePagination()  : Paginator
Works like `paginationInit()`, but the paginator is required; a missing component is a wiring error.
prepareCanonicalUrl()  : void
prepareFilters()  : array<int, Filter>
Filters of the plain DB path: visibility plus full-text. The search endpoint uses only the visibility part; full-text is handled on the Api side (ES, fallback `MATCH_AGAINST`).
prepareOgDataForDetail()  : void
prepareOgDataForList()  : void
prepareOrderBy()  : array<string, bool>
preparePerPage()  : int
prepareSearchFilter()  : Filter
Full-text of the plain DB path (fallback): ES ids go to `SearchIdFilter` (visibility, pagination and totalCount stay in the DB phase 1); with ES off or down (circuit breaker) a transparent fallback to MySQL `MATCH_AGAINST`, behaving as before.
prepareView()  : void
prepareVisibilityFilters()  : array<int, Filter>
Eligibility of an article in the list (activation, publication, category, paid access).
searchViaApi()  : Article>, 1: int, 2: bool, 3: array>}|null
Searches through the Api endpoint `api/blog/article/search` instead of building the filter in the presenter. Three states:

Constants

LIST_INCLUDES

Includes of the list, the same for the plain DB path and the search endpoint.

private mixed LIST_INCLUDES = ['translations', 'asset.translations', 'categories.translations', 'tags.translations', 'region.translations', 'user']

Methods

actionList()

public actionList(int|null $page, string|int|null $category, string|int|null $loc, int|null $order) : void
Parameters
$page : int|null
$category : string|int|null
$loc : string|int|null
$order : int|null

renderList()

public renderList(int $page, string|int|null $category, string|int $loc, int $order[, int $count = 20 ]) : void
Parameters
$page : int
$category : string|int|null
$loc : string|int
$order : int
$count : int = 20

requirePagination()

Works like `paginationInit()`, but the paginator is required; a missing component is a wiring error.

public requirePagination(int $perPage) : Paginator
Parameters
$perPage : int
Return values
Paginator

prepareFilters()

Filters of the plain DB path: visibility plus full-text. The search endpoint uses only the visibility part; full-text is handled on the Api side (ES, fallback `MATCH_AGAINST`).

private prepareFilters() : array<int, Filter>
Return values
array<int, Filter>

prepareOgDataForDetail()

private prepareOgDataForDetail([BlogContentInterface|null $entity = null ][, string $titleFnc = "" ][, string $textFnc = "" ]) : void
Parameters
$entity : BlogContentInterface|null = null
$titleFnc : string = ""
$textFnc : string = ""

prepareOgDataForList()

private prepareOgDataForList([Category|null $category = null ]) : void
Parameters
$category : Category|null = null

prepareOrderBy()

private prepareOrderBy() : array<string, bool>
Return values
array<string, bool>

preparePerPage()

private preparePerPage(int $count[, int $defaultCount = 20 ]) : int
Parameters
$count : int
$defaultCount : int = 20
Return values
int

prepareSearchFilter()

Full-text of the plain DB path (fallback): ES ids go to `SearchIdFilter` (visibility, pagination and totalCount stay in the DB phase 1); with ES off or down (circuit breaker) a transparent fallback to MySQL `MATCH_AGAINST`, behaving as before.

private prepareSearchFilter(string $search) : Filter
Parameters
$search : string
Return values
Filter

prepareVisibilityFilters()

Eligibility of an article in the list (activation, publication, category, paid access).

private prepareVisibilityFilters() : array<int, Filter>

Also sent to the search endpoint: visibility is always held by the DB, ES ids are only candidates.

Return values
array<int, Filter>

searchViaApi()

Searches through the Api endpoint `api/blog/article/search` instead of building the filter in the presenter. Three states:

private searchViaApi(string $search, bool $orderChosen, Paginator|null $paginator) : Article>, 1: int, 2: bool, 3: array>}|null

(a) search without a manual order choice: orderBys = null, ES orders and paginates by score (fromEs: true); visibility is still held by the DB (filters below), (b) search with a manual choice (/o-N in the URL): orderBys from prepareOrderBy(), the DB orders, paginates and counts over the ES id set and relevance is not used, (c) without a search the caller never gets here and nothing changes.

Highlighted snippets come only in state (a); they are fragments from ES.

null means use the plain DB path: the endpoint gave no list (deny or bridge outage), or ES is down and without a manual choice the DB branch of the endpoint would return an unordered list; falling back to published descending is a deliberate behavior change during an outage.

Parameters
$search : string
$orderChosen : bool
$paginator : Paginator|null
Return values
Article>, 1: int, 2: bool, 3: array>}|null —

[entities, totalCount, fromEs, highlights]

On this page

Search results