How to override define_paths.php?

[JRGoold]

I think you misread those comments ... they were talking about going from v155 to v155a ... not from v154.

.../docs/whatsnew_1.5.5.html (as included in 1.5.5a) says:

Upgrade Instructions

This document only mentions the actual changes specific to v1.5.5 since v1.5.4.
From v1.5.4

Simple: if you are using v1.5.4 already and have not customized any of the files listed in the changed_files-v1-5-5.html document, then simply replace those files with the new files as listed.

If you HAVE customized or altered certain files, simply re-do your customizations in the new version of those particular files by making the same changes needed.

If you are using Addons/Plugins that have made alterations to those files, it is best to compare those changed files against the original Zen Cart files for the version those plugins were built for, and see what changes were there ... and then re-build those changes in the v1.5.5 file.

To v1.5.5 from v1.5.3 or older

If you are upgrading from a version OLDER than v1.5.4, then please do a standard site upgrade. Be sure to review all the links in this article, including tips on staging the upgrade in a separate directory/folder.

I don’t think it unreasonable to think that last line implies that upgrading from 1.5.4 to 1.5.5 (or 1.5.5a) only requires changes to the file system

What EXACTLY have you changed in that file?

The system FIRST loads configure.php and THEN loads defined_paths.php .... so whatever you defined in configure.php takes precedence. And then defined_paths.php simply takes care of defining whatever else is needed by the system.

You should NOT need to touch defined_paths.php at all.

It is not so much changing as extending — the extensive customization means there are a small number of additional directories containing such things as “sample” files (extracts from e-books that customers can preview before committing to purchasing actual e-books) and so on.

No, not really. If it were done that way then none of the cascading effect I just described above would work at all. It's that way for this specific reason.

A define(), as you know, is PHP’s way of letting programmers create their own constants; since they are constants, they cannot be redefined. The way I read the code and the documentation/announcements, was that configure.php sets the very top-level (basic site) constants to allow code to access the file system and database and defined_paths.php then builds on the top-level constants to define some additional constants. So, when the catalog location is known, one can create constants that give the location of sub-directories of the catalog and, crucially, those defines (in defined_paths.php) will not need to be changed if one moves the store's catalog to a different location (e.g. a differently named subdirectory of the web-root or to a different hosting server).

So, based on this view of the architecture, defined_paths.php is not over-ridden by configure.php; defined_paths.php simply extends the former. Since we are talking “constants”, those defines should only be done in one place and should only be executed once. if (!defined()) is simply defensive programming to protect against errors (such as uploading an old version of defined_paths.php). It also, I am sure not coincidentally, means that running 1.5.5, having only uploaded changed files (which exludes configure.php) means it will run and can trap that the install script has not been run.

So, I'm back to my original premise: either all the defines in

defined_paths.php

have been executed, or none of them have.