Beez error.php is wrong and should be corrected.
We should have there:

							<?php if (JModuleHelper::getModule('mod_search')) : ?>
								<div id="searchbox">
									<h3 class="unseen">
										<?php echo JText::_('TPL_BEEZ3_SEARCH'); ?>
									</h3>
									<p>
										<?php echo JText::_('JERROR_LAYOUT_SEARCH'); ?>
									</p>
									<?php $module = JModuleHelper::getModule('mod_search'); ?>
									<?php echo JModuleHelper::renderModule($module); ?>
								</div><!-- end searchbox -->
							<?php endif; ?>

i.e. 'mod_search' instead of 'search'

Well, not related to this issue, but you can get a module either by its full extension name (i.e. mod_search) or the name without the mod_ prefix (i.e. search).

It does not work in Beez. Just tested. <name> of search module is mod_search.
Will make a patch.

Understand it may not be related to this issue indeed.

You may be hitting an issue with an extension doing something in the onAfterCleanModuleList event then. The name property that's used isn't one from the database but one set at runtime in https://github.com/joomla/joomla-cms/blob/staging/libraries/src/Helper/ModuleHelper.php#L452

Either way using the full name (mod_search) would be preferred as that should always be set, but if using the name without the mod_ prefix isn't working then there's another issue to be chased down. Unfortunately with the plugin events and us using plain stdClass objects instead of data objects with declared fields nothing is really reliable.

It's even worse in protostar error.php as not only search will not work, but the module is not rendered at all when changed to mod_search as there is no JModuleHelper::renderModule

I installed a new local version of joomla 3.8.1 instead of importing my site and try to rerpoduce the issue (with experimental router).
I found that if the site:

• is multilanguage
• the custom module is assigned to a specific language (for example EN) AND
• the custom module is assigned on selected pages (all EN pages selected, deselected all other pages of other languages)

The module is not rendered in the error.php

But, if the site:

• is multilanguage
• the custom module is assigned to a specific language (for example EN) AND
• the custom module is assigned to all pages

The module is rendered.

I don't know if this is expected behaviour.
Sorry to have provided little details to reproduce the issue, I'm still trying to understand.

Thank you for your work.

Error.php is not a menu item with an itemId. It is displayed when we get an error.
I would not expect restricting the module display to some menu items allowing display in error.php.
Not sure either that error.php respects multilang except for the language used.
EDIT: That last one looks like a bug.

Concerning Protostar and Beez error in displaying the search module please #18375

@infograf768 not sure I have understood 100%, anyway the complete code in my error.php to display one module instead of another is the following, based on the language:
<?php $lang = JFactory::getLanguage(); $result = $lang->getTag(); if ($result=="it-IT") { $module = JModuleHelper::getModule('custom', 'mycustom-it'); echo JModuleHelper::renderModule($module); } else { $module = JModuleHelper::getModule('custom', 'mycustom-en'); echo JModuleHelper::renderModule($module); } ?>

I confirm that ONLY if I set the language in the module tab and if I set "assigned to all pages" the content can be rendered correctly.

The situation is the following:
1- I'd want to switch to the new router
2- I want to display a custom module (customfooter1-it for italian pages and customfooter1-en for english pages) in the footer for page 1,2,3 and 4
3- I want to display a custom module (customfooter2-it for italian page and customfooter2-en for english page) in the footer for page 5
4- I want to display the customfooter1-it or customfooter1-en in the error page

So, I cannot assign the custom module customfooter1-it and customfooter1-en to all pages (which apparently is the only way to get them rendered by the error.php page with the experimental router) otherwise I will have a duplicate footer in page 5.

I hope to have clarified the situation.

@sweft54 If you want to render such module always, not depends on menu assignment and sometimes without module parameters from db then you can try to use mod_ prefix fro module name like:

<?php $module = JModuleHelper::getModule('mod_slideshowck', 'Slideshow CK'); echo JModuleHelper::renderModule($module); ?>

The other way is to assign module for all menus, you can set position to None to not display module on other pages.

BTW: I don't see in which way using the experimental router or not would change the results for the error.php.

@csthomas thank you, however using mod_ or name doesn't solve the problem, modules are not rendered. The second "solution" (create another module and assign to all pages without position) works.
However, this is not THE solution :)

Experimental routing does not set any Itemid on page /whatever and return 404 URL invalid
but stable routing set Itemid to home page and return 404 Article not found.

As we know Joomla loads (for not yet patched error.php in beez3) modules based on menu item.
If menu item is null or 0 then Joomla will loads only modules with assignment to all pages or to IIRC except selected.

If there is no search module enabled for supplied Itemid then the module will not be displayed.
And the issue is about this (when experimental routing does not set Itemid to home page).

The other way is:
If you try to load module by name with prefix 'mod_' as in #18375 then Joomla creates dummy object of module and executes module with empty/default settings.

For mod_custom this may do not work because if Joomla does not find any module (using Itemid) then creates dummy object with empty text and empty parameters. Module custom with empty text is useless. Some other modules also could have a problem to display content without parameters from db.

I don't know what to say about this. @csthomas is right and this is expected behavior. Can we close this one?

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/18369

Closed as stated above.