I am new to Sitecore and have a basic question around this. When I create a Sitecore item a Unique ID is created for this item. Is it ok if I use this item ID in the code to hold a reference to it? Does this change from deployment to deployment?
If you actually "deploy" your items -using a package or serialization (tool)-, the ID will stay the same and you can keep a reference to it in your code.
It is a good coding practice however not to spread hard-coded guids (as that is what the ID actually is wrapping) around all over your code. So either bundle them somewhere in a piece of code that can easily be deployed without side-effects or put them in a configuration file (but again, bundle them and don't mix with other stuff).
If for some reason the item would be gone some day and you need to re-create it (meaning: the id is changed) or you just need it to point to a new one, you will be grateful that you did keep it somewhere separated ;)
This is Sitecore behaviour to have Sitecore ID like a GUID. It is a very good aproach. The ID of an item can be also use in your C# code
The ID class in Sitecore is used to identify all types of item in Sitecore i.e. content items, templates, media items etc. It is a wrapper around .NET's own System.Guid struct and has a property called Guid which returns a System.Guid. Internally Sitecore stores IDs in it's SQL Server database using the uniqueidentifier type.
For exemple a template is also an item and it has a unique ID. If it wasn't the same ID between environments you need to modify your code between environments.
Sitecore ItemID always remain unique. So If you publish the content from your CM server to CD server, Item ID will not change. You can use ItemID as this ensure even if you change the name, you still reference to right Sitecore Content Item.
It is recommended to use some kind of class and put the item id there and reference from there so that in future, if you ever need to change then you change it in one place.
Using directly GUID or any number value for that matter are kind of magic values and is always prone to bugs.
A quick answer is yes, an ID does not change during deployments, so you can hold a reference in your code.
Sitecore Item Id will not change from deployment to deployment, You can use this ID in your code like:
Creating a class holding IDs
Or maybe a configuration file
Related
I am Using Sitecore 6.6
I believe item:setdefaultworkflow and item:resetdefaultworkflow commands are used to reset the workflow fields on an Item with values set on Standard values.
If not please correct me.
Here is the Path in Core:
/sitecore/content/Applications/Content Editor/Ribbons/Chunks/Workflow/Set Default Workflow
commands are not shown on the Ribbon. How do I use these commands? what is their purpose. Any Help is greatly appreciated.
I am aware of Version >> Fields(Reset)>> then choose the fields to reset with multiple clicks.
I am trying to use these commands if they solve my purpose to reset the Workflow Fields to standard values with a command on Review Tab >> Workflow section with one Click.
As far as I'm aware, these buttons are only visible on __Standard Values items. They are used to assign the workflow that will be used for new versions of that template going forward, or to clear the workflow that has been set (note that items which are already part way through a workflow will still need to finish it before they are no longer associated with a workflow).
The idea is that you assign the workflow to the standard values of templates (or base templates) in your solution, and those settings then get carried through to your content items.
Although you are able to, I'd advise against fiddling with the workflow fields on individual items before you fully understand the purpose of the fields.
For more information, I'd suggest looking at the Sitecore workflow reference document: https://sdn.sitecore.net/upload/sitecore6/60/workflow_reference_sc60orlater-a4.pdf
We are using Sitecore 7.2 with multi-site implementation. The actual data is shared between multisite, hence it's been stored in common Global Item folder.
We are facing a problem generating aunique ID on URL. I had a good search but could not find any solution except to use Sitecore Item ID.
This is what we want:
domain/players/player_id
e.g. domain/players/1234
where 1234 is uniquely generated ID.
Could someone please suggest if this is possible?
Every page that is managed in Sitecore is a Sitecore Item. As such, you should be able to just navigate to the name of the player item. If you were trying to say in your post that player items are stored in globals and not as pages, then you are left with the following options:
Query String: domain/players/player?playerId={ID}
If this is the route that you choose to take then I would suggest using the player item's Sitecore ID for the value of the query string parameter.
If you have other IDs then put the specified ID there, however it would be easiest with Sitecore IDs
What you would then do is get the item with the ID specified in the query string parameter (or get the item with the player ID specified in the query string parameter, depending on which route you take) and display the data for that player on the page
Sitecore.Context.Database.GetItem(Request.QueryString["playerId"])
playerItems.FirstOrDefault(playerItem => playerItem["Player ID"] == Request.QueryString["playerId"])
Note that this assumes that the Player ID is a field, not the Sitecore ID
If it is the Sitecore ID then change the lambda to use playerItem.ID == new ID(Request.QueryString["playerId"]
Regardless of which one you use, I suggest adding null checks to the QueryString getter
Sublayout Parameters
If you use this method, the query string will not change and people will not be able to get to the page from the direct URL
The process is the same as for query strings, except that you are using Sublayout parameters instead
Note that you must set these in a parent sublayout or in Sitecore (which means that you have a separate page for each player - i.e. this would be a bad solution)
Virtual Items
This is really what I think you are looking for
This can be a lot of work if you do it from scratch, or you can use the Wildcard Module
If you do it from scratch, you will need a custom pipeline and/or processor for handling the requests
Good suggestions from Zachary. I will add a couple more:
1) IIS Rewrite Module. If what you are really after is having external URLs look like /domain/players/1234, you could easily accomplish this by forwarding these requests to something like Zachary's option #1. The client sees /domain/players/1234, but it's really handled by a single Sitecore item at /domain/player/player.aspx?playerid=1234. Client doesn't have to know that.
2) Custom ItemResolver pipeline handler. Custom Pipelines may be a bit intimidating at first, but they are actually pretty easy to implement and highly useful. Would be pretty straightforward to add a new one which checked for "players/1234" and set the ContextItem to your player handling page and drop the ID into a session variable or some context variable.
Quite new to Sitecore and would like to understand the best way to access sitecore items. I've seen couple of ways:
Create Page ID field and get all items for given template and folder. Then do linq query on page ID.
Store all Page ID (Sitecore Item ID) on Constants file. Use this to query Sitecore using GetItem(itemID) API.
Could someone please suggest what's the best practice. Either way, I can see that there will be huge Constants file containing either custom Page ID or Sitecore Item ID.
My worry is do we really need to manage this Constants file or is there an elegant way to query CMS contents for given Page.
Thanks.
Approach 1 seems a bit odd. I don't really see why you would get a collection of items first when you already have the ID, but maybe I've misunderstood what you're saying.
I think a combination of 2 things you mention is best.
Constants classes are good for "landmark" items that will always definitely be there, so its fine for the GUID to be in code.
Some of these landmark items can be "configuraton items" that have fields containing the IDs of other items (These fields might have names like "Templates allowed in search"). This approach allows some flexibility for change by Sitecore users as the site evolves.
If you're concerned about the management of a constants file, I have to wonder how many items you need to access by ID. Sitecore items have properties like Parent and Children. You can also find items by template type etc.
This approach works well for me. I certainly don't think there is a more elegant way of getting strongly typed references to Sitecore items.
Personally, I prefer not to use constants files. What happens if your client or one of your developers deletes one of those items and creates a new one? One of the fundamental principles of Sitecore is that items can be added and removed by users who are not necessarily "technical" personnel.
Sitecore provides "Insert Options" so that you can specify what types of items can be added to each folder, and also grants the ability to protect certain items from deletion, via Roles and User Permissions. What does this mean conceptually? It means that Sitecore is set up such that the system architects/developers can create a structure that is not to be violated, while the content editors can add or remove content within that structure. In other words, Sitecore is designed to provide a framework in which the items can change but the location of each type of item is pre-determined.
As such, I suggest that you use the Custom Item Generator module available in the Sitecore Marketplace (free). CIG generates C# class representations (models) of your templates, and makes all fields into properties (I don't want to get too off-topic, but this is an awesome feature of CIG, especially when working with newer developers). You can add your own methods to your CIG classes for getting children of a particular type. For example, on a site in which the Profile Page is a direct child of the Homepage the following method could be added to the CIG HomepageItem.instance.cs file's HomepageItem partial class:
...
public partial class HomepageItem
{
public ProfilePageItem GetProfilePage()
{
//note that .IsOfType(...) is pseudo-code and not a real method, but I do
// suggest that you define an extension for it
return InnerItem.Children.FirstOrDefault(i => i.IsOfType(ProfilePageItem.TemplateId));
}
}
Be sure that you are assigning Insert Options to restrict the types of items that can be added as children to each item you make (add them on the Standard Values and not on the individual content items). I also suggest that you make a separate Template that inherits from Common/Folder for every folder that you use in the content tree. This way you can use CIG for your entire structure, via:
...in your Globals Item's CIG class...
public partial class GlobalsItem
{
public SlidesFolderItem GetSlidesFolder()
{
return InnerItem.Children.FirstOrDefault(i => i.IsOfType(SlidesFolderItem.TemplateId));
}
}
...in your Slides Folder Item's CIG class...
public partial class SlidesFolderItem
{
public IEnumerable<SlideItem> GetSlides()
{
return InnerItem.Children.Where(i => i.IsOfType(SlideItem.TemplateId));
}
}
and then you can get your Slide items via:
...
var slidesFolder = globals.GetSlidesFolder();
var slides = slidesFolder != null ? slidesFolder.GetSlides() : null;
Remember that CIG, Insert Options, and templates for each type of folder will enable you to create an iron-clad structure for your site that will not break if content editors make unexpected changes like replacing items.
Let me know if you have any questions on this. Good luck, and Happy Coding! :)
we faced very specific scenario in our Sitecore enviroment. In our Sitecore we have a item, lets call it "Promotion". Promotion was using "End date" field that was shared.
On our dev instance we "unshared" the field. Which naturally triggers the background process that changes the items to use field in unshared mode.
Similar process is described here: http://sitecoreblog.alexshyba.com/2011/10/changing-field-sharing-settings-in.html
So then we packaged and installed change of "unsharing field" on production "master" database. As I assume during installation the background process of "updating the items" has not been triggered. Which now behaves in the way, that "unshared" field on our production master database cannot be saved. Cahnges of value after clicking save are "vanishing". I am sure they are now being saved in some language agnostic mode.
Of course simple fix for that is to "share" it back and "unshare" it again. However when we tried to do this experiment on copy of our enviroment and we noticed all the values were lost. As the items from mentioned template are heavily used, we cannot really afford loosing those values.
Any ideas?
I would go "database digging". Sitecore stores these field values in their respective databases inside the "SharedFields", "VersionedFields" and "UnversionedFields" tables.
Assuming you shut off your Sitecore instances (this is important), you should be able to SELECT the data out of the wrong table, and INSERT it into the correct one.
(you need to look for items where FieldId matches the field you are having trouble with)
From what you've described, I don't believe Sitecore has removed any data on your production environment (yet).
So the solution we came up to, was to use Sitecore Rocks tool. We exported all the Items containing the fields before changing the field to "Share". The query was more or less like that:
SELECT ##ID, ##Start Date#, ##End Date# FROM //*[##templateid='{993DC54F-6724-46C3-B8D2-3EE13F15366A}']
It gave us proper values at that point, even though to items were pointing to the SharedFields table. We just simply converted the result of this query (around 9000 rows) in Excel to Sitecore Rocks update query -
UPDATE SET ##Start Date#='20120531T000000',##End Date#='20120614T000000' FROM //* [##ID='{E3FD9819-3DBD-4FAA-8DEF-FEF2A6272723}'];
After prepared this migrations script, we shared the appropriate field and apply the script of 9000 updates queries through Sitecore Rocks. We need to to exactly the same on Live database. Everything went pretty smooth.
The same approach could be easily done with the database I believe, however this solution was better for us, because of non-technical reasons (security policies etc.). Anyway Sitecore Rocks rocks!
I have this content tree:
SiteA
- Home
- Articles
SiteB
- Home
- News
Repository
- article1
- article2
- article3
- ...
- article1000
Is there a way I can pull any article from the Repository Item and display it dynamically on the SiteA/Article Item? Same I would do with SiteB/News.
Additional Question:
Is it possible to inherit the layout of each article from the parent Item Repository? The articles will be added via migration(which I would be working on next) it would take too much time reassigning layouts once the items has been migrated.
Yes, there is. There's a couple different things you can do, depending on your requirements.
For instance, you can have a MultilistField on your SiteA/Article item, which enables you to select articles from the Repository item. By setting the Datasource field for the MultilistField to /sitecore/content/Repository you'll be able to select any or all.
However, that's probably not what you want, since you might have thousands of articles looking at your article names.
Another option is creating a sublayout / rendering that reads the latest X articles from the Repository item. With a simple for loop you could then do something like:
var list = new List<Item>();
var repoItem = Sitecore.Context.Database.GetItem("/sitecore/content/Repository");
for (int i = 0; i < 5; i++)
{
list.Add(repoItem[i]);
}
Which you could set as a DataSource to an asp:Repeater. Of course, you could do it in many different ways (select the number of child items through some lambda expression, use Lucene to get the items if you also want to use keywords etc.).
You can also have the number of items defined somewhere in Sitecore, so it could be different for SiteB/News and SiteA/Article.
Looking at your question I can imagine you to eventually choose for an option like introducing Wildcard Items to present the data from your repository on those different locations. there is an interesting module available on the Marketplace.sitecore.net, have a look at that too before deciding what you want to do.
Reading your last line: I can pull any article from Repository/ Item and display it dynamically I would strongly suggest you to go for a wildcard solution.
Another option, is to use Sitecore Clones (from Sitecore 6.4) or Proxies (older than Sitecore 6.4).
Clones: http://www.sitecore.net/Community/Technical-Blogs/John-West-Sitecore-Blog/Posts/2010/10/Sitecore-CMS-6-4-Cloning.aspx
Proxies:
http://sdn.sitecore.net/Articles/Administration/Using%20Proxy%20Items%20in%205,-d-,3.aspx
Caveat Emptor: Turning on proxies and using them will affect performance. I think it works like this:
- each time it has to get items/children it looks in the Proxy table to see if any additional items should be added
- the more proxies there are the more "overhead" there will be to each "Sitecore query" has to look though all proxy items to see if there are any additional items that should be included in the result
Though this would copy all the items you choose to clone or proxy and might not be what you are looking to do.