[#6045] - Fatal error: Call to undefined method JDocumentRaw::getHeadData()
- Closed
- 15 Mar 2015
- Medium
- Build: staging
- Easy Test
- # 6045
- Diff
- islavi:patch-1
- Success The Travis CI build passed Details
User tests: Successful: Unsuccessful:
Getting Fatal error: Call to undefined method JDocumentRaw::getHeadData()
Case 6028:
http://issues.joomla.org/tracker/joomla-cms/6028
How to repreduce:
I'm using AJAX call to refresh a module.
In javascript I use the following:
function moduleRefreshSendAjax (moduleName, moduleId, modulePosition, num){
var data = {
"option": "com_ajax",
"module": moduleName,
"method": "refresh",
"moduleid": moduleId,
"position": modulePosition,
"format": "raw"
};
jQuery.ajax({
type: "POST",
data: data,
success: function (res) {
jQuery('.news-' + moduleId).html(res);
},
error: function (res) {
console.log("ERROR: " + res.responseText);
}
});
};
And in the server side I use the following method:
public static function refreshAjax() {
$position = $_POST['position'];
$moduleId = $_POST['moduleid'];
$modules =& JModuleHelper::getModules($position);
foreach ($modules as $module) {
if ($module->id == $moduleId) {
return JModuleHelper::renderModule($module);
}
}
}
joomla-cms-bot
- | Labels |
Added:
?
|
||
| Title |
|
||||||
| Rel_Number | ⇒ | 6028 | |||||
| Relation Type | ⇒ | Pull Request for | |||||
| Easy | No | ⇒ | Yes | ||||
| Category | ⇒ | Cache Libraries |
Looks good for the moment. In the future i would like to see interfaces.
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/6045.
I've looked into this for a while but couldn't reproduce this error. It seems that this bug only occours in a scenario where libraries\cms\library\helper.php:156] (libraries\joomla\cache\controller.php:57) gets called with an array ($woptions) containing a 'modulemode' key.
Any attempt to reproduce this led to an empty array (default) being passed to the get method, so the proposed code in question was never reached.
What did id do to test this:
I added the (helper) method as a test to both the login module and the main menu module which I published on position-7 in the protostar template.
After that, I opened the firefox console and ran an ajax-request to get the output of both modules with the format "raw" parameter. The result was always the expected / requested module output, never the warning message described in this issue (regardless of the cache being dis- or enabled).
The patch itself (code wise) might be ok but to verify it, further test instruction are needed.
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/6045.
If you put this snippet into a system plugin, you should be able to trigger the error:
public function onAfterInitialise() {
$doc = JDocument::getInstance('raw');
$doc->getHeadData();
}(If you choose a plugin that already has the method, then you only need the $doc lines)
Thanks @mbabker,
but wouldn't this be equal to call any non-existing method? Sure it produces the error message, but I got the feeling that it would be good to find an example or to have a test instruction where the proposed code change is actually reached.
Apart form that I'm willing to believe that adding the method_exists check would solve the issue.
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/6045.
Most of the problem is our JDocument classes are implemented very inconsistently; there is no interface or abstract layer defining the expected methods. So you're left with checking the document type, checking if the method exists, or some other workaround.
As to a "real" use, as the OP noted, his call will do it as it will create a JDocument object that isn't the HTML class, which is the only one that has the method he's wrapped in the method_exists check.
Shall we call this "fixed" then, what do you say?
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/6045.
I saw this error just recently with a user of my component.
I create a podcast from the data which uses JDocumentRaw. Now a 3rd party content plugin on my users site parsed the data and thought it's fine to add JavaScript to the head of a non-HTML document type, which obviously wasn't working and generated that error, which then again broke the podcast.
So it's basically a fix for bad coded plugins which just assume always having a HTML document present.
Yes, it could be easily fixed in the 3rd party plugins. But we all know that there always will be such plugins. And it's an easy fix here to avoid that error 
Setting it to RTC.
| Labels |
Added:
?
|
||
| Status | Pending | ⇒ | Ready to Commit |
Moving to RTC to match the github label
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/6045.
| Status | Ready to Commit | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-03-15 09:22:20 |
Merged. Thanks!
| Labels |
Removed:
?
|
||
Looks fine.