display_errors

cjm51213

Hi Folks,

I thought I understood this stuff pretty well, but apparently not. I'm running Apache with php-fpm, and that presents challenges, but I don't think they explain this. The principle challenge is changing the settings in /etc/php.ini, and that is done with "/.user.ini" in the document root, interestingly, and not in /etc/php.ini

I have expanded the zenphoto 1.6 distribution in "http://cjm.tryx.org/zenphoto" and I put phpinfo.php (<?php phpinfo(); ?>) in my document root. phpinfo() shows local values of exactly what I would expect that they should be:

display_errors                  Off On
display_startup_errors      Off On
error_reporting                 0 32767

... and yet, I continue to be notified that "PHP display_errors [is enabled]", so clearly I misunderstand something!

I sure could use some help on this.

Thanks,

Chris.

acrylian

On some hosts you have to set these values via .htaccess. If it is possible differs from host to host of course.

I checked on our host and our error_reporting value is 22519.

The other two should be "off" unless you enabled any debug modes.
The value is not consistent over different PHP versions. It may also be "0" and "1" or "stderr" or "stdout" historically. We do test for these using ini_get('display_errors'). Please call that function and see what it returns.

cjm51213

Hi Acrylian,

After many hours trying to clear all the errors and warnings from installation, pre-database, I decided to continue, create the database, and review these problems later, because I know how to do that. This "display errors" problem has vanished. If I were to guess, I'd guess that the code is remembering some static value and not actually looking at the current value, possibly as a result of the new php version, although I know I re-started php-fpm, apache, and firefox many times, so how "some static value" is being recorded is completely mysterious. So, in short, I can explain neither the trouble I had nor the equally unexpected disappearance of it during re-run. FYI: I forced "error_reporting" to be zero. It is a bitmap of options and I wanted to be sure that I was not asking for something that Zenphoto was interpreting as "leaky".

However, all is not lost. I have one other problem I can discuss -- UTF-8. On the one hand, I am getting a warning, "The Zenphoto filesystem character define is UTF‑8 [no test performed]", and I see "zp-data/tést.jpg" is created on each refresh of the page. If I delete it, it magically re-appears. So there is clearly inconsistency of thought and action. The test is apparently being performed, without the concomitant "character_test". I now see that the filename is not what I thought it was; there is a accent on the "test". Maybe a button creating the correct test file, so morons like me don't waste your time with non-existent problems.

And in spite of doing the test surreptitiously, the results of the test are ignored. Well, partially ignored... Immediately I am told, "Image URIs appear to require the UTF-8 character set.", and I am given the opportunity to enforce this, but doing so has no persistent effect, meaning, once enacted, the option continues to present itself on refresh of the page. So, I am being asked to do something that is already done, but there seems to be no persistent recognition that it is done, even after I do it. (-: I could use some clarification on this, meaning what is it that I am supposed to have done, and why does it persistently appear to not be done?

I'd like to take a moment to express my appreciation for your work. Zenphoto is a truly gratifying bit of design and engineering. It is tricky to install, but not prohibitively so, and once installed, nearly flawless in execution. I rarely find software that does not exhibit some, and in most cases, many, deficiencies or behaviors that are inconsistent with my view of how they should work, but Zenphoto is an exception. Zenphoto is a pleasure to use because there are no disappointments and I am grateful for your work. Give yourself a raise. (-:

Chris.

acrylian

Glady you solved the issue. It might indeed have bee some server cache or even the browser still serving an outdated page. But sometimes there are such hiccups where you cannot reproduce an issue again.

there is a accent on the "test".

Yes, the accent is supposed to be there to test if UTF8 filenames do work on your system. On localhost enviroments which basically inherit macOS/Windows you of course have UTF8 in general nowadays.

In general you can rather ignore that. Perhaps we should change that one from warning to notice. Generally I would still recommend to use filenames - this applies to images and album folders specifially - without any accents and other special chars because browsers still do have problems with that and depending on the visitor such chars may cause confusion/encoding in URLs. We have SEO tools for that like seo cleanup and such.

Thanks for your nice words about Zenphoto!

It is tricky to install,

It sadly depends on the server if it is tricky or not and we cannot forsee everything sadly. I gladly never had any real issues on numerous standard shared hosts myself.