Enhancement suggestion for HTML Block Element Display Settings

HTML blocks should allow us to configure the number of elements displayed directly from the page settings.

For instance, when accessing studio/module.php?name=bx_developer&page=pages&bp_type=system&bp_page=sys_home, there should be an option within the HTML block editor to define how many elements to display.

For example, when displaying the "New Members" HTML block, users should be able to set the number of members shown. Likewise, for the "New Organizations" block, there should be an option to specify how many organizations are displayed. This feature should not be limited to specific cases but should be applicable to any HTML block across all modules.

Crucially, this functionality should not be restricted to a general module-wide setting but should be configurable at the individual HTML block level for each page. While a default value can be set globally, developers should have the flexibility to adjust this setting as needed to customize content presentation on different pages.

  • Up vote
    6
    Down vote
  • View
    815
  • More
Replies (5)

    • Hello @Romulus !

      Well, the blocks like New People can be limited with the "Number of items per page" option in the Persons settings. I guess, as the Pages app works not only with the listings then this option looks too specific.

      • Enhancing HTML Blocks in UNA CMS with Context-Specific Settings

        I understand your point, but I believe it would be highly beneficial for every HTML block to have its own settings directly within the block itself, rather than being limited to the module settings. This approach would allow users to configure different display options for the same block when used in various contexts or on different pages.

        For instance, I might want to display a banner featuring three people on one page, while on another page, I could use the same HTML block to showcase a list of 24 or 36 people, or any number I choose. This level of flexibility would be advantageous for any HTML block.

        Drupal has a somewhat similar feature. I recall working on a news website where it was crucial to display HTML blocks with varying numbers of items across different pages. Additionally, each block could have different display settings depending on the device whether for desktop, mobile, or tablet, search results or browsing.

        Another highly useful feature would be the ability to set the number of characters of text to display. Sometimes, I might only want to show a few lines of text, while other times, I might prefer to hide the text entirely and display only images or another type of content. The way content is displayed is critical for any website, as each site has its own requirements, and each client has different needs. Having multiple display options would greatly enhance customization.

        Therefore, the ability to customize the display of specific content in different contexts becomes an essential feature. While module settings can establish default configurations, I believe users would prefer to adjust the number of displayed items at the page level rather than being restricted to a global setting.

        Since HTML blocks can be duplicated and used in multiple contexts, it makes sense for them to have individual properties based on the context in which they appear. If I can rename an HTML block when copying it to another page, why shouldn’t I be able to change the number of displayed elements? This added flexibility would be incredibly useful.

        Moreover, if additional customization options were available, the possibilities for personalization would become virtually limitless. This would open the door to a wide range of design possibilities, allowing users to start with a default setup and tailor each instance of the block to suit different needs.

        • Blocks in pages builder are abstracted from the functionality of the modules. You'll notice that there are a few types of blocks but the types do not depend on the module or method.

          So, then it is up to the module to define what to return for each method. Blocks don't really "know" about various nuances of each method rendering, like whether it's a list, or text, or something else that may have own sorting settings or filters. So, as suggested the settings for blocks would normally belong to the module - so in Studio you would go to Discussions > Settings (or Settings > Discussions) and set various parameters:

          I appreciate that it would be nice to be able to set different settings for each instance of a block and have UI in the pages builder to select parameters for each method used. That would be a significant change in core logic and would likely require broad modules updates. We will review feasibility and possible options.

          • 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.

              Login or Join to comment.