Should a Plugin EVER use template_default?

[dbltoe]

Strictly a discussion of something I feel may be confusing to a newbie. They are addressed briefly in items 4 and 5 of Documentation Requirements in the Rules for Plugin/Addon Contribution Submission.

First of all what constitutes YOUR_TEMPLATE. Several definitions make it unclear and sometimes infer that it is something OTHER than the template you currently have selected in the ADMIN >> Tools >> Template Selection. In other words, YOUR_TEMPLATE might be Classic Contemporary Green, Responsive Classic Template, or some other template. Indicating that files should be placed anywhere other than YOUR_TEMPLATE in a mod or addon, IMHO, can create a load of problems for the newbie.

For example, a mod might want the installer to place a copy of the file in template_default and merge the file with any other copy IF it is in YOUR_TEMPLATE. I read this as put tpl_somethingnew.php in the template_default directory and (if the tpl_somethingnew.php exists in YOUR_TEMPLATE) make sure any changes in template/YOUR_TEMPLATE/templates/tpl_somethingnew.php be merged into templates/template_default/templates/tpl_somethingnew.php. Isn't this exactly backwards from what we want? This method will lose all changes upon cart upgrade. The exact opposite of what we want to happen on upgrade.

Likewise, should there really be a need to put the same file in YOUR_TEMPLATE and template_default? To me, this is unnecessary even if one is using Classic Contemporary Green. Is not template_default only "called" if the file being used is NOT in YOUR_TEMPLATE?

It appears that, until 1.6.0, any upgrade will continue to replace Classic, Default, and Responsive thereby losing any changes done for a mod.

We recommend that our customers, whether starting new or upgrading, use lat9's clone a template immediately after installing ZC. Of course, we recommend cloning the responsive template for its responsive qualities and recommend a naming convention based on their store/site. If the customer comes with a template in hand, we make sure the template is compatible with ZC to avoid the

The immediate benefit is that, when a mistake occurs, the customer/storeowner has something to refer back to and compare. <off-topic>Clone a template should be added to core and recommended for use BEFORE making changes to a template.</off-topic>

I suggest that we standardize all template mods to refer to YOUR_TEMPLATE exclusively as we do with YOUR_ADMIN. A notice might be included with each mod's readme something like:

In this mod, you will see references to files and/or folders as YOUR_TEMPLATE. YOUR_TEMPLATE is that template that is currently controlling the "look" and layout of your site/store. If you do not know which template that is, you can find out by clicking on the Template Selection of the Tools Menu in the admin menu of your store/site. If YOUR_TEMPLATE is one of those shipped with the Zen Cart install, it is recommended that you clone the template prior to installing this mod. Installing this mod's YOUR_TEMPLATE files/folders to templates shipped with Zen Cart can or will cause them to be lost during a future upgrade of Zen Cart.


Flame on.

[DrByte]

This method will lose all changes upon cart upgrade.

If one "blindly" replaces all core files with new core files, without reviewing all alterations previously made to those files, then yes overwriting the files will "lose all changes upon cart upgrade". But, I've always disliked when anyone says "you'll lose everything upon upgrade", as it is unhelpful in the ongoing attempts at reducing the perception that "upgrades are daunting".

Likewise, should there really be a need to put the same file in YOUR_TEMPLATE and template_default? To me, this is unnecessary

Agreed. There's no need to put a plugin's additional files into template_default. It's simpler to maintain and manage upgrades when those files are only put into the affected template's folders.
That said, I can appreciate that if a store has a dozen templates which they regularly switch among for seasonal differences, then it can be handy to use template_default as a master in this way .... but this is a very advanced sort of configuration that brings with it its own other upgrade challenges, very much out of the scope of this discussion IMO.

[swguy]

That said, I can appreciate that if a store has a dozen templates which they regularly switch among for seasonal differences, then it can be handy to use template_default as a master in this way ....

1.6.0 will have a nice feature that allows you to add in changes like this which are shared between all templates without modifying template_default. :)

[lat9]

Likewise, should there really be a need to put the same file in YOUR_TEMPLATE and template_default? To me, this is unnecessary

Agreed. There's no need to put a plugin's additional files into template_default. It's simpler to maintain and manage upgrades when those files are only put into the affected template's folders.
That said, I can appreciate that if a store has a dozen templates which they regularly switch among for seasonal differences, then it can be handy to use template_default as a master in this way .... but this is a very advanced sort of configuration that brings with it its own other upgrade challenges, very much out of the scope of this discussion IMO.

I humbly disagree with the highlighted statement, based on experience with One Page Checkout. If that plugin's added files weren't placed in template_default, with instructions to installing stores to make a copy in their template, I'd have lost a significant piece of debug information (i.e. changing back to the "classic" template somehow caused the plugin to work).

[swguy]

Hallmark Moment (tm): Maybe you're both right. After all, there's a pretty big difference between a workflow that helps a developer and an install process that's storeowner friendly.

[mc12345678]

For example, a mod might want the installer to place a copy of the file in template_default and merge the file with any other copy IF it is in YOUR_TEMPLATE. I read this as put tpl_somethingnew.php in the template_default directory and (if the tpl_somethingnew.php exists in YOUR_TEMPLATE) make sure any changes in template/YOUR_TEMPLATE/templates/tpl_somethingnew.php be merged into templates/template_default/templates/tpl_somethingnew.php. Isn't this exactly backwards from what we want? This method will lose all changes upon cart upgrade. The exact opposite of what we want to happen on upgrade.

In reference to the bolded text only above, as there are multiple published ways to perform an upgrade (none specifically wrong, just done differently) such as replacing files that exist with consideration of why differences exist, removing files that no longer are applicable or another recommended method of starting with a fresh install and then adding to it or modifying it with whatever is needed to obtain the desired operation.

Even the clone a template plugin is designed with the first method of update in mind to support an upgrade or as able to support a fresh start off of a brand new install of either ZC alone or ZC with a new template. "Cloning" the fileset of an existing install to a new store is not inherently (out-of-the-box) made available. Yes, it can be modified to support that, but in its current state it supports the first method of update described above better than the second that is suggested in the this upgrade by rebuild FAQ.

[DrByte]

Likewise, should there really be a need to put the same file in YOUR_TEMPLATE and template_default? To me, this is unnecessary

Agreed. There's no need to put a plugin's additional files into template_default. It's simpler to maintain and manage upgrades when those files are only put into the affected template's folders.
That said, I can appreciate that if a store has a dozen templates which they regularly switch among for seasonal differences, then it can be handy to use template_default as a master in this way .... but this is a very advanced sort of configuration that brings with it its own other upgrade challenges, very much out of the scope of this discussion IMO.

I humbly disagree with the highlighted statement, based on experience with One Page Checkout. If that plugin's added files weren't placed in template_default, with instructions to installing stores to make a copy in their template, I'd have lost a significant piece of debug information (i.e. changing back to the "classic" template somehow caused the plugin to work).

Fair. And basically what you're doing there is what I talked about in using template_default as a master even for non-original-core files.

[Website Rob]

I would weigh in on the side of NOT placing customized files in the template_default dir.

Reason being is that template_default are Core Files and not touching Core Files whenever and wherever possible is a good thing.

Even though I have not tested 1.6 much, I can only presume the need for not having to check template_default for customized files will cut down on coding and processing time.

[dbltoe]

My reasoning behind the "This method will lose all changes upon cart upgrade." is that they just won't be looked for by the one upgrading. We stress to use the override system which, in itself takes the upgrader away from classic, template_default, and even responsive_classic if they were currently using a clone of one of the others.
Also, I recently installed a mod that had template_default and YOUR_TEMPLATE files with several of the template_default being new files. Not overwrites of core, but new files.
I can see the point in having something to "fall back on for testing" but can't wrap my head around putting a new file anywhere but YOUR_TEMPLATE.

[lat9]

My reasoning behind the "This method will lose all changes upon cart upgrade." is that they just won't be looked for by the one upgrading. We stress to use the override system which, in itself takes the upgrader away from classic, template_default, and even responsive_classic if they were currently using a clone of one of the others.
Also, I recently installed a mod that had template_default and YOUR_TEMPLATE files with several of the template_default being new files. Not overwrites of core, but new files.
I can see the point in having something to "fall back on for testing" but can't wrap my head around putting a new file anywhere but YOUR_TEMPLATE.

Just like the template_default files provide a fall-back for the Zen Cart base files, if a plugin introduces brand-new template files (take One Page Checkout for example), it can be beneficial to place those new files also into template_default.

That provides a base installation and allows for template-overrides on those files, so a store can make their own modifications to a file and still have the as-shipped version for reference.