PEAK XOOPS - News 
[/xlang:ja]
breadcrumbs list should be displayed by theme.html instead of each modules's templates.
Now, I suggest 'xoops_breadcrumbs' as a template variable of $xoopsTpl.
All modules should assign 'xoops_breadcrumbs' like ...
[0] => array( 'name' => '(module name)' , 'url' => '(URL for module top)' ) ,
[1] => array( 'name' => '(category name)' , 'url' => '(URL for list in a category)' ) ,
[2] => array( 'name' => '(subcategory name)' , 'url' => '(URL for list in a subcategory)' ) ,
[3] => array( 'name' => '(the article name)' )
If all modules assigns like this, you can write in theme.html like this.
<div id="theme_breadcrumbs">
<a href="<{$xoops_url}>/">TOP</a>
<{foreach from=$xoops_breadcrumbs item="item"}>
>
<{if $item.url}>
<a href="<{$item.url}>"><{$item.name}></a>
<{else}>
<{$item.name}>
<{/if}>
<{/foreach}>
</div>
You can understand this is the true "breadcrumbs list".
I've implemented xoops_breadcrumbs into pico and bulletin2.
But there are a lot of un-impelented modules in the world.
Though I know the fact, here is a magic named xugj_assign.php
(To be continued...)
Protector V3 has just been released.
You'll find this is a changed version drastically.
- The logic goes to XOOPS_TRUST_PATH
Don't forget remove "2 lines" for hooking into protector in mainfile.php before updating the module.
After Protector V3 has been installed/updated, you have to insert "2 lines" containing XOOPS_TRUST_PATH instead of XOOPS_ROOT_PATH into mainfile.php.
- Denying IPs
Protector V3 uses a file for denying IP instead of DB.
If you banned yourself, just remove the file under XOOPS_TRUST_PATH/modules/protector/configs/
- Limiting IPs for group=1
If webmaters of your site access from small range of IPs, set this.
It saves you from password cracking, session hijacking etc.
If you cannot log your site in, just remove the file under XOOPS_TRUST_PATH/modules/protector/configs/
- anti-XSS (BigUmbrella)
http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=126
- anti-SPAM with many URIs
Basic logic:
http://xoops.hypweb.net/wiki/5589.html
- compatibility checks with XOOPS Cube 2.1 Legacy
Of course, Protector V3 works with XOOPS 2.0.x*, 2.2.x, and Oreteki.
XOOPS Cube 2.1 Legacy RC has already released on 22nd Jan 2007.
I've just tested it whether my modules work fine or not.
The result... ALL GREEN!
Though Cube 2.1 Legacy has full-scratched core far from X2, it maintains high module compatibity!
I'm surprised with the great work.
Bravo! minahito, nobunobu, and Tom_G3X.
I've just made an icon of "XC2.1 Ready!".
I'll add it into mydownload's records of the modules have been checked the compatibility.
In D3 modules (pico, wraps etc.), the module icons are drawn with its dirname automatically.
But they are not so clear to distinguish, if you've installed them a lot.
You can override each module icons safely.
Just make a icon named module_icon.png and copy it into public side of XOOPS_ROOT_PATH/modules/dirname/ .
The file will never be overwritten by updating D3 module.
http://blog.solmetra.com/2007/01/19/php-vulnerability-possibly-affecting-spaw-1x-installations/
It looks curious...
Old PHP enables variables after unset() if it runs with register_globals=on ...?
If you are applicatable such conditions and you use common/spaw (TinyD etc.), you'd better update common/spaw.
- Download the latest TinyD
- Overwrite common/spaw/dialogs/img_library.php
Anyway, you MUST turn register_globals off, and you should turn allow_url_fopen off.
Moreover, I recommend you to use common/fckeditor instead of common/spaw.