installation: blank page. PHP version?

[design]

Hi.
I installed the last version r426. Everything seems ok, all the installation procedure is normal. I downloaded the conf.inc.php and all the permissions are ok.
The result is:
index.php page -> blank: no error message.
login.php page -> blank: no error message.
phpwcms.php page -> blank: no error message.

After then I installed again, and again. From my MAC and from another PC ubuntu. Just to avoid dubts!

These are my server settings
WWW server: Apache/2.2.3 (CentOS)
PHP version: 5.1.6 OK
MySQL version: 5.0.77 OK
PHP settings Security risks
register_globals Off OK
safe_mode On OK (limited permissions, but recommend)
GD2 bundled (2.0.28 compatible) GD2
Image types supported: GIFGIF supported/ PNGPNG supported/ JPGJPG supported

I try to install in another server with PHP 5.3.6 and MySQL version 4.1.22 and works perfectly!

It's not a news for me: I had the same problem with r423 (15.09.11)
BUT with r412 was perfect, and even with r420.
Any ideas?
Thanks!

[juergen]

Have a look to get (php.ini) Error messages displayed.

For now this behavior sounds like suhosin php ... very secure, nothing to say

[design]

No there isn't SUHOSIN.

And PHP is handled by Apache (no suPHP neither Fast-CGI).

apache2handler

Apache Version Apache/2.2.3 (CentOS)
Apache API Version 20051115
Server Administrator xxxx@xxxx.tld
Hostname:Port domain.it:80
User/Group apache(48)/48
Max Requests Per Child: 4000 - Keep Alive: off - Max Per Connection: 100
Timeouts Connection: 120 - Keep-Alive: 15
Virtual Server Yes
Server Root /etc/httpd
Loaded Modules core prefork http_core mod_so mod_auth_basic mod_auth_digest mod_authn_file mod_authn_alias mod_authn_anon mod_authn_dbm mod_authn_default mod_authz_host mod_authz_user mod_authz_owner mod_authz_groupfile mod_authz_dbm mod_authz_default util_ldap mod_authnz_ldap mod_include mod_log_config mod_logio mod_env mod_ext_filter mod_mime_magic mod_expires mod_deflate mod_headers mod_usertrack mod_setenvif mod_mime mod_dav mod_status mod_autoindex mod_info mod_dav_fs mod_vhost_alias mod_negotiation mod_dir mod_actions mod_speling mod_userdir mod_alias mod_rewrite mod_proxy mod_proxy_balancer mod_proxy_ftp mod_proxy_http mod_proxy_connect mod_cache mod_suexec mod_disk_cache mod_file_cache mod_mem_cache mod_cgi mod_version mod_unique_id mod_ssl mod_bw mod_fcgid mod_perl mod_php5 mod_proxy_ajp mod_python mod_security2

I've looked in error_log:

[Fri Nov 25 15:02:34 2011] [error] [client 2.224.45.43] PHP Parse error: syntax error, unexpected T_VARIABLE in /var/www/vhosts/domain.it/httpdocs/include/inc_ext/idna_convert/idna_convert.class.php on line 974
[Fri Nov 25 15:02:38 2011] [error] [client 2.224.45.43] PHP Parse error: syntax error, unexpected T_VARIABLE in /var/www/vhosts/domain.it/httpdocs/include/inc_ext/idna_convert/idna_convert.class.php on line 974
[Fri Nov 25 15:02:41 2011] [error] [client 2.224.45.43] PHP Parse error: syntax error, unexpected T_VARIABLE in /var/www/vhosts/domain.it/httpdocs/include/inc_ext/idna_convert/idna_convert.class.php on line 974
[Fri Nov 25 15:02:42 2011] [error] [client 2.224.45.43] PHP Parse error: syntax error, unexpected T_VARIABLE in /var/www/vhosts/domain.it/httpdocs/include/inc_ext/idna_convert/idna_convert.class.php on line 974
[Fri Nov 25 15:29:59 2011] [error] [client 2.224.45.43] File does not exist: /var/www/vhosts/domain.it/httpdocs/favicon.ico
[Fri Nov 25 15:53:27 2011] [error] [client 2.224.45.43] PHP Parse error: syntax error, unexpected T_VARIABLE in /var/www/vhosts/domain.it/httpdocs/include/inc_ext/idna_convert/idna_convert.class.php on line 974
[Fri Nov 25 15:53:30 2011] [error] [client 2.224.45.43] PHP Parse error: syntax error, unexpected T_VARIABLE in /var/www/vhosts/domain.it/httpdocs/include/inc_ext/idna_convert/idna_convert.class.php on line 974

I've also seen that idna_convert.class.php is supposed to just Encode/decode Internationalized Domain Names:

IDNA stands for Internationalized Domain Names for Applications. It
is a standard described in RFC 3490, RFC 3491 and RFC 3492. It is
used to allow language specific characters in domain names, like the
umlauts in German, accents in latin languages like French, or
even chinese characters.
This class allows you to convert domain names between the encoded
Punycode notation and the decoded 8bit (UTF-8) notation. It
simplifies the use of domain names defined with IDNA in applications
or scripts.

Couldn't it be inside that file some error for our server environments?

[design]

OK. I've notice that file is referenced by /include/inc_lib/general.inc.php

So. I've just deleted these lines and the problem is solved.

Code: Select all

if(IS_PHP5) {
	require_once (PHPWCMS_ROOT.'/include/inc_ext/idna_convert/idna_convert.class.php');
}

I'm very happy because I was in panic, but I ask:

And now?
Why it's caused the problem?
Thanks!

[flip-flop]

I think this is a good hint: http://wordpress.org/support/topic/code ... the-plugin

.... But it can only be handled by limiting the IDNA Feature to PHP versions >= 5.2.1 because of later introduced type casts necessary for convertion.
Your hosters seems to use a lower version. If you haven't and IDNA Domain, all is fine. If you have one, please upgrade your PHP version

Knut

[design]

So, phpwcms need now PHP versions >= 5.2.1?

[flip-flop]

"If you have an IDNA Domain" (in German: "Umlautdomain") -> Yes
It is the same as in WordPress and other systems.

[juergen]

oha ! Never known before !

[design]

No, I have a "normal" domain.
http://www.mydomain.it
I have some sites with Wordpress and I haven't problem with that. But with WP I can't have the last release, cause PHP version.
It's just to know... We will upgrade soon.

[flip-flop]

Better to say:

Code: Select all

if(version_compare(PHP_VERSION, '5.2.1', '>=')) {
   require_once (PHPWCMS_ROOT.'/include/inc_ext/idna_convert/idna_convert.class.php');
}

but if you have enabled mbStringOverload you don´t need this change.

Mhh, when I search the Internet for "mbStringOverload enable", lots of items will be offered. This is a very tricky subject.
It isn´t easy to handle (utf8/iso/database).

Based on IDNA, all systems show a similar behavior, since it is a PHP problem.

Knut