PEAK XOOPS - News

You know D3 modules can be installed any dirnames as you like.

The exact "dirname rule" by perl regex:

[0-9a-zA-Z_-]{,25}

SELECT (snip) WHERE dirname='PICO'

ALTER TABLE (prefix)_modules MODIFY `dirname` varchar(25) binary NOT NULL default '';

$constpref = '_MI_' . strtoupper( $mydirname ) ;

Japanese people do the general housecleaning at the end of week.
I do the cleaning of the altsys codes which are quite dirty.

I've cleaned myblocksadmin up.
And I dropped codes for XOOPS2.2 and common/spaw as trash.

Newly, altsys supports ImpressCMS.
It makes all "D3 Modules" can work fine with ImpressCMS.
Though I don't have time to test XOOPS 2.3, altsys perhaps works fine if XOOPS 2.3 is structurally identical with ImpressCMS.

And altsys starts to support common/fckeditor (fckxoops) for custom block's WYSIWYG editing.

And so on..

Since the new myblocksadmin is fully scratched, it might includes some bugs.
I'll be appreciated if you report bugs.

xoops.org (Mamba) annouces a news.
Security : Protector Security Fix for XOOPS 2.0.x and 2.2.x users

I can say it is a non-sense report then just ignore it.
(Inside XOOPS_TRUST_PATH LFI )

There are many Web applications structured with both public codes (inside DocumentRoot) and private codes (outside of DocumentRoot).
You know such applications have better structures than older applications like XOOPS.

If someone put private codes inside DocumentRoot and accesses private codes via httpd directly, there looks a lot of security problems.
But, none send such a stupid report.
Because all security experts know the meaning of inside/outside DocumentRoot well.

XOOPS_TRUST_PATH must be placed outside of DocumentRoot.
This is an important principal.

This news reveals the members of xoops.org don't know the basic of the security at all.

On the other hand, the developpers of ImpressCMS know the meaning of XOOPS_TRUST_PATH well.
eg) ImpressCMS stores a file for "DB password etc." under XOOPS_TRUST_PATH.

This is my conclusion:
Choose ImpressCMS rather than a CMS named XOOPS from xoops.org.

serialize()/unserialize()
var_export()/eval()

A) security

You may feel it is dangerous to use eval().
Of course, you should not unserialize requested text.
However, you cannot use unserialize() for requested text also.

B) speed

A script for verification.

#!/usr/local/bin/(php-cli binaries)
<?php

function getmicrotime()
{
        list($usec, $sec) = explode(" ",microtime());
        return ((float)$sec + (float)$usec);
}

function var_import( $data ) {
        eval( '$ret='.$data.';' ) ;
        return $ret ;
}

$data = ( big array ) ;

$time_start = getmicrotime();

for( $i = 0 ; $i < $_SERVER['argv'][1] ; $i ++ ) {
        $serialized_data = serialize( $data ) ;
        $restored_data = unserialize( $serialized_data ) ;
        $serialized_data = var_export( $data , true ) ;
        $restored_data = var_import( $serialized_data ) ;
}

$time_end = getmicrotime() ;
echo $time_end - $time_start , "sec. \n" ;
?>

We always use 'serialize()' as a built-in function to serialize arrays/objects.

But, the format made by serialize() is hard to use for multibyte environments.
This procedure:

 serialize() -> encoding translation -> unserialize() 

(your_encoding) -> UTF-8 -> (your_encoding)

array(
  'index' => 'value' ,
)