How to override define_paths.php?

The defined_paths.php files (either) contain a comment that, “It should NOT be necessary to edit anything here. Anything requiring overrides can be done in override files.” (in the /includes/...) or “It should NOT be necessary to edit anything here. Anything requiring overrides can be done in override files or in configure.php directly.” (in the /admin/includes/...).

I have never found any documentation whatsoever that indicates the override system applies to administration (to the contrary, that it doesn’t). I haven't found documentation that indicates how to override anything other than theme and a few other odds and ends.

I recently upgraded a heavily customized Zen Cart 1.3.9h site to 1.5.4. While that was being tested and taken live, 1.5.5 and 1.5.5a were released. That broke the defines that been put in configure.php, though, strangely, it didn't appear to break anything in the front-end.

By the way, the Upgrade Instructions indicated that it was only necessary to customize any files changed in 1.5.5 and upload those; however, when logging into admin, there is a warning that a database upgrade has not been done — when that is done, the configure.php files are updated).

To continue testing the 1.5.5a conversion (on a test site), I have modified the /admin/includes/defined_paths.php file. However, I would expect the override system that works on so much of the front-end to be able to handle this for /includes/defined_paths.php. Can someone explain please?

By the way, the way the defines are done in defined_paths.php could be simplified. Either all the defines will exist, or none of them will (because the only place they should be defined is in one of the defined_paths.php files). So it is only necessary for a single “if ()” statement to enclose all the defines. I suppose the saving is marginal, but it’s cleaner :)

Regards,
John

JRGoold:

I recently upgraded a heavily customized Zen Cart 1.3.9h site to 1.5.4. While that was being tested and taken live, 1.5.5 and 1.5.5a were released. ...
By the way, the Upgrade Instructions indicated that it was only necessary to customize any files changed in 1.5.5 and upload those

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

JRGoold:

I have modified the /admin/includes/defined_paths.php file. However, I would expect the override system that works on so much of the front-end to be able to handle this for /includes/defined_paths.php. Can someone explain please?

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.

JRGoold:

By the way, the way the defines are done in defined_paths.php could be simplified. Either all the defines will exist, or none of them will (because the only place they should be defined is in one of the defined_paths.php files). So it is only necessary for a single “if ()” statement to enclose all the defines.

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.

DrByte:

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

DrByte:

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.

DrByte:

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.

JRGoold:

However, I would expect the override system that works on so much of the front-end to be able to handle this for /includes/defined_paths.php. Can someone explain please?

I obviously got too enamoured of my own words and allowed the real question (quoted above) to get lost, for which I apologize.

The question is, “How do I override .../includes/defined_paths.php?”

The objective of an override system is to be able to modify the behaviour of core files, but not alter core files.

What would be really, really nice :smile:, is to have a user-created file that continues the definition of constants that defined_paths.php does — essentially appending additional defines to it (rather than making a copy of defined_paths.php somewhere and then modifying it).

Extend defined_paths.php rather than replace it.

JRGoold:

.../docs/whatsnew_1.5.5.html (as included in 1.5.5a) says:
[quote]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
[/QUOTE]Apologies. I can see how you would have assumed no database changes were required, based on that wording. Clearly a line is missing: "You will also have to run zc_install to upgrade the database too."

JRGoold:

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

defined_paths.php

have been executed, or none of them have.

No, that's not how the code is written, nor intended. It was written to intentionally allow the user to place their own defines in configure.php and potentially even override the ones in defined_paths if there were some (extremely rare) need to do so. It's not defensive programming. It's creating more control for the user. But, clearly we're seeing it from different angles.
Regardless, it works as described.

JRGoold:

The question is, “How do I override .../includes/defined_paths.php?”

The objective of an override system is to be able to modify the behaviour of core files, but not alter core files.

What would be really, really nice :smile:, is to have a user-created file that continues the definition of constants that defined_paths.php does — essentially appending additional defines to it (rather than making a copy of defined_paths.php somewhere and then modifying it).

Extend defined_paths.php rather than replace it.

You started this discussion asking about overriding defined_paths ... but now you're talking about *extending* it, doing something AFTER it.
So, I'll clarify my earlier response:
a) defines for BEFORE defined_paths.php go in configure.php
b) defines for AFTER defined_paths.php go in extra_configures/your_php_files_here.php

No apology needed.

Again, it appears to be a matter of view-point.

.../includes/extra_configures/ That sounds like exactly what I'm looking for. Perfect. Thank you very much for your help DrByte.