I think its personal preference if the module should not be displayed at all if there are no similar items or if it should be displayed as you suggest with that error message.

By changing it now you are potentially changing the display of every site using this module as soon as they update Joomla. So as a result I am personally not in favour of this change.

We shouldn't have these returns in the module's main file, that completely prevents loading a layout and rendering things at all, empty or otherwise. We can add a return to the layout file to keep the existing logic in place, that allows overrides to render something when empty also.

Sounds like a plan

Considering the layout has the code to display no results message, this patch is correct. But perhaps make it an option like in mod_tags_popular? Would address @brianteeman's concern and would be nice for consistency too.

@mbabker having these prevents module chromes from rendering which might be desirable behavior in some cases. It's possible to address this in layout but that means ensuring no content (not even a whitespace) is outside of item check.

Oh I agree totally the check in and of itself is valid, but IMO it belongs to the layout to decide and not the main file because as is this forces the module to never render when there is an empty result set, and that might not always be the desired thing. Even that param seems acceptable for this use case (and I'm not a fan of having options for everything).

Iirc if you don't do it this way then joomla can end up with an empty column

I can't say I've ever run into the empty column scenario in the past, BUT, I'm pretty sure @SharkyKZ has exactly the conditions you can hit that with covered (essentially the check has to return before any output, as soon as something generates output then the module would be considered non-empty). It may also depend on the order of operations for module chrome (does that check for an empty output before applying chrome or is that the chrome's responsibility, because the system chrome handles that inconsistently whereas the Protostar chrome checks empty content).

It is a common request that empty content modules

• do not effect the layout of the page (that includes not rendering module chromes),

and that is why people even use a popular 3rd party tool to even

1. strip HTML on module content
2. and then trim whitespace

and then consider that a module is empty ...

I agree with @mbabker that it belongs to the layout

But accepting this PR as it is, will change layout display of websites
if it was ever going to be the responsibility of the layout to return zero string it should have been done in the beginning.

You can move the IF statement inside the layout like it is for other modules

But now all existing custom layouts that have duplicated the default
https://github.com/joomla/joomla-cms/blob/staging/modules/mod_tags_similar/tmpl/default.php#L13

will start rendering module chromes on empty content

You are going to have bug reports after excepting this for this module

If you are going to accept this PR , at minimum the removed code should be added to the layout

@brianteeman @mbabker we end up with empty column anyways because HtmlDocument::countModules() counts empty modules. There's a PR pending for 4.0 to change this, see #19416.

@ggppdk Syncing with mod_tags_popular for 3.x is fully B/C, even with overrides. Return could be moved to layout in 4.0.

Iirc if you don't do it this way then joomla can end up with an empty column

I stand corrected - you do get the empty column before this PR

@david-bettondesign can you update this PR so that it matches mod_tags_popular (see #20811 (comment))?

Erm... I know I sound like an idiot but I don't know how! This was my first ever pull request.

Are you asking how to update the PR or what changes you need to make?

To update the PR you first need to restore the branch. There should be Restore Branch button somewhere on the page. If there isn't one, you'll need to create a new PR.

The changes needed are shown in #20811 (comment)

Essentially, you would need to add a new parameter to the XML file (and accompanying language strings in INI file) and update the check in the module file to check against the parameter.

@SharkyKZ can you update the PR? If not i suggest to close it due the lack of response by @david-bettondesign

@franz-wohlkoenig I don't think I can modify someone else's PR. I think only maintainers can.

I can make a new PR but I guess it will have to go into 4.0? Because new parameter added.

@SharkyKZ to be on safe Side i suggest to make a PR against J4-Branch.

clsong for the Reason stated above.