Fatal error: Cannot redeclare date_diff() (from an upgrade by Softalicious)

I had an installation of Zen Cart and got the title error. The full message is

Fatal error: Cannot redeclare date_diff() in [store URL]/admin/includes/functions/general.php on line 3001

I googled this and found the FAQ.

I actually think I had 1.3.9, in hindsight. I upgraded to 1.5.0.

I still get the fatal error when trying to access [storename]/admin. What could be happening?

Zen Cart v1.3.8a and older contained function definitions for date_diff(), which was fine in older versions of PHP.

But newer versions of PHP have that function built-in, so any scripts which attempt to redeclare the date_diff() function, will trigger the fatal error you're reporting.

Therefore this means that you are using files on your site which contain older code. You will need to remove all traces of v1.3.8a or older from your server. This includes all code for older addons which may have used old functions or old copies of those functions.

http://www.zen-cart.com/wiki/index.p...Obscure_Issues

I'd have expected the upgrade process to clean up the old files.... is there a log kept? there might have been a few error messages. Where?

Given that it didn't update some files, how can I fix the installation? I did look at the file that caused the crash, as suggested on the Obscure Issues page ... but this doesn't help. The old file and the new file are very different. This installation should not have any customization other than through the ZenCart interface. Can I just clean out the old php files and replace them with new ones from the 1.5 package? I'm hoping all my setup is in the SQL!

Sounds like you haven't followed the official upgrade instructions:
www.zen-cart.com/upgrade

Right you are, Dr. Byte, I did not see them until I'd already upgraded. I saw the FAQ and it said to upgrade immediately. I checked my cpanel and there was a suggested Softalicious upgrade from 1.3.9h, which is what I had, to Zen Cart 1.5. So I ran it, and here we are. The question is what now.

(By the way, the chance that I'd be able to follow those "official instructions" is somewhere around 1%. Too many things I'd have to figure out. It's not relevant here, or I'd point them out. I don't manage SQL databases every day, nor set config files and modify PHP, not even every year. The installation was probably a clean 1.3.9 installation, so how the old stuff got in there is puzzling. Maybe Fantastico, which was used for the original installation, had them, and it was all working until PHP was updated. I see that there was another user with a similar problem with 1.3.9h, and it was implied that he'd garbaged the PHP. I'm guessing not. This may have to do with unmaintained installation scripts. Since scripts are widely used, the problem will recur, and it needs a clearer fix than "pour over every file to see what is different.")

An upgrade is basically a very quick re-build of your site.
The reason you do the comparisons that the instructions explain, is so you can very quickly see all the things you changed in the PHP files, so you can very simply and quickly redo them.

Another part of the instructions that you say you think you could only do 1% of, is the "staging" in another folder+database, basically a "test copy" of your site so you can do all the testing and preparation away from your live store, so that if you do run into any problems your store won't be offline while you fix them. It looks/sounds harder than it really is.
But, you don't have that luxury now, unless you have your hosting company restore your site from the backup that was done the day before you clicked that unsupported "upgrade" button.

And, yes, part of the upgrade process is deleting any files on your server that no longer belong or are no longer needed. That part becomes clear when you use an automated tool like WinMerge to show you all the changed files, added files, deleted files, etc.

Quote:

---

Originally Posted by DrByte

An upgrade is basically a very quick re-build of your site.
The reason you do the comparisons that the instructions explain, is so you can very quickly see all the things you changed in the PHP files, so you can very simply and quickly redo them.

---

What I've been asking is whether or not normal store configuration involves changing the PHP. I don't think I've edited any of those files before. "A quick re-build" normally involves writing the new files over the old ones, and any custom files are separate and not touched.

Quote:

---

Another part of the instructions that you say you think you could only do 1% of, is the "staging" in another folder+database, basically a "test copy" of your site so you can do all the testing and preparation away from your live store, so that if you do run into any problems your store won't be offline while you fix them. It looks/sounds harder than it really is.

---

I'm sure it's much easier for you to do it than it is for me to see how to do it. And once I know how to do it, sure, it will be much easier, I assume. But that doesn't get me from here to there.

Quote:

---

But, you don't have that luxury now, unless you have your hosting company restore your site from the backup that was done the day before you clicked that unsupported "upgrade" button.

---

Oh, I could take it back, but it involves monkeying with the SQL database, which I would very much prefer not to touch. I did a backup as recommended before running the script. I'm not sure I'd gain anything. I also have, from that backup, a copy of the files as they existed before -> 1.5, and I have the 1.3.9h installation files, for comparison.

Quote:

---

And, yes, part of the upgrade process is deleting any files on your server that no longer belong or are no longer needed. That part becomes clear when you use an automated tool like WinMerge to show you all the changed files, added files, deleted files, etc.

---

The number of changes are massive. However, I only used WinMerge to compare two files. This really should not be necessary, because customizations should not be held in the files that are being updated. Sure, if they are, they will be overwritten. I never completed the store, I hadn't removed the ZenCart stuff from the home page. I've now gotten the admin page loading, by overwriting all the files under admin, and then renaming the admin directory, but the site is "down for maintenance."

I'm suspecting I need to do the same with the non-admin PHP. And then I'll need to figure out how to take it out of maintenance mode. I searched, found nothing. I did try overwriting all the older files with new, and it broke the installation completely, probably because of some non-PHP file or something.

Found the "Down for Maintenance: ON/OFF" setting, under Configuration/Website Maintenance. Before that, I uploaded the installation directory that I'd deleted per instructions, and reran it. One "configure" file wasn't writeable. I made it so with my site File Manager, finished the installation script, and then restricted the permissions again, and deleted the installation directory.... It seems to be working now, still needing customizations.