Problem/Motivation

Here we are planning version 2.x release.

Upgrade documentation from 1.x version is here.

Plan for 2.x

General intention for 2.0 release is to update to Bootrstrap 5, clean and improve curent code and keep adding new features to a minimum.

More investigation

Remaining tasks

User interface changes

API changes

Data model changes

Comments

pivica created an issue. See original summary.

pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
miro_dietiker’s picture

About components: We need to find a process to deal with components that are distributed across multiple origin repositories.
If you have a Website and a Shop area, you don't want to load the shop related assets everywhere. With many optional parts, the global monolythic asset is getting huge.

Loading too many micro components contextually also seems to be the wrong approach as this leads to too many different CSS aggregation variations. Then caching them doesn't work.

So the framework and patterns we recommend should result in chunks of separation that make sense, where you can deal with larger optional components and still benefit from feasible stable static asset caching.

pivica’s picture

> About components: We need to find a process to deal with components that are distributed across multiple origin repositories.

Some initial thoughts

The pattern approach is defining atoms, molecules, organisms, templates and pages.

Bootstrap is defining layout, content, components and utilities https://getbootstrap.com/docs/4.4/getting-started/introduction/.

Bootstrap content is mostly atoms from my perspective. Bootstrap components are molecules and some atoms (for example button is an atom for me).

Bootstrap layout and utilities are similar i would say. We do not use layout by default in a base theme and we use some utilities, we let child theme define layout rules as they like and load additional utilities as needed. I don't see any problem with this approach currently and would keep this if others are not objecting, and try to keep minimal utility loading as much as possible.

It makes sense to me we always load all atoms and molecules styles by default.

Organisms are stuff like header, footer, nodes, etc. We should probably define libraries for styles/behaviours and load these libraries in respective organism templates.

In this way, shop card and shop product page styles would be loaded only if/when they are needed.

Thoughts?

pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Version: 8.x-1.x-dev » 2.x-dev

Added 2.x branch so we can group issues more easily.

pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Title: [META] Ideas for version 2.x » [META] Plan for version 2.x
Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes
pivica’s picture

Issue summary: View changes