[d3pipes] JavaScript Error in use with Some Kinds of Modules

Hi, GIJOE. I have a difficulty that...

d3pipes 0.56a is used.
If the block "List entries (Async)" of d3pipes module and Some Kinds of Modules shown below are installed
then a browser's JavaScript error occurs on the pages of this block (with IE6).

It may be the basic cause that $xoops_module_header can be overwitten simply by Some Kinds of Modules
after it is modified by d3pipes.


Error Check:
If the CODE1 shown below is commented out in HTML source then the above error doesn't occur.
<<<CODE1
d3pipes_add_script( "http://localhost/modules/d3pipes/index.php?page=jsbackend&pipe_ids=1&max_entries=10&union_class=mergesort&unique_id=150446e0b5d16ee49" ) ;
CODE1;

If the URI in the above CODE1 is entered to some browser
then the CODE2 shown below is returned in HTML source (case of no pipes).
<<<CODE2
d3pipes_insert_html('d3pipes_async_block_150446e0b5d16ee49','
<ul class=\"d3pipes_block_async_aggregated\">
</ul>
');
CODE2;

And it is found out when the above error occurs the CODE3 shown below is not included in HTML source!
<<<CODE3
<script type="text/javascript">
<!--
function d3pipes_add_script( url )
{
script = document.createElement("script");
script.setAttribute("type", "text/javascript");
script.setAttribute("src", url);
script.setAttribute("charset", "EUC-JP");
document.getElementsByTagName("head").item(0).appendChild(script);
}

function d3pipes_insert_html( id , html )
{
document.getElementById( id ).innerHTML = html ;
}
//-->
</script>
CODE3;


It seems that PHP var $xoops_module_header is modified suitably by d3pipes (but $xoops_js is not used).
XOOPS_URL/modules/d3pipes/blocks/async_show.php: line 71
<<<CODE4
if( is_object( $GLOBALS['xoopsTpl'] ) ) {
$xoops_module_header = $GLOBALS['xoopsTpl']->get_template_vars( "xoops_module_header" ) ;
if( ! strstr( $xoops_module_header , 'd3pipes_add_script' ) ) {
$GLOBALS['xoopsTpl']->assign( 'xoops_module_header' , $head_script . $xoops_module_header ) ;
}
}
CODE4;


It is a guess that $xoops_module_header is overwitten simply by Some Kinds of Modules after it is modified by d3pipes.
Actually, it is confirmed that the above error occurs on the block of d3pipes with Some Kinds of Modules shown below.

Some Kinds of Modules:
- XOOPS Search
- WF-Downloads
- RSS Center
- SmartSection
- SmartFAQ
- SmartPartner
and maybe more...

Example #1: XOOPS Search 2.0
XOOPS_URL/modules/search/index.php: line 156,270
<<<CODE5
$xoopsTpl->assign("xoops_module_header",'<link rel="stylesheet" type="text/css" media="screen" href="'.XOOPS_URL.'/modules/'.$mydirname.'/include/search.css" />');
CODE5;

Example #2: WF-Downloads 3.1.0 Final
XOOPS_URL/modules/wfdownloads/footer.php: line 36
<<<CODE6
$xoopsTpl->assign("xoops_module_header", '<link rel="stylesheet" type="text/css" href="' . WFDOWNLOADS_URL . 'module.css" />');
CODE6;
...


It seems that;
- $xoops_module_header and $xoops_js are provided for additional CSS etc. and JavaScript.
- $xoops_module_header and $xoops_js should be modified suitably by any modules for common use.
- $xoops_module_header is modified suitably by d3pipes (but $xoops_js is not used).
- But now, $xoops_module_header is assigned simply by many modules.
- Now, $xoops_module_header is overwitten after it is modified by d3pipes.

If that is the fact then the block "List entries (Async)" of d3pipes module can not be used with the other modules.
If the rule and one way of accessing to $xoops_module_header and $xoops_js should be provided and announced by somebody...

Will you have any ideas to avoid the above difficulty?


[Environment]
XOOPS_ROOT_PATH = D:/homepage
XOOPS_URL = http://localhost
XOOPS Cube Lagacy 2.1.1
mysql 4.0.27
php 5.2.0
apache 2.0.59
Windows XP HE SP2 / IE6

hi souhalt

It sounds a musty issue.
Just a simple reason:
Quote:These modules are not well designed.

All modules never break <{$xoops_module_header}>.
At least, all good modules get the previous values by $xoopsTpl->get_template_vars("xoops_module_header") before assigning 'xoops_module_header'.
It's a simple rule for the cooperation.

Though hodaka advocated <{$xoops_block_header}> 2~3 year ago, almost themes don't place such a variable even now.


If you want to use such bad-designed modules with blocks of d3pipes, there are two way.

- Request such developpers to keep xoops_module_header
- Use sync block instead of async block of d3pipes


These are quite a common sense.
You should learn XOOPS more.