Backing out an override

[kobra]

This is a problem that I just encountered and I am seeking the correct solution and the normal procedure that Zen Cart uses in these instances.

Zen Cart - 1.3.5 - fresh install - no modules

Custom template; created. tpl_ header.php copied from template_default to includes/templates/custom/common.
I did not like the changes that I made and deleted the overriden tpl_header.php file
Received this set of errors:

Warning: main(includes/templates/custom/common/tpl_header.php): failed to open stream:
No such file or directory in home/public_html/domain/includes/templates/custom/common/tpl_main_page.php
on line 70

Warning: main(includes/templates/custom/common/tpl_header.php): failed to open stream:
No such file or directory in /home/public_html/domain/includes/templates/custom/common/tpl_main_page.php
on line 70

Fatal error: main(): Failed opening required 'includes/templates/custom/common/tpl_header.php'
(include_path='.:/usr/lib/php:/usr/local/lib/php') in
/home/public_html/domain/includes/templates/custom/common/tpl_main_page.php on line 70

Zen Cart did not revert back to the file located in the template default fileset, cleared cache, closed browser, tried another browser.
Copied the core tpl_header.php, un-edited, to includes/templates/custom/common and all was functional again.

Now, it has been my understanding that Zen Cart first looks for an overriden file and if none is found then it uses the default file.
But this current action does not appear to follow this convention.

Checked the wiki and found a list of "automatically included files" and these are not among the list.

Is this normal? Where is the fact that this file was overriden stored?

[Kim]

Kobra- URL? That is odd behavior. What browser were you using?

[kobra]

UPDATE on this thread...after a bit of testing and my mis quoting myself here is the outcome.

I actually did not delete the tpl_header.php file...but renamed it to 0tpl_header.php, which I thought was unique and would not be picked up. I still believe that it is unique but doing this throws the error.

When I actually deleted the file...Guess what...no error. So to anyone that I might have suggested the renaming with "0", "1". etc. Please do not use this method opting instead for changing the extention as is necessary for .css files.

If there is anyone that might know the underlying reason for this please enlighten me.

[seethrou]

Please refer to the the topic below, it has something related to the file naming.
Disable Gift Certificates

.

[Sketchy]

kobra, the easiest way to understand what happened is... say you have an image on your desktop and rename it from "nightsky.jpg" to "01nightsky.jpg", you can still open it. But, if you change the file extension to "nightsky.jpg.dark" , you won't be able to open anymore as the O/S won't understand the file extension any longer.

Anything before the last period(.) is just renaming of the given file name, but anything after the last period(.) is the actual file extension that basically gets called into play. To render a file useless, you must add any kind of jumbo at the very end. Example: tpl_header.php.blah. The most common is the addition of .bak at the very end. Those methods will "hide" the file, so it will be overlooked during file calling phases. If a file is found only with an improper actual name, but the right file extension name... that will give you your stated errors.