$params = '123'
.Module loaded.
Exception thrown:
Call stack
--
# | Function | Location
1 | () | JROOT/libraries/cms/module/helper.php:223
2 | JModuleHelper::renderModule() | JROOT/libraries/joomla/document/renderer/html/module.php:93
3 | JDocumentRendererHtmlModule->render() | JROOT/libraries/joomla/document/renderer/html/modules.php:42
4 | JDocumentRendererHtmlModules->render() | JROOT/libraries/joomla/document/html.php:486
5 | JDocumentHtml->getBuffer() | JROOT/libraries/joomla/document/html.php:777
6 | JDocumentHtml->_renderTemplate() | JROOT/libraries/joomla/document/html.php:552
7 | JDocumentHtml->render() | JROOT/libraries/cms/application/cms.php:1116
8 | JApplicationCms->render() | JROOT/libraries/cms/application/site.php:777
9 | JApplicationSite->render() | JROOT/libraries/cms/application/cms.php:271
10 | JApplicationCms->execute() | JROOT/index.php:49
Joomla 3.7.3, PHP 7.1.
Line 223 in helper.php looks like this:
$paramsChromeStyle = $params->get('style');
Before that, module files are included, and before that, $params
is defined.
Solution: The included file must be contained in some way, so that variables does not leak into parent scope.
Labels |
Added:
?
|
With lack of anything else than function scope in PHP, one cheap (and maybe ugly) solution would be to rename all variables in renderModule()
using __
prefix, like $__params
, etc. While not bullet proof, it could diminish the collision risk slightly.
The best way would be to let modules define a function instead of just a file, but it's too late for that. :)
If anyone knows another way to create scope in PHP, please let us know.
Or maybe better: Move $chromeMethod()
call to own function that returns the string from ob_get_contents()
. And within that smaller helper function, all variables can be prefixed with _
or sim.
Edit: Sorry, I'm reading wrong line. The thing that needs to be in it's own function is
include_once $chromePath;
on line 216. I think.
Category | ⇒ | com_modules |
Status | New | ⇒ | Discussion |
OK, mod_menu
assumes $params
is defined when the module is included. So, no solution.
OK, mod_menu assumes $params is defined. No solution.
This can be fixed in mod_menu but it means that we have a b/c break if we change the helper than. If you have code can you send that against the 4.0-dev branch so we can fix it longterm and shortterm you just rename the $params to $myparams in your module?
This can't be fixed without a B/C break.
https://github.com/joomla/developer.joomla.org/blob/master/modules/mod_joomladata/mod_joomladata.php has a list of variables in scope when you get into a module's file. They should not be overwritten or modified.
@olleharstedt feel free to update the docs. It's a wikithat anyone can contribute to.
I am closing this for the reasons stated above.
Status | Discussion | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-09-09 12:29:11 |
Closed_By | ⇒ | brianteeman |
Thank you, @brianteeman. You know which page that would be, exactly?
hmm. I'm not sure if we can fix this as this is a namecolusion.
here: https://github.com/joomla/joomla-cms/blob/3.7.4/libraries/cms/module/helper.php#L196-L200 we import the module.
and a few lines later we try to get the paramsChromeStyle using
$params->get('style');
Sure we can override this by moving this line$params = new Registry($module->params);
just be fore the actual usage but this would just override your$params = '123';
.The currentlt way shows the dev that there is a problem / error with the patch i have described above the error would be masked and the dev would not spot it that easy as currently.
Would be great to get your feedback on this. Thanks.