Syntax Error on Upgrade

7jlong

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!

acrylian

Maybe the file is corrupt. Try a reupload.

7jlong

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.

acrylian

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

7jlong

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.

acrylian

Please post the info. Otherwise we are just guessing.

7jlong

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.

7jlong

(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...)

acrylian

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?

sbillard

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::setResourceLimit() 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.)

7jlong

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.

7jlong

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::setResourceLimit() 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));
}

7jlong

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

kagutsuchi

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).

7jlong

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.

sbillard

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.

7jlong

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!

acrylian

@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).

7jlong

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?

acrylian

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!

- 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.
The first may cause trouble, the second is as said by the warning optional.

- field collations. I haven't even looked this one up yet to see what it is all about.
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).

- 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.
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.

7jlong

Uh, yeah, when working with setup, there were errors. I know the difference, and realize that it was not setup that was showing me Internal Server Errors, but rather my host. If I tried the permissions dropdown, it would go to an Internal Server Error page. If I tried to hit Go at the bottom, Internal Server Error page. Only solution is to not ask setup to do anything, go back in via FTP and change back all the permissions, and tiptoe lightly out of setup without waking the slumbering beast. Host problem. Got it. OK. Though I still wish I could get setup to leave permissions alone completely.

As far as the theme goes ("day one" being October 2007 for me), if I should have upgraded to a newer version of default-dark at some point... again, might that have been noted in the upgrade instructions somewhere? You guys remind people an awful lot to go by your instructions explicitly and not use other scripts/etc, but at no point do I remember a suggestion to update "officially supported" themes - only to replace the home directory files and zp-core. Maybe this was dumb of me, but I had assumed (since they aren't mentioned) that as with cache and album folders, the rest could be left alone. I don't update with every new release, but I've updated a few times.

I mean, it's not like I was trying to carry forward some iffy third-party theme.

So, if I can scrap my old theme folder and replace it with a new one from the 1.3 package without everything going berserk, that's fine. I have been using default-dark with absolutely no modifications. I'll backup my current installation and give it a go. The theme does work as-is, but I wouldn't want setup to be unhappy about it. Or maybe I should stick with "don't fix what ain't broke."

acrylian

I just wanted to explain the setup warnings once again..;-) The internal server error probably should not happen. We will see if sbillard will have any idea to prevent this.

Themes. You are right that the upgrade instruction do not tell to replace the standard themes. We should add that. But isn't it quite obvious that from 2007 to 2010 something might have changed, especially for standard themes, especially improvements or new feature support?
Not even all former standard are included anymore (example theme was thrown out) and Zenpage theme is actually newer as well (since somewhere 2008).

Especially custom/customized themes may nor work fully (that is why many on our theme section are marked as incompatible). If you use an old standard theme without any change just try and if it still works good for you that is great. We of course don't test older standard themes with newer releases.

sbillard

Besides, setup did warn you about the themes even if the instructions were not explicit!

7jlong

Umm, no, considering that the date on the default theme info page lists 12/12/07, it isn't "quite obvious" that anything at all has changed with it since just after I first downloaded Zenphoto.

I guess what I'm trying to express is that I do exactly what you recommend, I read the difference between warnings and errors, between a Zenphoto problem and a host problem, I check my compatibility (ok, so I stupidly assumed that my host had already moved me to PHP5, but I think that's forgivable), I read the directions, I search the forums before hounding you about problems, and yes I even went in to the themes page to make sure I wasn't clinging to some hopelessly outdated theme from yesteryear.

Default still comes with the full installation package (the very definition of "default"), still marked as officially supported, and maybe I'm being dumb again, but if something is dated 2.5 years ago on your official pages I tend to suspect that it has not been modified since then and there's no need to go against your written upgrade instructions and replace the themes folder, considering that the convention with any other bit of software I've ever downloaded - patches, full installers, drivers, etc - is to mark the information page with a version number or at the very least a modification date.

What is most amazing is that you mention that you "of course" don't test your default theme with new releases. What's the point of having a default, included theme at all then?

acrylian

The date of the theme is the date of creation of the design itself actually, not necessarily all the code... I admit that is a mistake and agree we should update those dates. I appreaciate that as I actually have never thought about that. Sorry.

What is most amazing is that you mention that you "of course" don't test your default theme with new releases. What's the point of having a default, included theme at all then?
No, I actually said "We of course don't test older standard themes with newer releases" and meant "older versions" of those themes. We of course test the theme but just the current version of it. (Just to note that English is my 2nd language so sometimes I am thinking in my 1st....)

Generally we try to make most things backward compatible by not changing standards but not always that may work out.

7jlong

Well, like I said. I'm trying to follow what's on your pages and forums - your comments and contributions, not other users, who may have completely different factors to their problems. I am not slamming through dumb guesses and kludgey homebrew workarounds - as I mentioned I am not a programmer and do not understand the consequences of making it up as I go along. So I don't do it. Instead I've been reading and following steps religiously.

At any rate, the permissions thing still bugs me when I run setup if anyone has any thoughts on that. I am about to rip out my themes folder and move in the new one, hopefully that will be fine.

Thank you for all the help, and as for "Besides, setup did warn you about the themes even if the instructions were not explicit!"... yeah. I know. That's why I asked about it in the first place. I guess I just didn't realize that I was supposed to assume unwritten upgrade steps, since the rest of the documentation is pretty clear and concise.

acrylian

We appreciate your notes about our instructions not being clear in parts. It's too easy to leave out things for others if you are too used to them yourself.

7jlong

Thanks - I noted the revisions in the upgrade instructions. Hope this doesn't feel like you had to dumb it down too much, but with the small mods it is much more clear (to me, anyway).

hussonl

I had also this error when migrating from v1.2.4 to v1.3.
In my case, I only had to change PHP version (from v4.xy to 5.2) on my webserver (done throw a code in .htaccess at the root)
No more problem now.

kagutsuchi

Just an FYI, in the nightly builds there is now a check for PHP5 to make sure that this error won't occur.

Soleil

Please help !!! I just upgraded to 1.3 and got exactly the same error:

Parse error: syntax error, unexpected ',', expecting '(' in /homez.65/patrician/www/albums/zp-core/lib-Imagick.php on line 79

I am quite desperate, especially since I cannot understand exactly from the discussion above what has to be done to correct this error.

Thanks a lot in advance