Layers Of Technical Responsibility

I have defined here a new way and a new arrangement of how websites will be structured in the future and how responsibility will be shared between themes and plugins. I have evaluated it thoroughly and made a solid decision, but I’ll finally see if it works as expected on the next projects.

This is the entirety of the logical framework for themes and plugins. Despite its initial appearance of complexity, the system is straightforward, adaptable, efficient, and above all, future-proof.

1. Pipeline: Dev > Staging > Production
   Define the exact process for pushing and pulling databases, files, and uploads with ease.

2. Basic Page Templates and Essential Elements
   A theme is a place where skeleton page-templates and basic patterns are located. “Skeleton” page templates refer to the default layout of the header, footer, single page template, 404 template and similar. Users are encouraged to customize these as needed, which is now easily achievable as the theme provides a foundation for such modifications. Complete support for theme.json is also crucial as it enables proper propagation of global customization on both front-end CSS and within the editor. A theme is also responsible for allowing users to choose global colors and basic styles for essential elements, buttons and similar, but nothing more. While fonts can be also defined within the theme, a standardized official companion plugin is favorable.

   1. Theme: Frost Theme
   2. Companion Plugin: Create Block Theme, used primarily for fonts
   3. Tech Note: Avoid adding any build processes, no SCSS generation or minification, as these should be implemented through plugins whenever possible.

3. Navigation Clarification
   Although it may appear that navigation is a part of the theme, it is actually comprised solely of “Nav” blocks and should thus be styled through plugins rather than the theme itself. In terms of styling, the theme will provide basic defaults, such as a CSS reset, but not much more than that.

4. Customizing Core Blocks
   This is the point at which responsibility is transferred to the blocks and subsequently to the plugins. Commonly there is a need to tweak core blocks in small ways, such as by implementing some improvements that do not hinder further development and which are even expected to be incorporated into future Gutenberg updates. E.g., the responsiveness of core blocks, etc.

   1. Plugin: Twentig, to enhance all core blocks to a certain extent
   2. Tech Note: Although Twentig provides its font manipulation system, this is already properly addressed through the “Create Block Theme” plugin in a previous steps.

5. The Work Stage
   At this point, we are using Block Patterns, Custom Blocks and Reusable Blocks with pre-defined CSS styling modifiers aka CSS classes. This is the layer where users work and write most of the time. They receive predefined already styled patterns, as well as custom blocks if needed, while also being able to create their reusable blocks when necessary. Every pattern/block is provided with a modifier in a form of predefined CSS classes specific to that pattern, and with these modifier styles user can then further customize block appearance and behavior.

   1. Plugin: Plain Classes or “Classy” plugin, used for simplified input of CSS modifier classes from a preset list.
   2. Tech Note: Developer creates CSS styles that users can use but can’t modify, and add them to the system through plugins alongside patterns and blocks he has created as they are all part of the same package. Besides “classic” CSS, a developer is also allowed here to use Tailwind CSS which we will mention in later steps.

6. Copy-Pasty Stage, with the help of Tailwind CSS
   We are using Tailwind CSS as the pre-final CSS override and for copy-pasting components. The end user will use it inside the Gutenberg editor and will often copy-paste Tailwind components from various public-domain sources. Since the structure and styling are in the together in the same place, everything will properly fit and insert into the content. Plugin: Winden, as Paid plugin Tech Note: It is important that these styles override previous CSS styles, and this is a goal to strive for.

7. The Sparkles Stage
   This is a moment where the user can employ blocks with animations and attractive styling. These blocks are presented either as individual plugins for each block or as part of some block collection. When using a plugin collection, it’s important to identify and stick to just one, as having more can lead to user confusion and even site sluggishness. Plugin: Greenshift plugin, with a bunch of attractive blocks for advanced fancy effects if needed. Tech note: It’s crucial to ensure that the block collection doesn’t add anything to pages where the blocks aren’t used. Surprisingly, not many block collections work in this proper way.

The system is designed to be easy to understand and use, and its future-proofing capabilities ensure that it will be useful for the foreseeable future.