Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 11/30/2025 in all areas

  1. Nested Checkboxes An inputfield for Page Reference fields that groups options by their parent page, and optionally by grandparent page too. This can help editors understand the grouping of the selectable pages, and also makes it quicker for an editor to select or unselect an entire group of pages. The checkboxes at the parent and grandparent level are not for storing those pages in the field value - only for quickly selecting or unselecting groups of pages at the lowest level of the hierarchy. For example, in the screen recording above the "Cities" Page Reference field allows only pages with the "city" template, and the pages at the country and continent level are not included in the field value. The inputfield is only for use with Page Reference fields because the structure comes from the page tree. Requires PW >= v3.0.248. Configuration For each field that uses the inputfield you have these options: Checkboxes structure: choose "Parents" or "Parents and grandparents". Collapse sections that contain no checked checkboxes: this option makes the inputfield more compact. There are also the standard column width and column quantity options familiar from the InputfieldCheckboxes inputfield. These apply to the selectable pages at the lowest level of the hierarchy, and the structure is arguably more readable when these are left at their defaults. https://github.com/Toutouwai/InputfieldNestedCheckboxes https://processwire.com/modules/inputfield-nested-checkboxes/
    3 points
  2. @bernhard I completely forgot about this post and ended up with a solution. I do have a default block and did implement this as you described. Interestingly I did this on my own having missed your reply. So we were thinking in the same direction.. This is ultimately what I came up with and this made it much easier to implement a solution and with less effort. This is a simple example of a block with an image marquee. I only want the block to render if there are images that will show up on the page. <?php // rest of block... /** * Renders this block if conditions are met */ public function renderBlock(): string|Html { if ($this->images->count()) { return ''; } parent::renderBlock(); } // rest of block... I added a renderBlock() method that overrides the parent Block::renderBlock(). It contains all of the logic that determines if a block will render. For a complex block that has multiple fields that need to be checked this can be very helpful. It is also very clean and simple since that method is automatically called when RPB renders blocks anyway. I think this is better than an entirely new method like shouldRender() In my case there are blocks which have an ASM page select. The pages that can be selected may become unpublished or hidden which will remove them from the selected pages. If there are no pages left to render then renderBlock() will return an empty string and prevent it from rendering without any need to go through the site and hide blocks that don't have any pages. This allows for dynamic changes in content and the block always behaves as needed. Thank you for working on a solution and apologies that I missed it!
    1 point
  3. Actually class_exists() should work, but WillyC missed an important part. ProcessWire doesn't include module files that aren't autoload unless some information about them is requested, like $modules->getModuleInfo("className"), or the like. In the same manner, a class_exists("className"); call triggers the autoload mechanism and causes the file to be loaded. But you can prevent that by specifying false as argument 2 to class_exists(): if(!class_exists("ModuleName", false)) { // module is not loaded }
    1 point
×
×
  • Create New...