Where do I find proper files where constants are defined?

Such as ACCOUNT_DOB?

Some are defined in the database. A fast way to find them is to use the first input field on the Developers Toolkit page: Admin->Tools->Developers Toolkit.

Or, you could look up constants or other text via other fields using the same tool. The various input boxes are used to search various selective areas. The last one searches the whole site's files.

https://www.zen-cart.com/tutorials/index.php?article=39
https://www.zen-cart.com/tutorials/index.php?article=38

I have several times had the same question.

So why is it that the Wiki doesn't contain this essential information? I have been trying to locate an Admin setting for SHOW_FOOTER_IP without much luck. It's defined in 'tpl_footer.php' but I can't find it using the Dev Toolkit search, no definition in the Wiki and nowhere in the ZenSupport area. The forums hit it, but mostly just as quotes.

What we all need is something that defines all these constants and locates them in the standard ZenCart files:

E.g.
SHOW_FOOTER_IP - Set in Admin/Customer, this option lets you choose whether to display a customer's IP address on every page as they browse the site.

Default files where it occurs:
admin/customer.php
includes/templates/template_default/common/tpl_footer.php

The ZenCart documentation really needs a major overhaul. This should be considered a complete project for a future release.
--Tim

I did finally find the setting for this using Dev Kit search (in search CONSTANT definitions using ALL language files).

It is in Admin/Layout Settings.

(The Admin panels could use a serious overhaul/reorganization as well.)

senortim:

I have several times had the same question.

So why is it that the Wiki doesn't contain this essential information? I have been trying to locate an Admin setting for SHOW_FOOTER_IP without much luck. It's defined in 'tpl_footer.php' but I can't find it using the Dev Toolkit search, no definition in the Wiki and nowhere in the ZenSupport area. The forums hit it, but mostly just as quotes.

What we all need is something that defines all these constants and locates them in the standard ZenCart files:

E.g.
SHOW_FOOTER_IP - Set in Admin/Customer, this option lets you choose whether to display a customer's IP address on every page as they browse the site.

Default files where it occurs:
admin/customer.php
includes/templates/template_default/common/tpl_footer.php

The ZenCart documentation really needs a major overhaul. This should be considered a complete project for a future release.
--Tim

In the admin under configuration->layout settings, look for "Footer - Show IP Address status" near the bottom of the list.

Thanks Mary Ellen.

senortim:

The ZenCart documentation really needs a major overhaul. This should be considered a complete project for a future release.
--Tim

Does this mean you're volunteering?

Actually, I'd love to and I've thought of offering, but there are two problems. First, I'm having a baby in the next month or so. Second, I find ZenCart so confusing that I'd really need a knowledgeable guide to help me know where to start.

For example, what I really wanted at first was a sense of how all the ZenCart files go together. However, I now think that it might be more important to know where various pieces fit visually. Especially for those who want to customize ZenCart's appearance (as I do.)

And it would be useful to have some of the documentation echoed in the source files themselves -- such as showing the user what the text output of a PHP script might be within that snippet of php code (e.g., a module). This might take a lot of the mystery out of it.

Anyway, if you weren't being entirely flip, let's talk.

--Tim

senortim:

For example, what I really wanted at first was a sense of how all the ZenCart files go together.

You might find these handy:
http://www.zen-cart.com/index.php?main_page=product_contrib_info&cPath=40_54&products_id=378
http://www.zen-cart.com/index.php?main_page=product_contrib_info&cPath=40_54&products_id=298

... as well as the various tutorials in the FAQ area:
https://www.zen-cart.com/tutorials/index.php

Thanks. Those files were helpful. Fortunately (???) I've spent a lot of hours already trying to understand the baroque structure of the overrides folders and the page construction code, so they clarify things a bit for me.

Still, I don't understand what seems to me the inverted logic of the overrides system. I can see the the division of language files from other template files, since one might wish to localize for several languages. But why not have 'your_template' as a single folder at the top level with sub folders for the various goodies? And why are modules not part of templates? I'm certainly treating them that way as I customize my design, I just have to look in places that assume I have a firm grip already of ZenCart's structure (which most newbies or non-programmers will not.)

I'm not naive: I'm sure there are well-considered reasons that ZenCart is the way it is. However, it strikes me that these reasons likely have more to do with how ZenCart is programmed than with considerations for ease of use or excellence in store design in mind.

Further, it strikes me that the complexity of ZenCart is one of the reasons that custom designs are not that interesting or varied. (Obviously the three column structure is another major factor.)

Cheers,
Tim

Hey, I just thought of something that might be a useful debugging tool (perhaps for a future release of ZenCart).

If the Admin panel included a debugging flag, I could see that a template set could be created to add trace information (either visible text or rollovers or just comments that could be seen in the browser source -- or perhaps by a tool like FireBug). Maybe even with different levels of verbosity. So someone unfamiliar with ZenCart could switch templates to see where information may be coming from.

--Tim

Tim, if you research on Zen Cart you will find out how it came to be and why changes can sometimes take longer than anticipated. From DrByte (one of the CORE developers) it sounded like maybe an Invitation to work on CORE files was extended to you (I could be wrong). As they are far and few between, best decide if YOU are serious about improving any Documentation.

I agree with you on the Template situation and look forward to the day when Templates can be used that have Layouts based on CSS, Tables used where required, and Main Content allowed to show before any Sideboxes. I am patient though and in the meantime, trying to put together a few New Templates for people.

 Main Content allowed to show before any Sideboxes

This can be done with css. In the matter of fact, you can show main content before anything else (users will still see the normal layout)

Your points about structure are well taken.

Your suggestion about a designer-debug template is interesting. It has some merit; however, unless debug code were added to the template one wanted to customize, it may not be all that useful.

The most productive skill to develop design-wise is to understand how to read the generated HTML in order to build/change the appropriate CSS to make the changes you desire. You mentioned Firebug ... and that's probably your best asset when it comes to fine-tuning your templates.
A documented design guide will only do so much, depending on which template it was based on. Knowing how to use the browser source is a far more useful end result.

Nevertheless, the template-system improvements being built in v1.4 will make life much easier. There's a lot yet to be done ... there is no ETA for release.

As to documentation, a reference guide of what features can be enabled/disabled via the admin, and where those switches are located, is probably one of the quickest things to generate. A list of admin config switches is not the useful thing. A list of "possible desired template changes" and their corresponding admin-switch-location would be the target.

Going beyond that takes you into both coding and templating, which is another level altogether.

Although I think documentation is a great thing (as long as I don't have to write it), I think the suggestion below is overkill.

senortim:

What we all need is something that defines all these constants and locates them in the standard ZenCart files:

E.g.
SHOW_FOOTER_IP - Set in Admin/Customer, this option lets you choose whether to display a customer's IP address on every page as they browse the site.

Default files where it occurs:
admin/customer.php
includes/templates/template_default/common/tpl_footer.php

Most newbies won't have a clue what that means. It might useful for someone trying to write a mod for Zen Cart, but the average non-technical user probably won't care and will only add to his/her confusion and feeling of being overwhelmed.

It seems to me that some users think they need to know every last detail on how Zen Cart works before they can get anything done. That's like saying you need to understand an internal combustion engine and how it ties into all the systems in a car before you can learn to drive. :blink:

The template system isn't always obvious, but it isn't difficult either.

yellow1912:

Main Content allowed to show before any Sideboxes

> This can be done with css. In the matter of fact, you can show main content before anything else (users will still see the normal layout)

I know it can be done because that is how I code stand-alone Web pages. One can also code to use switches within CSS for turning ON/OFF Sideboxes and setting widths. But to do all that one needs fluid CSS which I don't see happening in the current Zen Cart, due to Sideboxes & Main Content being confined within a Table.

Can you provide a working example of your statement using a current version of Zen Cart?

afo:

Although I think documentation is a great thing (as long as I don't have to write it), I think the suggestion below is overkill.

Most newbies won't have a clue what that means....the average non-technical user probably won't care and will only add to his/her confusion and feeling of being overwhelmed.

It seems to me that some users think they need to know every last detail on how Zen Cart works before they can get anything done....

I certainly agree with your last comment and perceive clearly that ZenCart it intended to be easy to use and configure. However, unless one accepts one of existing templates with only minor changes to the overall look, then folks (like me) quickly descend into the complexities of the system. If only 5% of the thousands and thousands of ZenCart installations out there are attempting high levels of customization/design, then a huge number of people are quickly getting frustrated with ZenCart's quirks and idiosyncrasies.

I further agree that presenting a set of constants definitions will be confusing to newbies (who, unlike me, are probably not professional web designers with PHP and other programming experience, or familiar with other CMSs). But good documentation is tiered so that that readers are not faced with complexity at the outset.

This is related to my comment that the Admin features should be reorganized, so I'll use that as an example. I think a newbie will want to get their store going right away, so the Catalog and basic branding (logo, fonts) are what they are chiefly concerned with. So put those under a suitably named menu and provide super easy to use and understand controls. Then for the next tier of complexity, provide features that one would use to configure details of a site's look (including such things as whether quantity boxes appear). Then the next tier might be focused just on customizing and extending the site. And so on.

Now most of my comments are related to customization, but here is no different. Start with a thorough explanation of overrides and where certain features would need to be configured. Then move into how CSS can be used to reorganize features (with some discussion of how CSS and the dynamics of templates and the Admin panel are related; obviously styling a 'best sellers' DIV won't do much good if it doesn't show up on your site.) And then give people a clear guide to the logic behind the code and how they can modify templates and modules without breaking anything to do with the systems features.

This is somewhat long winded, and forgive me if documentation addressing some of these pieces is somewhere in the Wiki. But I hope that you take my point.

More than once I have been tempted to delve into the Wiki to begin this kind of reorganization. (And isn't it one of the beautiful parts of a Wiki that it could develop alongside what already exists!) Of course, I cannot log in and so there it is.

I also appreciate that a more complete documentation process is a potentially large undertaking. I have written user manuals before and there are several different levels of need for ZenCart. It would take time....

Anyway, someone was slightly challenging to me about taking on documentation duties, but I was serious about my comments. I do not know any of your timelines re v1.4 nor my own availability with my nascent child, but if I can of any help, I'd be happy to try.

--Tim

Your comments about the admin area are understood. An entire release is scheduled for an admin overhaul:
http://www.zen-cart.com/forum/forumdisplay.php?f=4