Zenphoto
The simpler media website CMS
ZenphotoThe simpler media website CMS
Forum search only. You might also want to search on the main site's user guide.
Your support helps pay for this server, and helps development of zenphoto. Thank you!
Visit the donations page
Comments
But to address the warnings. Generally they tell you what you would need to do to rectify the warning.
The first describes what to do to have setup detect your filesystem character set. Of course, if you know, you can set it directly. Your php info link is broken, but most likely the characterset is iso-8859-1. Anyway, so long as you do not use diacritical marks in file/folder names there is no problem (as the warning states.)
You have several warnings saying that Zenphoto is unable to set file/folder permissions. Currently the permissions are not very secure. However, note that servers that are set this way often do not work when you set the permissions properly. The warning message points you to a troubleshooting guide on this.
The secons warning simply states that setup does not think you are running on an Apache server. That may or may not be an issue. Apache servers are the only ones we are in a position to provide support suggestions for. But Zenphoto has been successfully installed on other servers. You can post what you are using and maybe someone here can help.
The last unique warning says that Zenphoto could not create the robots.txt file. That file is not needed, but the fact that we could not create it probably means there is a permissions issue.
Now, I get a different error.. it has to do with the Mysql query... http://tiagotavares.eu/foto/zp-core/setup.php
2. There is no MySQL error indication from setup
3. Your PHP ini link is still broken
3. You have exactly one more post to convince me that this thread in not just an elaborate attempt to use the Zenpoto site to promote your web page SEO. Should you fail, this thread and your user ID on the site will be deleted.
https://picasaweb.google.com/lh/photo/eVoOhbQvtG1YEmp5PlWKUA?feat=directlink
It says register globals is set to ON and it isn't! It's set to off...
So, contact your host. Make him prove he has set it off--a simple PHP script can do this (as is done by setup.) Probably also this can be confirmed by the PHP info function.
http://tiagotavares.eu/foto/1.php
`
$register_globals = ini_get('register_globals');
`
[circa line 427] add:
`echo '
$register_globals ';var_dump($register_globals);`
and report what it displays.
https://picasaweb.google.com/lh/photo/MuZrTu3BOwTm1sRmOSLOfA?feat=directlink
Apparently it is off...
So set it to `off` [no quotes] and it will indeed be not set.
[root@linux2-whg httpdocs]# cat .htaccess
php_value magic_quotes_gpc off
php_value register_globals off
php_value short_open_tag off
"If these PHP settings were wrong, you would not be able to see that register_globals was set to off through phpinfo() function. So I think the issue is with particular application, not server settings."
Sorry, but this one is really on you and your provider. You will notice that no one lse is reporting that they also have this problem.
First my feeling: sbillard, I found you pretty arrogant and unfair with mrtavares who was just trying to make zenphoto work on his host. Contrary to what you say, he is not alone reporting this problem: I just spent my morning fighting against it, and another post has been submitted a week ago on the very same topic (http://www.zenphoto.org/support/topic.php?id=9573#post-56312).
A bit of history: the line that causes trouble has been introduced in setup.php at revision 7059 in the development branch of zenphoto. It has been merged into the trunk at revision 7176 in the middle of May. I do not know precisely when it has been officially released but anyway, this is three times the same report, for a bug (call it a feature if you want) that has been introduced less than 2 months ago. So, please, consider that the problem might also come from you before insulting people.
That said, I recognize that the behavior of php is a bit troubling here. According to the commented lines at the beginning of my php.ini (php version 5.3.3-7, from a Debian distribution), the allowed keywords for boolean flags are: 1, true, yes, on, 0, off, false, no. Experiments seem to show that these keywords are key insensitive. When one uses one of this keyword, everything is fine.
Now, what happens, if some other keywords are used?
* a non-zero integer seems to be considered as true, as it is everywhere in PHP.
* Things become weird when strings are used: the strings "on", "true", "yes", "17", etc. (case insensitive) are considered as on.
* Any other non-empty string (or an invalid keyword, such as onnn, without quotes) yields the following behavior: (bool)ini_get('register_globals') returns true (as you could expect for the boolean cast of a non-empty string) *but* register_globals is actually deactivated (I mean that the variables in $_GET, $_POST, etc. are *not* registered as global variables). Moreover, phpinfo() indicates that register_globals is Off (both local and master).
In conclusion: clearly, using something else that the recommended keywords is bad and should be avoided by hosts. *But* the behavior of php is indeed such that the string "on" activates register_globals and the string "off" deactivates it. So it is not surprising that many site managers do the mistake, since it works in practice as expected.
Finally, it seems to be considered as poor practice to do what is done in zenphoto (i.e. just test the boolean value of ini_get('register_globals')). About it, see the comments of "nicolas dot grekas+php at gmail dot com" at the official manual page of ini_get: http://www.php.net/manual/en/function.ini-get.php
But we also can't know what works on some host and on some not if you don't use the recommended keywords. (register globals should simply off by default anyway...)
As likely is that it may be an implementation specific anomaly. The PHP ini documentation clearly distinguishes constants from strings. The statement for booleans is Nowhere does it suggest that the string “Off†is equivalent to the constant `Off`. Are you sure that this is the case in all versions of PHP past and future? Are you indemnifying anyone who relies on this and is subsequently hacked by a security breach?
Seems to me that best practice is to use the constants as defined. Any provider not willing to do that should be viewed with some concern.
I thought of another (robust) way of deciding whether register_globals is activated or not: read the "Local" field of the corresponding row in the table returned by phpinfo(). Something like the following function do the trick (I do not claim the following code to be very robust though, because it will be broken if the output of phpinfo is formatted a bit differently; but you certainly can write more robust code for doing the same thing).
function register_globals_from_phpinfo() {
ob_start();
phpinfo(INFO_CONFIGURATION);
$pinfo = ob_get_contents();
ob_end_clean();
preg_match('#<tr><td[^>]*>register_globals.*#', $pinfo, $match);
if (count($match) != 1) return -1;
$line = $match[0];
$value=strtolower(preg_replace('#<tr><td[^>]*>register_globals</td><td[^>]*>([a-zA-Z]*)<.*#', '${1}', $line));
if ($value == "off") return 0;
else return 1;
}
Bottom line is that Zenphoto will report the settign of the ini_get(). If in some cases that does not match the actual enable of the feature at least we know we will error on the conservative side. There is really no justification for using a sledge hammer to kill this fly.