PEAK XOOPS - Templates problem in 2.0.14/15 from xoops.org in englishin japanese

Archive | RSS |
XOOPS
XOOPS : Templates problem in 2.0.14/15 from xoops.org
Poster : GIJOE on 2006-08-30 12:52:23 (18072 reads)

in englishin japanese
In 2.0.14 from xoops.org, the system of templates are modified.
You have to see just a function.

- Using tplset other than default ... DB template. (== XOOPS 2.0.13)
- Using default tplset ... FILE template. (no longer DB template!)
-- Try to read /themes/(your_theme)/modules/(dirname)/(templates) first. (1)
-- Try to read /modules/(dirname)/templates/(templates) second. (2)
-- Else the template will be blank ... (3)

It looks like compromise idea between Oreteki and XOOPS<=2.0.13.

But this makes some incompatibilities against some module does not have templates under (dirname)/templates/.
eg) wraps, bulletin 2.0 etc.

Thus I've just suggested imploved codes here. (red part)

-- Else read DB template ... (3)

Yo, Skalpa!
Can you hear me?
class/smarty/xoops_plugins/resource.db.php


function smarty_resource_db_tplinfo( $tpl_name ) {
	static $cache = array();
	global $xoopsConfig;

	if ( isset( $cache[$tpl_name] ) ) {
		return $cache[$tpl_name];
	}
	$tplset = $xoopsConfig['template_set'];
	$theme = isset( $xoopsConfig['theme_set'] ) ? $xoopsConfig['theme_set'] : 'default';
	
	$tplfile_handler =& xoops_gethandler('tplfile');
	// If we're not using the "default" template set, then get the templates from the DB
	if ( $tplset != "default" ) {
		$tplobj = $tplfile_handler->find( $tplset, null, null, null, $tpl_name, true);
		if ( count( $tplobj ) ) {
			return $cache[$tpl_name] = $tplobj[0];
		}
	}
	// If we'using the default tplset, get the template from the filesystem
	$tplobj = $tplfile_handler->find( "default", null, null, null, $tpl_name, true);

	if ( !count( $tplobj ) ) {
		return $cache[$tpl_name] = false;
	}
	$tplobj = $tplobj[0];
	$module = $tplobj->getVar( 'tpl_module', 'n' );
	$type = $tplobj->getVar( 'tpl_type', 'n' );
	$blockpath = ( $type == 'block' ) ? 'blocks/' : '';
	// First, check for an overloaded version within the theme folder
	$filepath = XOOPS_THEME_PATH . "/$theme/modules/$module/$blockpath$tpl_name";
	if ( !file_exists( $filepath ) ) {
		// If no custom version exists, get the tpl from its default location
		$filepath = XOOPS_ROOT_PATH . "/modules/$module/templates/$blockpath$tpl_name";
		
		if ( !file_exists( $filepath ) ) {
			return $cache[$tpl_name] = $tplobj ;
		}
		
	}
	return $cache[$tpl_name] = $filepath;
}


Related articles
Printer friendly page Send this story to a friend

Comments list

gigamaster  Posted on 2007/9/23 8:41
Still Learning !

GIJOE  Posted on 2007/9/19 16:13 | Last modified
Incidentally...


I did stand neutral zone far from both projects Xoops and XoopsCube.

I am/was making my modules/hacks can work with both XOOPS and XOOPS Cube as possible.
My proud D3 modules works perfectly with XOOPS 2.0.13.2/XOOPS 2.0.16a-JP/XOOPS Cube Legacy 2.1.x


But you -xoops.org- kill the basic compatibility of XOOPS one-sidedly and suddenly in 2.0.14
However the version counts 2.0.17.1RC now, you still ignore my modest proposal "just add fall-backing code for compatibility". (sigh)


That's the reason why I have to stop supporting the core from xoops.org.


Dear "core team" of xoops.org:
read once minahito's entry
http://sunday-lab.blogspot.com/2007/09/core-team-was-dead-2.html
GIJOE  Posted on 2007/9/19 12:33
hi Shine.


I've checked the archive.
Certainly I can find "fixed resource.db.php" in extras folder.

But, this is quite NON-SENSE.

Almost Users of the core from xoops.org still ask me how to run my works.


And the poor core team don't understand what I mean at all, sadly.
My patch is just adding a fall-back...
Perhaps, they cannot read PHP code at all


Then I'll target only XoopsCube.

Good-bye! xoops.org.
Shine  Posted on 2007/9/19 6:48
FYI:
Today a new realease of xoops which makes it compatible again.
See: http://www.xoops.org/modules/news/article.php?storyid=3939

Release of XOOPS 2.0.17.1 RC
Quote:
We also took the opportunity of this release to update the resource.db.php located under the extras folder of the package. This file is fixing a problem that may occur with modules not having their templates under module/dirname/templates/. Please carefully read extras/readme.txt for all information.

They've listen to you finally GIJoe
GIJOE  Posted on 2006/12/29 6:35
hi Bandit-x
Quote:

im just the messenger.
OK
Thus, I'm stacking another message

2.0.14's incompatibility means the resource 'db:' interprets 'file:'.
This is a contradiction for the resource type of Smarty.

But I never deny your "modification" just by logical consistencies.

I just mean merging your modification and the compatibility.

I believe you can aware my patch never denies the 2.0.14's modification but it goes together the new feature in XOOPS >= 2.0.14 and compatibility with XOOPS <= 2.0.13.2
Bandit-x  Posted on 2006/12/28 13:29
im just the messenger.
GIJOE  Posted on 2006/12/28 4:01
Quote:

Bandit-x wrotes:
but they are not . since the template files are supposed to be in the . templates directory.
Are you a member of core team of xoops.org?

Thus, I have to say you misunderstood the original spec of template system.
XOOPS uses DB template instead of FILE template for modules or blocks.
(Just theme uses FILE template system)

This is the real 2.0.x spec.
Only 2.0.14/15/16 from xoops.org break the compatibility.
Of course, 2.0.16 from xoopscube.org follow the compatilibity

If you break the compatilibity, you should number them 2.1.x or 2.2.x etc.

And do you know template robber?

XOOPS_ROOT_PATH/modules/(dirname)/template

is almost PUBLIC and anyone can access the template.
(Though my modules are protected by .htaccess)
Base templates for DB templates should be out of DocumentRoot.

This is just one of the reason I use XOOPS_TRUST_PATH
Bandit-x  Posted on 2006/12/28 0:24
Quote:

GIJOE wrotes:

I say again, this is an incompatibility just with core 2.0.14/15/16 from xoops.org

Core team of xoops.org should fix it.
Just insert a few lines

but they are not . since the template files are supposed to be in the . templates directory.

Found It On SF.Net.
http://sourceforge.net/tracker/index.php?func=detail&aid=1549165&group_id=41586&atid=...
GIJOE  Posted on 2006/12/27 13:00 | Last modified
Quote:

I copied the file /trusted_path/modules/templates/index.html to a new folder /modules/testwrap/templates/testwrap_index.html and that seemed to do the trick.
In the way, you have to copy and rename the templates manually for every modules.
At least, I cannot do such a bother way. lol

I say again, this is an incompatibility just with core 2.0.14/15/16 from xoops.org

Core team of xoops.org should fix it.
Just insert a few lines
borpin  Posted on 2006/12/27 9:19
I think I solved the problem for 2.0.15 for me anyway!. It is difficult to explain. I am calling my folder testwrap so I will use that. The system was looking for a template file templates/testwrap_index.html in the normal /modules/testwrap/ directory instead of the trusted path directory. I copied the file /trusted_path/modules/templates/index.html to a new folder /modules/testwrap/templates/testwrap_index.html and that seemed to do the trick.

I looked at the oninstall and onupdate files and they seem to be the problem, but as I do not understand the templates I can't fix it!
Login
Username or e-mail:

Password:

Remember Me

Lost Password?

Register now!