The block is described as "This embeds a catalogue category's entries into the page.".
If you want to embed from multiple categories, you need to use the Selectcode parameter, to override the category ID passed.
The narrow in config option is for the module. Generally it's expected a link from a block won't link back to the same page the block is on with the block being different. Blocks are generally not considered a primary user interface component, they're an interface into some other part of the system.
Thanks for the pointer, I knew I'd managed it somehow before (I think by adding each subcat ID). I just added * in the Selectcode field and that lists everything in subcats. Problem solved :)
The easier things are to achieve, the likelier people are to adopt and if if things don't seem to work out of the box people may get frustrated and give up. I think this block should show all entries in subcategories and have a way to filter out any unwanted. I've used this CMS for quite a while now and after moving some entries it even had me baffled until I remembered the * and figured I'd try it out.
I think for the vast majority of people, categories are used for navigation, not just as some way of logically classifying things. Especially for the simpler use cases we promote where catalogues are used for something like a directory.
Hence, most people will not want to show all entries from subcategories under one listing.
Further, the block literally is "catalogue category embed", so it's baked into the name already.
Also, the block doesn't have a catalogue name parameter. It gets the catalogue name from the category supplied. So if we made it by default to show entries from all categories we'd want to change it to take a catalogue name instead of a category name. But then for the case of someone wanting the current behaviour, these users would then need to be supplying both a catalogue name and a category name. And then there's the consideration of what happens if someone specifies a catalogue name and then a category ID from a different catalogue (probably we'd just throw an error, but it's a further consideration).
I think the only resolution would be to create a second block. But that's expanding the scope of the product (bloat), for a use case that can already be achieved with a little more work.
Thus, I have just documented it better:
https://gitlab.com/composr-foundation/composr/commit/c5359df4c8be36597b8c19856532564373bb2aab
The block is used by default on the site zone welcome page and my concern was that an end user may organise their entries into categories and wonder why they are no longer showing on the default block but the tutorial should help out in that case.
Ok well in v11 the plan is for it to have a simpler default of a tile-based system that shows ALL content, so that'll deal with that particular problem.
If you want to embed from multiple categories, you need to use the Selectcode parameter, to override the category ID passed.
The narrow in config option is for the module. Generally it's expected a link from a block won't link back to the same page the block is on with the block being different. Blocks are generally not considered a primary user interface component, they're an interface into some other part of the system.
Hence, most people will not want to show all entries from subcategories under one listing.
Further, the block literally is "catalogue category embed", so it's baked into the name already.
Also, the block doesn't have a catalogue name parameter. It gets the catalogue name from the category supplied. So if we made it by default to show entries from all categories we'd want to change it to take a catalogue name instead of a category name. But then for the case of someone wanting the current behaviour, these users would then need to be supplying both a catalogue name and a category name. And then there's the consideration of what happens if someone specifies a catalogue name and then a category ID from a different catalogue (probably we'd just throw an error, but it's a further consideration).
I think the only resolution would be to create a second block. But that's expanding the scope of the product (bloat), for a use case that can already be achieved with a little more work.
Thus, I have just documented it better:
https://gitlab.com/composr-foundation/composr/commit/c5359df4c8be36597b8c19856532564373bb2aab