Template question for The Next Version of Zencart

I know this is the wrong place for but I cannot find the right place.

At the moment; you find a template you or your client like add all the plugin's that are required and sit back. Then a new, better template comes out upload that and you have to add all the plugin's again.

Would it be possible in the next version of Zencart to change it so that plugin's only need to be added once no matter how many templates are used?

I do not know enough of the coding for Zencart to make any suggestions on how you can do this, yet.

I think that you will have to wait for v2.0 for this to happen

I nearly said call it v2.0.0

As far as "reinstallation" to a new template, there are two ways that I typically take depending on the fileset.

1. Reinstall only the template override files from each of the plugins.
2. Using the original template override files of the original template, identify the differences in them. Evaluate the reason for those changes (error in original template, store owner's desired change, or plugin installation). Modify the equivalent template override files from the new template (location of changes may need to be different), then any files modified/present in the original override directory and not in the original template and not in the new template are copied over to the new template directory.

I have seen some buzz about the proposed template modifications though. What version? Dunno. :)

Well, it's not 2.0, but the Zen Cart 1.6.0 repository has the concept of "shared" template files. That will enable your store (and associated plugins) to have content that is *shared *between templates.

at this point, i would just be happy if products_all, products_new, products_featured, and specials all used the same template file!

I believe that is also being standardized in v1.6

You are correct. Those four use the same template in 1.6 (tpl_product_listing_standard.php).

excellent. now can we ensure that functions remain the same on the admin as well as the customer side? and classes get extended on the admin side if they need additional functionality? the duplication of code makes maintenance so much more difficult... it's very painful. i know dr byte has said that the team is working on it for v1.6. i'm just hopeful that the code consolidation is very thorough.

and i apologize as i have not downloaded 1.6 and started playing. hopefully when i get some more time and energy i will start doing that!

carlwhat:

excellent. now can we ensure that functions remain the same on the admin as well as the customer side? and classes get extended on the admin side if they need additional functionality? the duplication of code makes maintenance so much more difficult... it's very painful. i know dr byte has said that the team is working on it for v1.6. i'm just hopeful that the code consolidation is very thorough.

and i apologize as i have not downloaded 1.6 and started playing. hopefully when i get some more time and energy i will start doing that!
We've done a bunch of that, and there's still more to do. But do you want us to focus on merely changing architecture, or also adding features?

drB,
my opinion would be enhancing the architecture while adding the important features.

as you are asking my opinion, i will provide it. but please note, i'm a fan of the zen-cart project; and my comments are meant as constructive.

for me, the important features that i have had to look elsewhere (or code from scratch) include:

• adding additional product fields
• admin edit/add orders
• one page checkout
• responsive design template

i think those 4 items, and i know some, if not all of these are being incorporated into future releases, should be part of a vanilla install.

in addition, i know the current versions also has an ajax-add-to-cart; but i had already implemented an add-on to make use of that feature. I am a huge fan of more ajax calls when possible. unfortunately a lot of ajax add-ons are buggy, and my experience getting them to work requires lots of work on my part.

with regards to adding more features, the question becomes when does it become bloatware? how many excel/open office users use more than 15% of the functions available? i can only assume that you have more insight into the typical zen-cart user, and know what features they are requested, but the ones above would be the ones i would focus on.

as far as the architecture, do you want to go more like shopify in trying to make it as idiot-proof as possible, or more like magento where they try and isolate all of the enhancements from the core; to the point that their whole XML architecture gets to be ridiculously confusing for a developer or someone implementing a magento site?

frankly, i'm amazed when i look at the zen-cart forums, and see store-owners with little to no coding experience implementing a zc site. store owners with no idea what css is, forget about jquery, php, responsive design or html validation. now if they can get a ZC install up and running without professional help, with a modern look and feel, and it serves their business well, awesome! in my experience, rarely does anything work as required out of the box; but it's to the ZC team that some people can make that happen.

but for someone like me, i find it incredibly frustrating at times, the work required to do something. for example, i recently upgraded a client to 1.5.4. they have a ton of customizations that were done over the years, that now had to ported over to the new version. i tried to isolate as much of that customization; but it becomes impossible for any number of reasons. no big deal i suppose. but i then have to add some new menu items onto the admin side. does it really have to be this difficult:

https://www.zen-cart.com/content.php?327-Adding-a-menu-item-to-the-v1-5-0-admin

different files for defining the FILENAME and the BOX_ constant? requiring a constant at all? and if the constant is defined on the customer side, that is not good enough? or perhaps i defined it in the wrong spot? and then deleting the init_new_tool.php file or have extra dB hits if it is still there. and if i really want to be persnickety, a script called init_* that is not in the init_includes directory?

i suppose the development team has their reasons why, but requiring this level of complexity totally perplexes me.

please note that I am not looking for any justification here. i'm only providing my opinion.

on a last note, between live sites, development sites, and finding the right development environment for myself, i have constructed and destructed any number of ZC installs. yesterday, i decided to do a clean/vanilla install of V1.5.5 to troubleshoot another problem i was having. i have to say the install process went surprisingly easy and quick. i think its a big improvement over previous versions. and i'm still looking forward to future enhancements/releases...

best.

Thanks @carlwhat. I was most looking for the honest feedback. Your candid answer is appreciated.
We are indeed endeavouring to make each version better and better, minimizing bloat (in all the angles you can think of) and at the same time making expandability easier.
We love the fact that complete noobs can indeed get a store running with minimal challenge, in just a few minutes.
We want to improve the same for upgraders too.
Lots has been done to address the most common feature improvement requests in the v155 base. Lots more planned for subsequent releases.
Your ongoing support of the community and use of the software is much appreciated!

carlwhat:

...
https://www.zen-cart.com/content.php?327-Adding-a-menu-item-to-the-v1-5-0-admin

different files for defining the FILENAME and the BOX_ constant? requiring a constant at all? and if the constant is defined on the customer side, that is not good enough? or perhaps i defined it in the wrong spot? and then deleting the init_new_tool.php file or have extra dB hits if it is still there. and if i really want to be persnickety, a script called init_* that is not in the init_includes directory?

i suppose the development team has their reasons why, but requiring this level of complexity totally perplexes me.
...
The reason for the different files for the FILENAME and the BOX_ constants is due to the use of those constants. The FILENAME constant applies to *all *languages, while the BOX_ constant (which is displayed on the admin menu) is language-specific. That's why (for plugin authors) it's suggested to separate the FILENAME (and database TABLE_ constants) from the language ones.

When the constants are also used/supplied on the store-front, you can code the admin-console version to simply pull that store-front file in as part if that admin processing. For Zen Cart v1.5.4 and later, this concept is used by /YOUR_ADMIN/includes/extra_configures/use_catalog_time_zone.php, for example.

Certainly, if you're developing a customization for a single-language store you *could *lump the FILENAME_, TABLE_ and BOX_ constants all in a file in the /extra_datafiles folder, recognizing that that might be a source of confusion if another person is called in to help with some troubleshooting on that store.