Hello -

Anyone seen this one?

Upgrading from 1.2.6 to 1.3. Followed all directions and ended up with this error:

-----

Parse error: syntax error, unexpected ',', expecting '(' in /home/inflight/public_html/zenphoto/zp-core/lib-Imagick.php on line 79

-----

...when going to either http://www.inflightshutdown.org/zenphoto/ or http://www.inflightshutdown.org/zenphoto/zp-core/setup.php

Lost!

Maybe the file is corrupt. Try a reupload.

No good. Deleted the file on my server, deleted the local copy of the download, re-downloaded entire package and un-zipped, replaced files on my server - same error.

Please post both the line of the file you get the error on and additionally please some details about your server (PHP etc).

Also downloaded and tried builds from 6/1 and 5/27 to see if there was a hiccup somewhere along the line; the only notable thing that changed was that the error moved to line 80 in the 6/1 build and back to 79 for the 5/27 build.

Please post the info. Otherwise we are just guessing.

I am not a programmer. I do not know the convention of applying line numbers to PHP files to interpret error messages. I looked for something that might stick out, but it is not my "native tongue", so to speak. For drill I dumped it into a text file and counted lines and "79", as I counted, was blank. Looked nearby, no dice.

PHP 5.2
MySQL 5.0.90

GlowHost is my hosting service.

(also, it is clear that our two messages re: your request for info and my mentioning trying other files overlapped, and I don't think 6 minutes was an unreasonable amount of time to look up the info that you asked for. geez, usually its the end user that is impatient...)

Sorry about sounding impatient, didn't look at the time of the post.

Also sorry, that I have no idea what this could be. MAybe you could post a bigger part of how your file looked around the lines in question?

just as a sample, there are the lines of the file as I have them around the line number where you got the error:

77  `// Imagick:etResourceLimit() crashes if called statically (prior to 3.0.0RC1)`
78  `$mem_lim = getOption('magick_mem_lim');`
79  `if ($mem_lim > 0) {`
80  `$temp->setResourceLimit(Imagick::RESOURCETYPE_MEMORY, $mem_lim);`
81  `} else {`
82  `$temp->setResourceLimit(Imagick::RESOURCETYPE_MEMORY, $temp->getResourceLimit(Imagick::RESOURCETYPE_MEMORY));`
83  `}`

At least here, there are no blank lines close. (line 76 is blank as is
line 84.)

Working on it (again, not a programmer and don't have the right tools handy - am having a colleague look at it).

I really do appreciate the quick replies and assistance, am trying to come up with useful info to help troubleshoot, guess the head-scratching is making me touchy.

OK - colleague busy but pointed me to Notepad++ to have it open and number the code for me. It calls the line after your example #79, but still in the same ballpark.

So, since this chunk of code looks exactly the same as what you posted, is there something screwy going on server-side with my host?

-----

// Imagick:etResourceLimit() crashes if called statically (prior to 3.0.0RC1)
$mem_lim = getOption('magick_mem_lim');
if ($mem_lim > 0) {
$temp->setResourceLimit(Imagick::RESOURCETYPE_MEMORY, $mem_lim);
} else {
$temp->setResourceLimit(Imagick::RESOURCETYPE_MEMORY, $temp->getResourceLimit(Imagick::RESOURCETYPE_MEMORY));
}

Dug around my host a bit. I don't know exactly what "server default" translates to as far as PHP interpreters go (which is what my account was set on), but the other two options were PHP4 and PHP5. PHP4 repeats the problem, PHP5 coughs up a new one. I will work on the new problem, but I think the old error might possibly be attributed to: just because your host flaunts PHP5 doesn't mean that they have turned it on for your account. Sorry, I guess I should have checked compatibility more thoroughly before sending up flares.

A quick peek around the forums reveals that the new problem might be a fairly routine one and I am going through the usual troubleshooting to sort that one out.

-----

Fatal error: require_once() [function.require]: Failed opening required '' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/inflight/public_html/zenphoto/zp-core/functions.php on line 28

Imagick (the PHP extension) does require PHP5, so that's the main problem right there. Strange that the server would still report Imagick as available. lib-Imagick doesn't check for PHP5 since the Imagick extension requires it (dependency of a dependency).

Yeah, once that was sorted out it got past the Imagick problem.

After digging around about the new problem for a little while I found that it was somehow upset about loading Captcha. Deleted those four lines from functions.php just to see if I could get it to think about something else, or at least show me the setup screen.

Got through, and setup concluded that despite my old Zen gallery having been up and working fine since 10/2007, every last core file was somehow suspect and I (or my host) had many options set completely wrong. When I tried to work with any of the info I immediately got an Internal Server Error, and eventually the setup screen wouldn't load either. I'm sure it's my host's fault.

So I'm ripping it all off of my server, am replacing the backup of my 1.2.6 version, and will leave well enough alone. I can't stand any of the web-for-dummies galleries that I've tried to work with (or the over-the-top Gallery) and really like Zen, but don't want to be sifting through code and server settings and permissions and all that either. Lazy user, I guess.

Thanks for the help.

Fatal error: require_once() [function.require]: Failed opening required '' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/inflight/public_html/zenphoto/zp-core/functions.php on line 28

That plus the setup file list complaints would indicate that the upload of zenphoto did not go properly.

BTW, setup will tell you what version of PHP (and MySQL) you have running.

Well, OK, but that info appearing in setup doesn't help much when the first error stopped me from even getting to the setup screen. My fault, OK, lesson learned.

As for the upload, perhaps it is time to review the upgrade instructions.

1 & 2: backups performed, fine.

3: All files (not folders) in the remote home directory deleted. All. If this is too strict an interpretation of "remove the files" - including the existing .htaccess file - that might be problem #1, and needs clarification. Also, step 3 indicates that I will need the info out of my zp-config file, which doesn't appear to actually be the case going from 1.2.6 to 1.3, as it seems to grab this from the zp-config file that is in the zp-data folder. At any rate, deleted zp-core folder per instructions.

4: Downloaded, unzipped, uploaded new zp-core folder and new home directory files via SecureFX. No errors or special notes from FTP software.

5: The .htaccess file. Where is this meant to come from? If I deleted the files in the remote home directory, the old one is now gone. There is not a new one in the set of local new files from the download. The closest I can find is an htaccess file (no dot) in the new zp-core folder, which I briefly imagined might be a source for the setup routine to place on the server in the remote home directory - but since I am supposed to be checking this before going to setup, this seems unlikely. So, was I intended to leave the old .htaccess in the home directory where it was? For if that is the case, the upgrade instructions might have mentioned this somewhere.

6: Setup. This is where it blows apart for me - resulting in the error already mentioned above.

What I will try tomorrow is once again (third time) removing every shred of new downloaded files from my computer in case one of them went bad in transit, downloading a fresh copy of the 1.3 package, and starting again from there. 1.2.6 is currently running without problems on my server, and I should be able to upgrade as described.

If there is anything I mentioned above that I should do differently, I'd love to know about it.

Thanks!

@kagutsuchi: The problem is I got also an report about not being able to install Zenphoto on PHP 4.4.x (we actually are still not strict PHP5...). So even if Imagick is not used or available on that server you can't install Zenphoto without PHP 5 it seems.

@7jlong: As you noted the .htaccess file exists as a template within zp-core and should normally be created by thet setup (there should be an option to do so if no one already exists).

OK, finally back up using 1.3. What I've learned:

Setup caused problems for me every time I went into it by changing permissions on all php files in zp-core and the home directory to 777, which upset my server. Manually went in and changed them all back via FTP to 755, which made everyone happy.

Because of this, asking setup to change permissions for me would result in an internal server error. Same for asking it to write me a new .htaccess file. (I dragged in the template from the zp-core package so that I did not have to deal with the mod_rewrite issue.)

Again, I'm not a programmer, but I even went in to zp-config.php and changed the last bit to 755 and put the file back on the server, no change. Setup still changes files to 777 as soon as I run it.

The rest of the warnings in setup are still a mystery. It is upset about:

- magic quotes and my host's mbstring settings, fine, I'll talk to my host. a quick spin through the forums reveals that this will not disturb the universe, at least in the short term.

- field collations. I haven't even looked this one up yet to see what it is all about.

- every single theme file. I have some others that I auditioned when I first installed still on there, so I guess it's time for some housekeeping anyway. However, I've used the default dark theme since day one, so I'm not sure what setup is so uncomfortable about.

So that's that. It seems that my server settings have not been interfering once I solved the PHP5 problem, and it is likely that the second problem (the Captcha issue) was from an upload problem. However, this permissions thing is a bit irritating. How to solve that? Or just stay away from setup.php forever?

Sadly not all servers are setup the same way thus several behave differently. We can't know and test all. I had never any issue with the permissions on shared hosts, although some refuse to let setup do it. But an internal server error I did not encounter so far.

Setup "warns", those are no errors!

[i]- magic quotes and my host's mbstring settings, fine, I'll talk to my host. a quick spin through the forums reveals that this will not disturb the universe, at least in the short term.[/i]
The first may cause trouble, the second is as said by the warning optional.

[i]- field collations. I haven't even looked this one up yet to see what it is all about.[/i]
This is important if you encounter problems with special chars in titles or descriptions. A mysql table can have an encoding but several fields of that table can also have a different one (for whatever reason..)

If you use only plain English you will probably not have any encoding issues but people with other languages might (as I am with German for example).

[i]- every single theme file. I have some others that I auditioned when I first installed still on there, so I guess it's time for some housekeeping anyway. However, I've used the default dark theme since day one, so I'm not sure what setup is so uncomfortable about.[/i]
Well, if you use a theme since "day one" it may not work correctly with the current release. A lot has changed since then.
Setup warns if the file time is out of variance so there "might" be a probem.

I am sure my collegue will respond later as well.