Except it's not
Quote:Zenphoto has detected a change in your installation.
Your database software has changed from MySQL 5.1.66 to MySQL 5.1.66.
The change detected may not be critical but you should run setup at your earliest convenience.
You can see there the math is gone teh silly.
I re-ran the setup, twice, before posting. PHP error log is empty of relevant zenphoto errors (just has one where it says it can't install the .htaccess for me, which yes, I know).
The only thing I see in my debug log is this:
{25979:Mon, 04 Feb 2013 01:31:48 GMT} Zenphoto v1.4.4.1[596740f6519a92b55e371274624e4a922ff60676] NOTICE: Constant DATABASE_SOFTWARE already defined in /home/public_html/gallery/zp-core/functions-db-MySQL.php on line 13 define called from require_once (functions-db-MySQL.php [13]) from require_once (functions-basic.php [151]) from require_once (functions.php [18]) from require_once (admin-functions.php [9]) from index.php [274] {25979:Mon, 04 Feb 2013 01:31:48 GMT} NOTICE: Constant DATABASE_MIN_VERSION already defined in /home/public_html/gallery/zp-core/functions-db-MySQL.php on line 14 define called from require_once (functions-db-MySQL.php [14]) from require_once (functions-basic.php [151]) from require_once (functions.php [18]) from require_once (admin-functions.php [9]) from index.php [274] {25979:Mon, 04 Feb 2013 01:31:48 GMT} NOTICE: Constant DATABASE_DESIRED_VERSION already defined in /home/public_html/gallery/zp-core/functions-db-MySQL.php on line 15 define called from require_once (functions-db-MySQL.php [15]) from require_once (functions-basic.php [151]) from require_once (functions.php [18]) from require_once (admin-functions.php [9]) from index.php [274] {25979:Mon, 04 Feb 2013 01:32:19 GMT}
If you install from the GitHub master branch (the support build) the overview will say 1.4.4.1s. The only release that will show as 1.4.4.1 with no letters is the original 1.4.4.1 release, so I would have to presume your download link is not to the correct place.
Ah, the link is to https://github.com/zenphoto/zenphoto/archive/master.zip
Tried that and got caught in an endless loop of upgrades and it said I HAD to make my folders 777 (they're set to 755, dunno why that's a problem). Eventually I flushed caches all over the damn place, including APC, and it ran through an upgrade successfully. I'm willing to chalk the cache crap to my server (note to self to turn pagespeed caching OFF for zp-admin) but that it refused to accept 755 as a valid folder permission is annoying. I set 'em right back of course.
And yes, $conf['CHMOD'] = 0755; is set in my .cfg file, which I actually just rebuilt off the sample, so I could be sure I had the latest settings
Bah, you guys switching to Git ruined my old deployment scripts I used to use svn switch, and I just can't get git archive to work the same way as I used to. (Not your fault! I've been meaning to work out new deployment scripts. You and MediaWIki are 2/3rds of what I use!)
Maybe you still are not on the current master build. If you have set CHMOD in your config file there would be nothing saying you HAD to change the value. And any suggested value would have been 0666 if you started with 0755 in the config file. All the suggested values are file access values, so do not include the "execute" bits and therefore will never have "7" as a digit.
If you had not got CHMOD set in the config file then you do get a warning message to set the permissions. That message (as well as the notice if there is already a vale set) do explain what the values are all about.
Current Master Build... Sorry, I'm not sure what you mean when you say that.
I only have one install of ZenPhoto, and I was in the right file (when I changed settings in it for DB stuff, it broke as expected).
Files were 666, no problem. FOLDERS were 755 on the sevrer, but the upgrader yelled at me saying I had to make the 777. I did that, ran the upgrade, changed 'em back. It wasn't an option or warning, it was an outright ERROR, full stop, you cannot proceed.
http://cl.ly/image/3o2J0r1e0L3y
I re-ran that just for you
I am 100% certain I have the right .cfg file (/zp-data/zenphoto.cfg) and I am 100% sure it says $conf['CHMOD'] = 0755;
It's never thrown that error before (been using since '09 ). However odd that is, though, it does explain it.
DSO PHP is locked so php generated files are owned by 'nobody' - my cache and cache_html folders are owned by nobody:nobody, with 755, and work fine.
What's new is that it wants the same permissions on albums and zp-data, though. Previously it would check on the log files, and I can undertand why this is better, though frustrating for me I upload all the images via FTP anyway since I'm usually doing 100 at a go, and it's far more practical, so I don't need albums or uploads (or plugins?) to be writable in the long run.
Well consider this resolved, in so far as it's not you, it's me, and I'll adjust. I haven't see the erroneous upgrade notice since.
It would be nice if it warned instead of failed, like "Cache is not writable. You will not be able to use caching unless you correct this..." and "albums is not writable, you will not be able to upload albums from zp-admin..." but again I'll adjust. it's still way less weird than how I have to upgrade PHP and mod_pagespeed
ETA: I feel like the spacebar guy! http://xkcd.com/1172/
I guess if the cache was really writeable then the error was wrong. But if Zenphoto really could not write to the cache then it would be pointless to continue as Zenphoto would crash upon execution.
We use the PHP function is_writable($path) to see if the folder is writeable. I suppose that must be reporting that it is not in your case. I guess we could try to write anyway and see what happens.
I think your is_writable... is working fine, on reflection. The cache_html folder worked (cache didn't because I had it set one more folder deep - cache is NOT writable, but cache/folder/ was, I changed that, it's happier now).
The only annoyance is that zenphoto wants /albums, /plugins and /zp-data as writable and I ... don't Which makes me weird (and the spacebar guy). I'm a little tinfoil hat wearing lady, though, and I know it.
The data folder needs to be writeable for much the same reasons as the cache file. The other two are possibly exceptions. But, Zenphoto does write to both folders on occasions. The album folder if you create a dynamic album or crop an image and the plugins folder when certain plugins initialize themselves.
Amazingly enough? I never crop images in ZenPhoto and I'm not using any plugins That the data folder needs to be writable is interesting. I have the log files writable, and everything works fine.
Like I said, it's probably just me, and that's totally okay.
(Original problem of MySQL being upgraded has gone away! Yay!)
Quote:That the data folder needs to be writable is interesting. I have the log files writable, and everything works fine
There is also a configuration file there. Maybe some others depending. So how did those files get there in the first place? And what if you delete one? How does it get back?
Just to loop back to this: WHY does the Data folder need to be writable?
Previously I made a data file for the various logs, chmod'd them 777, and let the logs run. Since now ZP creates them parsed on the fly and needs to delete them when you press delete, that methodology no longer works.
For ModPHP (DSO), the fix is (alas) to make the folder 777. I could switch to FastCGI, but there are reasons
(Sidenote: WordPress lets you do this with a very odd set of defines like FS_CHMOD_DIR and FS_CHMOD_FILE. No idea if that's anything to consider in the long run, as my upgrade process is now
- Upgrade files via Git
- chmod 777 albums plugins uploads
- Visit page, run upgrade
- chmod 755 albums plugins uploads
Not perfect, but it satisfies me
The zp-data folder needs to be writable by the server because there the config file is created and also the logs are stored there. By any means nothing should be 777. 775 or 750 should work but of course as often discussed if the server does not run under the same user as zenphoto (see the user guide) there may be conflicts. How strict works is also server dependent.
It's the installer/upgrader that demands 777. I tried 755, but y'know modPHp is a moron.
It would be nice if those folders gave warnings and not "You Shall Not Pass!" type failures, since ZP will work, just some things won't. It's a 99% thing it'd be nice if it trusted me on that one.
Update. SOLVED.
Keeping modPHP/DSO, I installed mpm-itk: http://mpm-itk.sesse.net/
This lets me run everything as the user, which let me change permissions back down to something sane and sensible.
Re-ran the installer, since PHP permissions had changed and it 'broke' my files in zp-data (which were owned by nobody) and ... I'll be posting the messy details on http://halfelf.org
But I now have my cake, and Edith too!