Problem/Motivation

It turned out, that for layouts and landing pages as most important component will be block that displays content lists (for example, articles, media entities, etc.).

Proposed resolution

Implement block list with following configurable features:

  1. Source list - allow selection of list that should be used to provide source for list of entities. List can provide different types of entites. List can be provided from different sources, view defined lists, search defined lists, ad-hoc defined lists, etc. For POC implemenation view defined lists will be used.
  2. Limit - number of elements that will be displayed in list block
  3. Overwrites - manually defined entities/blocks that will be displayed on specific places. For entity: entity|position; for block: block|config|position
  4. Unique entites - flag that will define if list block displays unique entities accross whole page.
  5. View mode - since list with overwrites can provide multiple entity types, view mode selection should provide multi selection of view modes. One view mode per entity type.

Comments

mtodor created an issue.

mtodor’s picture

mtodor commented

According to ideas proposed in Vienna DrupalCon 2017 BOF listed in #2904129-5: [META] Landing Pages and Layouts, list block should be differently implemented and based on core views module.

According to that, we could change proposal to following:

  1. Source list - will not be selected, since that will be actual view used to generate list block
  2. Limit - already existing part of view defintion
  3. Overwrites - best suitable solition is to use views style plugin, where we can define overwrite list. In style plugin internally, filters has to be used to exclude manually picked entities from actual list returned by view defintion. This solution is also suitable for correct paging (if we define that maunally picked entites are visible on every page)
  4. Unique entites - for this solution something like "views_exclude_previous" could be used
  5. View mode - already existing part of view defintion

This feature set would match major requirements for list block.

Main missing parts are:

  • nice and simple user interface. Views creation form is to complex for end users (that are editors).
    We need a simplified form to create list block and that could be the first step in views creation wizard.
  • additionally, that form should be exposed in frontend, so that user can create ad-hoc views without going to backend views administration page.