PEAK XOOPS - News in englishin japanese

Archive | RSS |
Poster : GIJOE on 2008-12-28 18:02:01 (8707 reads)

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

The exact "dirname rule" by perl regex:


Under the environtment "case sensitive" (Unix etc.), (dirname) is distinguished (Dirname) definitely.

eg) XUGJ uses d3forum as "QandA". OK NG

And I believed both (dirname) and (Dirname) can be installed independently with such environtments.
To our regret, this is just a misunderstood.

Consider XOOPS with "pico".
I dare to install another pico as "PICO".

This SQL is queried to identify "dirname".

SELECT (snip) WHERE dirname='PICO'

'PICO' will be hit existent 'pico'.
And the installer raise an error.
Of course, this is not only a problem of installer but common.php also.

If you want both "pico" and "PICO", try this query once.

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

The column of `dirname` is added an attribute 'binary'.
I've confirmed "pico" can work fine with "PICO".

But only the feature of "Literal overridding" cannot work independently between "pico" and "PICO".

This code is the cause of the confusion.

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

We -D3 module developpers- have to fix this code in (lang)/modinfo.php, (lang)/block_each.php and xoops_version.php etc.


Poster : GIJOE on 2008-12-14 06:04:31 (11135 reads)

in englishin japanese
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.

Poster : GIJOE on 2008-11-29 04:45:23 (15929 reads)

in englishin japanese (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.

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 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

Poster : GIJOE on 2008-11-12 04:08:39 (13106 reads)

in englishin japanese

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)

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" ;

# 100 (blue)
# 100 (red)

serialize()/unserialize() is faster than var_export()/eval() 3-4 times.
This result is independent from PHP versions.

But you should check the absolutely value.
Serializations is not so costed processes.
Then, I can say this is a disregardable cost.

C) usability

var_export()/eval() sweeps it

var_export()/eval() is free from encoding troubles.
And you can edit serialized text as you like.

D) conclusion

This is a standard to select it.

serialize() : redundant data / a lot of arrays
var_export() : primary data / few arrays

E) digression

I will use var_export()/eval() in my works.
pico in my developping tree has been already modified it.


Poster : GIJOE on 2008-11-11 18:28:10 (11044 reads)

in englishin japanese
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() 

causes an error.

You may say ...
"As I don't translate any text, this discussion sounds non sense"


MySQL >= 4.1 stores any text as UTF-8.
This means that your serialized text can be translated automatically by MySQL

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

This might be a critical trouble for XOOPS session.

The I'm trying the other serialization by 'var_export()'.

var_export() outputs text like:

  'index' => 'value' ,

This format is strong for automatical/manual encoding translations.
We can unserialize the data by eval().

I will discuss merits and demerits of using var_export(), tomorrow.


« 1 2 (3) 4 5 6 ... 55 »
Username or e-mail:


Remember Me

Lost Password?

Register now!