Is it okay to add fields to Standard Template or add Base Templates to it?
I would like to add a field to all of my templates. The easiest approach appears to be to either
- Add the field directly to Standard Templates (
/sitecore/templates/System/Templates/Standard template
) or - Create a new template and add it to the Base Template field on Standard Template (inherit my custom template)
Similarly, if all media items require a particular field, can I modify a low-level media template in a similar manner?
Example:
- "Media Classification" - (
/sitecore/templates/System/Analytics/Marketing Taxonomy/Base/Classification/Media classification
) - "File" - (
/sitecore/templates/System/Media/Versioned/File
)
Is it reasonable to modify these Base Templates in certain scenarios?
templates inheritance
add a comment |
I would like to add a field to all of my templates. The easiest approach appears to be to either
- Add the field directly to Standard Templates (
/sitecore/templates/System/Templates/Standard template
) or - Create a new template and add it to the Base Template field on Standard Template (inherit my custom template)
Similarly, if all media items require a particular field, can I modify a low-level media template in a similar manner?
Example:
- "Media Classification" - (
/sitecore/templates/System/Analytics/Marketing Taxonomy/Base/Classification/Media classification
) - "File" - (
/sitecore/templates/System/Media/Versioned/File
)
Is it reasonable to modify these Base Templates in certain scenarios?
templates inheritance
add a comment |
I would like to add a field to all of my templates. The easiest approach appears to be to either
- Add the field directly to Standard Templates (
/sitecore/templates/System/Templates/Standard template
) or - Create a new template and add it to the Base Template field on Standard Template (inherit my custom template)
Similarly, if all media items require a particular field, can I modify a low-level media template in a similar manner?
Example:
- "Media Classification" - (
/sitecore/templates/System/Analytics/Marketing Taxonomy/Base/Classification/Media classification
) - "File" - (
/sitecore/templates/System/Media/Versioned/File
)
Is it reasonable to modify these Base Templates in certain scenarios?
templates inheritance
I would like to add a field to all of my templates. The easiest approach appears to be to either
- Add the field directly to Standard Templates (
/sitecore/templates/System/Templates/Standard template
) or - Create a new template and add it to the Base Template field on Standard Template (inherit my custom template)
Similarly, if all media items require a particular field, can I modify a low-level media template in a similar manner?
Example:
- "Media Classification" - (
/sitecore/templates/System/Analytics/Marketing Taxonomy/Base/Classification/Media classification
) - "File" - (
/sitecore/templates/System/Media/Versioned/File
)
Is it reasonable to modify these Base Templates in certain scenarios?
templates inheritance
templates inheritance
asked Jan 29 at 15:46
jrapjrap
2,6421630
2,6421630
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
Whenever I do this, I create a new template that I inherit. If wanted to add a new field called widget
, I would create a new _template called _widgetdata
(notice the _ to dictate the fact that this should only be inherited). And in _widgetdata
add my widget field.
Now go to /sitecore/templates/System/Templates/Standard template
and inherit the _widgetdata
template. This will help with upgrades because it will be easy to put back with TDS or a script. Rather than having to keep track on field on the Standard template.
2
+1 for the mention of TDS/Unicorn to make sure the change is not lost after an upgrade
– jrap
Jan 29 at 18:28
add a comment |
From my point of view, the answer is yes, you can update the Sitecore Base template or add the template as base.
When upgrading the Sitecore instance, this may impact those templates. You may need to re-add those base templates to the standard field template. You'll need to keep track of the items so that if you are upgrading the Sitecore instance, you'll need to update the template.
However, when performing a Sitecore upgrade using the .update
packages, if the standard field template is not updated, it won't remove the inheritance that you've added.
Moreover, it depends on the requirements at hand. For example, if you need to add new fields to the Media item, you'll need to make the default Sitecore Media Template item inherit the fields. Preference here is to create a custom template and then use inheritance.
add a comment |
My humble opinion is that it's not acceptable to modify the ootb item by adding templates via inheritance. The reason for this is purely because you then start introducing parts of the ootb Sitecore tree in to your solution. With that in mind you might as well have other parts of Sitecore imbedded within the solution such as the Sitecore Web root. If 1 item doesn't break your coding standards then neither should 10, or 100, or, heck, just serialise the entire Sitecore database and add it to your solution.
While you correctly identify that it is a slippery slope, there are valid cases for needing to do this. One example, for instance, is adding the option for content editors to add the X-Robots-Tag header to media items selectively, which would require modifying the File template. If well documented and selective, I think this is a completely valid case, and does not amount to serializing the entire Sitecore database.
– Matthew FitzGerald-Chamberlain
Jan 29 at 23:40
add a comment |
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "664"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsitecore.stackexchange.com%2fquestions%2f16306%2fis-it-okay-to-add-fields-to-standard-template-or-add-base-templates-to-it%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Whenever I do this, I create a new template that I inherit. If wanted to add a new field called widget
, I would create a new _template called _widgetdata
(notice the _ to dictate the fact that this should only be inherited). And in _widgetdata
add my widget field.
Now go to /sitecore/templates/System/Templates/Standard template
and inherit the _widgetdata
template. This will help with upgrades because it will be easy to put back with TDS or a script. Rather than having to keep track on field on the Standard template.
2
+1 for the mention of TDS/Unicorn to make sure the change is not lost after an upgrade
– jrap
Jan 29 at 18:28
add a comment |
Whenever I do this, I create a new template that I inherit. If wanted to add a new field called widget
, I would create a new _template called _widgetdata
(notice the _ to dictate the fact that this should only be inherited). And in _widgetdata
add my widget field.
Now go to /sitecore/templates/System/Templates/Standard template
and inherit the _widgetdata
template. This will help with upgrades because it will be easy to put back with TDS or a script. Rather than having to keep track on field on the Standard template.
2
+1 for the mention of TDS/Unicorn to make sure the change is not lost after an upgrade
– jrap
Jan 29 at 18:28
add a comment |
Whenever I do this, I create a new template that I inherit. If wanted to add a new field called widget
, I would create a new _template called _widgetdata
(notice the _ to dictate the fact that this should only be inherited). And in _widgetdata
add my widget field.
Now go to /sitecore/templates/System/Templates/Standard template
and inherit the _widgetdata
template. This will help with upgrades because it will be easy to put back with TDS or a script. Rather than having to keep track on field on the Standard template.
Whenever I do this, I create a new template that I inherit. If wanted to add a new field called widget
, I would create a new _template called _widgetdata
(notice the _ to dictate the fact that this should only be inherited). And in _widgetdata
add my widget field.
Now go to /sitecore/templates/System/Templates/Standard template
and inherit the _widgetdata
template. This will help with upgrades because it will be easy to put back with TDS or a script. Rather than having to keep track on field on the Standard template.
answered Jan 29 at 17:19
Chris AuerChris Auer
8,61611146
8,61611146
2
+1 for the mention of TDS/Unicorn to make sure the change is not lost after an upgrade
– jrap
Jan 29 at 18:28
add a comment |
2
+1 for the mention of TDS/Unicorn to make sure the change is not lost after an upgrade
– jrap
Jan 29 at 18:28
2
2
+1 for the mention of TDS/Unicorn to make sure the change is not lost after an upgrade
– jrap
Jan 29 at 18:28
+1 for the mention of TDS/Unicorn to make sure the change is not lost after an upgrade
– jrap
Jan 29 at 18:28
add a comment |
From my point of view, the answer is yes, you can update the Sitecore Base template or add the template as base.
When upgrading the Sitecore instance, this may impact those templates. You may need to re-add those base templates to the standard field template. You'll need to keep track of the items so that if you are upgrading the Sitecore instance, you'll need to update the template.
However, when performing a Sitecore upgrade using the .update
packages, if the standard field template is not updated, it won't remove the inheritance that you've added.
Moreover, it depends on the requirements at hand. For example, if you need to add new fields to the Media item, you'll need to make the default Sitecore Media Template item inherit the fields. Preference here is to create a custom template and then use inheritance.
add a comment |
From my point of view, the answer is yes, you can update the Sitecore Base template or add the template as base.
When upgrading the Sitecore instance, this may impact those templates. You may need to re-add those base templates to the standard field template. You'll need to keep track of the items so that if you are upgrading the Sitecore instance, you'll need to update the template.
However, when performing a Sitecore upgrade using the .update
packages, if the standard field template is not updated, it won't remove the inheritance that you've added.
Moreover, it depends on the requirements at hand. For example, if you need to add new fields to the Media item, you'll need to make the default Sitecore Media Template item inherit the fields. Preference here is to create a custom template and then use inheritance.
add a comment |
From my point of view, the answer is yes, you can update the Sitecore Base template or add the template as base.
When upgrading the Sitecore instance, this may impact those templates. You may need to re-add those base templates to the standard field template. You'll need to keep track of the items so that if you are upgrading the Sitecore instance, you'll need to update the template.
However, when performing a Sitecore upgrade using the .update
packages, if the standard field template is not updated, it won't remove the inheritance that you've added.
Moreover, it depends on the requirements at hand. For example, if you need to add new fields to the Media item, you'll need to make the default Sitecore Media Template item inherit the fields. Preference here is to create a custom template and then use inheritance.
From my point of view, the answer is yes, you can update the Sitecore Base template or add the template as base.
When upgrading the Sitecore instance, this may impact those templates. You may need to re-add those base templates to the standard field template. You'll need to keep track of the items so that if you are upgrading the Sitecore instance, you'll need to update the template.
However, when performing a Sitecore upgrade using the .update
packages, if the standard field template is not updated, it won't remove the inheritance that you've added.
Moreover, it depends on the requirements at hand. For example, if you need to add new fields to the Media item, you'll need to make the default Sitecore Media Template item inherit the fields. Preference here is to create a custom template and then use inheritance.
edited Jan 29 at 16:26
answered Jan 29 at 16:20
Hishaam NamooyaHishaam Namooya
6,6491627
6,6491627
add a comment |
add a comment |
My humble opinion is that it's not acceptable to modify the ootb item by adding templates via inheritance. The reason for this is purely because you then start introducing parts of the ootb Sitecore tree in to your solution. With that in mind you might as well have other parts of Sitecore imbedded within the solution such as the Sitecore Web root. If 1 item doesn't break your coding standards then neither should 10, or 100, or, heck, just serialise the entire Sitecore database and add it to your solution.
While you correctly identify that it is a slippery slope, there are valid cases for needing to do this. One example, for instance, is adding the option for content editors to add the X-Robots-Tag header to media items selectively, which would require modifying the File template. If well documented and selective, I think this is a completely valid case, and does not amount to serializing the entire Sitecore database.
– Matthew FitzGerald-Chamberlain
Jan 29 at 23:40
add a comment |
My humble opinion is that it's not acceptable to modify the ootb item by adding templates via inheritance. The reason for this is purely because you then start introducing parts of the ootb Sitecore tree in to your solution. With that in mind you might as well have other parts of Sitecore imbedded within the solution such as the Sitecore Web root. If 1 item doesn't break your coding standards then neither should 10, or 100, or, heck, just serialise the entire Sitecore database and add it to your solution.
While you correctly identify that it is a slippery slope, there are valid cases for needing to do this. One example, for instance, is adding the option for content editors to add the X-Robots-Tag header to media items selectively, which would require modifying the File template. If well documented and selective, I think this is a completely valid case, and does not amount to serializing the entire Sitecore database.
– Matthew FitzGerald-Chamberlain
Jan 29 at 23:40
add a comment |
My humble opinion is that it's not acceptable to modify the ootb item by adding templates via inheritance. The reason for this is purely because you then start introducing parts of the ootb Sitecore tree in to your solution. With that in mind you might as well have other parts of Sitecore imbedded within the solution such as the Sitecore Web root. If 1 item doesn't break your coding standards then neither should 10, or 100, or, heck, just serialise the entire Sitecore database and add it to your solution.
My humble opinion is that it's not acceptable to modify the ootb item by adding templates via inheritance. The reason for this is purely because you then start introducing parts of the ootb Sitecore tree in to your solution. With that in mind you might as well have other parts of Sitecore imbedded within the solution such as the Sitecore Web root. If 1 item doesn't break your coding standards then neither should 10, or 100, or, heck, just serialise the entire Sitecore database and add it to your solution.
answered Jan 29 at 17:50
Ashar ShahAshar Shah
1
1
While you correctly identify that it is a slippery slope, there are valid cases for needing to do this. One example, for instance, is adding the option for content editors to add the X-Robots-Tag header to media items selectively, which would require modifying the File template. If well documented and selective, I think this is a completely valid case, and does not amount to serializing the entire Sitecore database.
– Matthew FitzGerald-Chamberlain
Jan 29 at 23:40
add a comment |
While you correctly identify that it is a slippery slope, there are valid cases for needing to do this. One example, for instance, is adding the option for content editors to add the X-Robots-Tag header to media items selectively, which would require modifying the File template. If well documented and selective, I think this is a completely valid case, and does not amount to serializing the entire Sitecore database.
– Matthew FitzGerald-Chamberlain
Jan 29 at 23:40
While you correctly identify that it is a slippery slope, there are valid cases for needing to do this. One example, for instance, is adding the option for content editors to add the X-Robots-Tag header to media items selectively, which would require modifying the File template. If well documented and selective, I think this is a completely valid case, and does not amount to serializing the entire Sitecore database.
– Matthew FitzGerald-Chamberlain
Jan 29 at 23:40
While you correctly identify that it is a slippery slope, there are valid cases for needing to do this. One example, for instance, is adding the option for content editors to add the X-Robots-Tag header to media items selectively, which would require modifying the File template. If well documented and selective, I think this is a completely valid case, and does not amount to serializing the entire Sitecore database.
– Matthew FitzGerald-Chamberlain
Jan 29 at 23:40
add a comment |
Thanks for contributing an answer to Sitecore Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsitecore.stackexchange.com%2fquestions%2f16306%2fis-it-okay-to-add-fields-to-standard-template-or-add-base-templates-to-it%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown