Template overrides clarification

In working at some length with the overrides setup I am wondering if it can be made simpler? A basic definition of 'override' is:
The act of nullifying; making null and void; counteracting or overriding the effect or force of something

As v1.3.5 and greater allows for override setup, I presume there is a programming flow similar to:

if override =yes
then follow path to override files and apply
else use basic/default setup

If the above is true, it means the "if loop" is applied in every instance where the possibility of the overrides setup is being used. It should also mean the override file replaces, or makes null and void, the default file. Ergo, when overrides are being used there should be no need for the default file to be used or even be there. This would help to prevent confusion when editing files.

Trial & error has shown that in some cases, files can be safely deleted and in some cases they cannot.

Example 1
file 1 default - includes/languages/english/meta_tags.php
file 2 custom - includes/languages/english/custom/meta_tags.php

If the second file replaces the first file and makes it null & void, why is it that removing the first file causes problems? (cannot login to Admin for example)
A zero byte default file is all it takes to prevent the above error. This means no programming within the file is required, simply that a default file with that name be there. So why then, is there a need for a file by that name?

Example 2
file 1 default - includes/languages/english/html_includes/define_main_page.php
file 2 custom - includes/languages/english/html_includes/custom/define_main_page.php

In this case, removal of the first file does not cause any problems within the Admin section. But, the "Tools > Define Pages Editor" feature cannot access the files within the 'custom' directory.
This means someone can be using overrides exactly as they should but are not editing files within the 'html_includes/custom' directory. Therefore, next update their customized files are overwritten and all previous work to those files is lost, possibly making a site look really bad and/or some pages not to work properly.

It could also be, I'm totally off base and need some further guidence. :unsure:

I have not attempted to replicate what you have described but only offer that one must also have a template named "custom" in the includes/templates/custom area and that this template name must be active for any overrides in any "custom" folder to be used.

Custom, can be other names and you can have several templates installed and switch to them in the Admin > tools > template selection area.

i.e.:

classic
custom
future zen
my_template
summer
etc

Appreciate the input kobra, but I had already mentioned 'someone can be using overrides exactly as they should'. Although I think in Example 2, the situation is more of an oversight rather than a bug.

When Template overrides is being used the situation in Example 2 is easily reproduceable.

includes/languages/english/html_includes/

Remove one or all of the 'define_*' files then see what you can edit with 'Define Pages Editor'. If one file deleted you will not be able to edit that file. If all files removed you will not see any files listed in the drop-down selector. Directory permission is 777 for the 'html_includes' dir. and the 'html_includes/custom' dir. File permissions have been tested at 777 but still no files shown.

KoBra:

I have not attempted to replicate what you have describedSo I went in and tried this. And what you describe is in fact true but only in the sense that one cannot then edit it from the admin.

It is valid and will be parsed by the catalog side of the system even when there is no matching named file in the default folder.

The admin edit function processes differently, first looking at the available files in the default for selection and then looks for one that might apply to the current template.

For your first example the only problem that I could see is on the admin side. No problems shopping buying checking out etc on the catalog side. Again, the admin processes differently, being currently mostly "Legacy" code.

So you have pointed out a process difference and this is what you state as the reason that you are concerned:> you:

This would help to prevent confusion when editing files.
If you follow the BASIC policy of NEVER editing a "core" file but always a copy, either in or one that you will place in the template specific folder, this is what prevents all confusion. For the html_includes protection > set the default files to non-writeable and the admin will not allow even an erroneous edit to be saved.

If it is space that you are concerned with(I do not know that this is valid), as you noted you can have a "zero byte" file named correctly.

Goes to show that when editing/testing one should not do it when tired. Another hour or so of more thorough testing has provided me with the following information -- related to using Template overrides and 'Define Pages Editor'.

dir & file permission:
755 html_includes
644 html_includes/define_main_page.php
(even 0 byte file is OK, just need a file by the same name)

766 html_includes/custom
766 html_includes/custom/define_main_page.php
(766 appears to work just as good as 777 but is preferred due to better security)

HTMLarea or FCKeditor will both state
Editing file:
includes/languages/english/html_includes/custom/define_main_page.php

So it would seem that any confusion was strictly on my part.

I apologize for any confusion "I" created but as stated in the Thread title, clarification of some of the best kind is being reported. :wink2:

Rob,

Not at all...It was an enlightened view into frontend function versus somewhat "legacy" code backend function.

The dev's have paid specific attention to the frontend but are working at a backend rewrite for some future release.

NOTE: If there isn't a file in the default directory ... there is nothing to override when you have files in your templates and overrides directories ... :eek:

I understand and agree with what you say, Linda, but it is different logic than what I had described initially.

if override =yes
then follow path to override files and apply
else use basic/default setup

The logic you referred to would be more along the lines of:

always look first for files by default path/name
if override =yes
then follow path to override files and apply
else use basic/default setup

Thinking along the lines that "if" overrides are used there is no need for the default file, that extra first step is what confused me.

Would it not make ZenCart run faster to have to have an "if = overrides" statement come first? I realize coding changes would be involved and could be a big change. Also not sure if worth the effort involved. It was just a thought. :smile:

In many places that is how it works ... in others not 100% in that manner ... there should always be default files and then the override files ...

Some things grab the list of files in a directory then look for the override ...

If there isn't anything in the default, it doesn't know to look for the override, as in this case ...

In doing a Template upgrade I notice that, although everything else is working correctly, the default buttons are being used instead of the new button images.

includes/templates/template_default/buttons/english/button_in_cart.gif

instead of

includes/templates/custom/images/btns/in_cart.gif

Can someone explain what I am missing?

/english/

missing something in the directory??? :unsure:

Can you be more specific on your path?

I had thought when using overrides and a 'custom' template dir., all image overrides would also apply. Sounds like you are saying that images need to be uploaded somewhere other than the 'custom' template dir.

includes/templates/YOUR_TEMPLATE/buttons/english

You have to follow the same structure in order to override.

Thanks, got it now.

As a general observation, I'm curious about the need for duplication of names. If images are in a dir. called 'buttons' then why the need to use file names starting with 'button'?

Just wondering outloud is all.

They wouldn't let me call the file: fred.php ... :cry: