Yes, I know that, thank you for your answer. However, my suggestion is based on the idea that a page block within UNA CMS could inherit the property related to the number of elements to display from the originating module as a default value similar to its current functionality. My proposal extends this by allowing that default value to be overridden when creating a new page block. (or even existing ones with the possibility of reset to default)

When a new page block is generated using an existing one as a source, it effectively becomes a new entity that retains the original block’s data source and inherited properties while also allowing additional customization, such as modifying the number of display elements. Furthermore, these new page blocks can be fully customized including their appearance, name, and localization (translations), capabilities already available in UNA CMS.

A key enhancement would be introducing an inheritable property for the number of elements to display. This property would default to the original module’s setting while remaining editable for each individual block instance. Such an approach would enhance modularity and flexibility, enabling blocks to maintain consistency while supporting tailored adjustments based on specific use cases.

Moreover, implementing this functionality would open the door to new development possibilities and future customizations, allowing for more dynamic content structuring, improved user experience, and greater adaptability within UNA CMS. In the current architecture, blocks within the Page Builder are abstracted from module functionality, with settings typically residing within the module itself. Offering the ability to customize display settings on a per-block basis is crucial for dynamic content presentation and would significantly enhance overall flexibility without compromising the existing structure.

However, an even better improvement for a CMS would be if each page block could be customized at the atomic level, with the current module-level setting serving merely as a default value to be inherited by each page block. If each page block had the ability to override its inherited property, it would be a truly significant step forward. I don't think it would be a problem to add an extra table or fields to store the custom property for each page block, without compromising the existing structure. This approach would allow each page block to have its own custom settings while using the module-level setting as a default value.

Consolidating All HTML Block Settings into a Dedicated Module

The first step toward future customization i believe is to migrate and consolidate all existing settings into a new, dedicated module let’s call it "HTML Block" (or any other name, as the specific name isn’t critical). The goal is to centralize and manage settings on an individual level for every HTML block across all modules.

Current Situation

1. Page Builder Interface Settings

Currently, the Page Builder provides various settings directly within the HTML block editor, such as:

• Edit Block Settings:
• Block Title and Short Name: The title and short name displayed in the block header.
• Block Layout and Content Settings: Options to configure the block’s design and content.
• Asynchronous Mode: Toggle to enable or disable asynchronous content loading.
• Block Submenu Options: For example, selecting an inherited or tab-based submenu.
• Visibility Settings: Options to control where the block is visible (e.g., on phone, tablet, desktop, mobile app) and for which user levels (such as Unauthenticated, Account, Standard, Unconfirmed, Pending, Suspended, Moderator, Administrator, Premium).
• Additional Options:
• Content-Related Settings: Placeholder text for empty blocks, help text, and CSS classes.
• Block Cache Lifetime: Configurable duration (in seconds) for caching the block.
• Activation Status: Whether the block is active or inactive within the app.

2. Module-Specific Settings

Various modules that use HTML blocks have their own general settings, which currently exist separately. For instance:

• Persons Module:
• Number of items in the friends block.
• Number of items per page.
• Number of items in the RSS feed.
• Number of items in the showcase view.
• Number of items in the recommended view.
• Albums Module:
• Number of characters in the auto-cropped album summary.
• Number of characters in the plain album description when no thumbnail exists.
• Number of items per page.
• Number of items on the profile page.
• Number of items in the showcase view.
• Number of favorite lists per page.
• Number of items in the album card.
• Number of items in the RSS feed.
• etc

Note: These examples are merely illustrations. The approach should apply to all modules that incorporate HTML blocks.

The Proposal

Migrate and Consolidate All Settings:

The first step to future customization is to migrate all these settings currently spread between the Page Builder’s HTML block editor and various module-specific settings into one centralized, independent module (or submodule of Page Builder or/and Developer module ). This module, which we might call "HTML Block " would:

• Provide a Unified Interface:
• Group all existing settings into one dynamic system. Instead of managing settings in multiple locations, users and developers will have a single point of configuration for HTML block settings.
• Enable Dynamic Customization:
• Each module will dynamically connect to this central module to retrieve its specific settings for HTML blocks. This means that every HTML block instance can be individually configured allowing properties like the number of items displayed or text length to be adjusted on a per-block basis, even though a default value might be inherited from the originating module.
• Enhance Flexibility and Granularity:
• By centralizing these options, it becomes easier to tailor the presentation of content for different contexts and devices. Whether it’s adjusting display settings for a banner, a list, or any other block type, this approach offers granular control that benefits all modules using HTML blocks.

Key Benefits

• Unified Management:
• All HTML block-related settings are available in one consolidated interface, simplifying both configuration and maintenance.
• Dynamic Customization:
• Modules can dynamically connect to the central settings module, ensuring that every HTML block can be customized individually without conflicts from global settings.
• Enhanced Flexibility:
• This solution allows for a high degree of personalization, paving the way for advanced customization options in the future. It enables content to be tailored at an atomic level each block can have its own settings while still inheriting a default configuration from its module of origin.

By consolidating all these settings into a dedicated module, we streamline the management of HTML block settings and lay the foundation for more advanced, flexible content presentation across the entire UNA CMS.

Additionally, all the HTML block settings module could be embedded into various other modules, such as within a Page Block Builder at the Developer Html Block module level or directly into the settings of individual modules.

Each HTML block could have its own settings with default values inherited from the current configuration to ensure consistency with the existing settings, along with custom settings that allow new values to override the defaults value.

The HTML Block Module could contain several submodules or sections, each responsible for different aspects of HTML block management, providing a comprehensive solution for creating, styling, displaying, and interacting with HTML blocks.

HTML Block Submodule/section List:

• HTML Block caching : Manages block caching strategies. Also divided into display categories
• Browse caching
• Search Results caching
• etc
• HTML Block Permissions : Controls user access and role-based restrictions for block visibility and management. (already existing function). Also divided into display categories
• Browse permissions
• Search Results permissions
• etc
• HTML Block Builder : Provides an embeding interface for creating, editing, and managing HTML blocks dynamically in the Page Builder module (already existing function)
• HTML Block Analytics: Provides an embeding interface for Analytics module settings for all display
• HTML Block Developer : Provides an embeding interface for creating, editing, and managing HTML blocks dynamically in the Developer module
• HTML Block Modules Settings : Provides an embeding interface for settings, editing, and managing default value in the each module level. (already existing function)
• HTML Block Styling : Offers predefined themes, custom CSS options, and inline styling capabilities. (already existing function). Also divided into display categories
• Browse styling
• Search Results styling
• etc
• HTML Block Events : Handles JavaScript interactions, animations, and real-time event triggers. (already existing function). Also divided into display categories
• Browse translation
• Search Results translation
• etc
• HTML Block API : Facilitates structured communication with internal and external systems, enabling integration with other modules. Also divided into display categories
• Browse permissions
• Search Results permissions
• etc
• HTML Block SEO : Implements metadata management, structured data support, and indexing optimization for search engines. Also divided into display categories
• Browse SEO
• Search Results SEO
• etc
• HTML Block Automation : Supports scheduled content updates, conditional display logic, and personalized content rendering. Also divided into display categories
• Browse automation
• Search Results automation
• etc
• HTML Block Logging : Records modifications, performance metrics, and debugging events for monitoring and analytics.
• HTML Block Translation :Embed and Integrates with translation modules managing multilingual content for HTML blocks and ensuring seamless language switching. (already existing function). Also divided into display categories
• Browse translation
• Search Results translation
• etc
• HTML Block Items : Allows specific settings for items within HTML blocks, such as the number of items displayed per block (e.g., items in RSS feed, showcase view, etc.), taken from module-specific settings. Also divided into display layout categories
• Browse items
• Search Results items
• etc
• HTML Block Devices : Manages block visibility across different devices and platforms (web, mobile, app), allowing for responsive design and specific configurations per device type. (already existing function) Also divided into display categories
• Browse permissions
• Search Results permissions
• etc
• HTML Block add new: (already existing function)
• HTML Block Mode: Togle to enable or disable asyncronous content loading. (already existing function)
• HTML Block submenu: (already existing function) Also divided into display layout categories
• Browse items
• Search Results items
• etc
• HTML Block Layout: Manages block layout in different views, including:
• Browse Layout: Configuration for displaying blocks on browse pages. (already existing function) "Empty box," "Content," "Content + Padding," "Content + Background," "Content + Background + Padding."
• Search Results Layout: Configuration for displaying blocks specifically in search results pages. "Empty box," "Content," "Content + Padding," "Content + Background," "Content + Background + Padding." will fix the error from https://unacms.com/d/issues-with-una-search-results-display
• RSS feed Layout: ...
• etc
• ETC

This proposal is meant as a starting point. UNA Developers who are more familiar with the UNA CMS platform should carefully analyze and determine the best solution, given their deeper understanding of the system’s architecture and requirements. Their insights will be critical in implementing the most effective and efficient approach for this modularization.

By implementing embedding functions across all existing modules, we enable the seamless configuration of module-specific settings directly within the HTML block system, ensuring that each block can dynamically inherit and customize settings corresponding to the respective module, enhancing both flexibility and integration. This allows us to leverage existing settings and minimize the need for redundant configuration by embedding them into HTML Block submodules, where the default inherited settings from the modules can be automatically applied to HTML blocks, ensuring consistency and reducing the complexity of manual configuration. The existing settings from module configurations related to HTML blocks, inherited from previous versions of UNA CMS modules, can be automatically pulled into the embedding submodules, serving as default values. These inherited values ensure compatibility with earlier module versions, while allowing custom settings to be applied on top, providing flexibility and maintaining the integrity of previous configurations.