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.