I am creating a Sitecore MVC site for a client and I need to create page that will list news articles for the company.
So far, I have created items that use a shared data template called “Article,” and I also have a sublayout (a view rendering) called “Article” that will display these items.
For the list itself, my plan was to create another component (a sublayout) call “News_List”, and to put a placeholder in it called “List”.
My question is this: can I allow the author to insert articles (e.g., N items of type “Article”) into this placeholder via the page editor?
Will SC allow you to insert multiple instances of the same component into a placeholder? Will this break anything?
I believe this is a pretty common question but I have not found a definitive answer. Thanks in advance…!
You can insert as many components (of the same type) in your placeholder as you want.. Just make sure to put the placeholder settings correctly and give it a decent name (not just "list" ;))
But are you sure you want to do this? Your editors will manually need to create a list of components for each article they want to add on the page. Doesn't sound to be very user (editor) friendly.. Maybe you should consider creating a list component that can get a list of articles as a datasource and show those. Or even select them automatically (but that might be not according to your business case)..
Yes, authors can add multiple instances of the same component into a single placeholder.
Assuming that the code of the component doesn't do any stupid things it's absolutely ok to do this.
Related
I used to implement listing/detail scenarios using wildcard items, meaning that, for the sake of URL, I create a regular item to display the list and then under that node, I create a wildcard item to represent all possible detail pages, like:
/news/*
(i generate a friendly name by code to replace wildcard and produce the full URL such as: mywebsite.com/news/the-meeting-press-release)
Then I create a folder or a bucket of content items somewhere else as my repository. Then I assign same datasource to listing node and wildcard node to give them same repository of content items.
Main reason I want to do this is to use datasources and make navigational nodes (which generate actual pages and URLs) to be separate from Content folder structure. In other words, separation of concerns: navigational items as presentation nodes and content items as my data repository.
This is an easy way to work around master/detail requirements but I always feel guilty about this, it feels like this technique breaks integrity (sitecore links table on database) and design pattern in Sitecore back-end.
For example when I look at Analytics, I get * as name of items, clearly the it feels like aliens to back-end system.
I know this is not a new topic. I have seen threads like this or ideas like Sitecore Pipeline Processor for Virtual Items to implement such requirements.
Is there any best practice about this? Have anyone good example of what is most sitecore-friendly way to implement such pipeline processor? How do you address this issue with wildcards on Analytics?
I'm going to go a different way to Martin here. I have successfully used Wildcards many times for the exact purpose you are suggesting (For an example have a look at http://www.atpworldtour.com/news - all news articles are items in a bucket with a wildcard to resolve the url).
There are 2 options to enabling the page editor.
The news article item becomes the page. In this way, you need a new processor in the httpRequestBegin pipeline that resolves the url to the item and then sets Sitecore.Context.Item to the current item. IIRC you do this by setting one of the pipeline argument properties. This will work fine in the page editor as the context item - the one being edited - is the news article. And then other renderings on the page can just use data sources as needed.
The news article resolves to a Datasource. I have also tried this method. To do this, you need a custom Datasource resolver. I sill used a processor in the httpRequestBegin pipeline so that I didn't have to resolve the Url multiple times for each rendering that needed the datasource. But then in the RenderRendering pipeline I had a processor that detected if I wanted a wildcard Datasource and used the item that had been resolved in the httpRequestBegin processor.
There are pros & cons for each method.
Option 1 is nice and simple. It means that you could use a single wildcard to resolve different "types" of page item as the presentation is on the page item and not the wildcard item, also each item can have its own custom presentation, so Datasources set in the page editor would be unique to an article. That is also a disadvantage in someways. A/B testing becomes more difficult with main article text etc... You are limited to testing article versions.
Option 2 is more flexible in the testing area - you can easily test/personalize parts of the article by changing the Datasource. But you are more limited as the presentation must be set on the wildcard. So renderings that are not part of the main article will have the same content/settings across all news articles.
I was previously in the same boat as you are. The are few issues with wildcard items, like resolving datasources or disability to run a page in Page(Experience) Editor or nested wildcards. Regardless of that, I have used wildcard few times and they do their job.
I've managed to resolve datasources properly, based on URL (see blog post: Automatically resolving correct Datasources for wildcard items based on URL), still did not sort the rest others.
Update: Richard suggests the way of implementing Page Editor below, you may find this helpful
Thus, my answer would be:
I would recommend you to keep classical approach of having a page item for each news item, rather than using wildcards. Content authors would use habitual approach (and page editor) rather that editing datasources somewhere on the content tree in Content Editor. If you configure that properly with templates and standard values - there would minimal hassle to create new news article.
In case if you worry about potential raise of number of news articles - use Buckets along with it (or suggest manual strategy to group them into folders).
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! :)
So I am rather new to sitecore, and it's a topic that wasn't covered during my training. My questions is just to help point me to the correct term, or documentation on a method to do the following.
I have a definition item, with a ton of field groups, what I want to do is something like:
if Value of Field X is "yes" then collapse/hide Field X or Field Group X.
Does that make sense? Is it a validation rule? or some other kind of rules, is it a workflow I need to attach? Do you place it on just the field I want to hide, or the field that triggers the action?
I appreciate any guidance.
There is nothing out-of-the-box in Sitecore to achieve what you want but there is no reason you cannot create a composite custom field type to do this. The following articles will help you achieve this:
Creating a custom Sitecore Field
Getting to Know Sitecore: Custom Fields, Part 1
Create a new control, inheriting either from Droplist (if the comparison of the value is to be text based) or Droplink (for comparison of ID). You could add a parameter in the Source field of the control to specify what the values that trigger the hide should be.
The underlying control in the Content Editor is just a standard HTML select element. Add onchange events to the control and add your Javascript handler to hide the other controls. Since I could not find a way of adding additional custom css classes to the Sitecore controls, it would be best/easiest to hide all other controls in the same collapsible group after you control. This would mean you would need to group your controls better (or logically at least).
The Javascript will be something like this (the Content Editor uses the Prototype JS framework):
if ($(this).getValue() == 'no') {
// find the parent container of this control and then hide all the next siblings in the same group
$(this).up('.scEditorFieldMarker').nextSiblings('.scEditorFieldMarker').invoke('hide');
}
You can test this by running the above in the console, change out the keyword this with the id of your field, e.g. $('FIELD2292054').
What I am not sure about is how to trigger the hide on initial load, i.e. when someone returns to an existing item, it may be possible by adding to one of the pipelines, but would be better using a JS solution if possible. I'll have a think about this and get a proper code sample up over the next few days.
EDIT: You can add an event handler to sc:contenteditorupdated to handle the content editor being rel-oaded.
document.observe("sc:contenteditorupdated", myFunction);
I wrote up a blog post and put the code on GitHub if you are interested.
Not sure if you have come across Andy Uzick's this blog post.
He wisely talks about hiding fields in the Content Editor and has also created a Sitecore Module called Hide Field Template Extension which is hosted on the Sitecore Marketplace with the full source code to extend.
After reading through and trying the extension, I do feel that it will not completely resolve your issue (how you have described it in the question).
But it will give you:
A mid-term solution to hide a few unnecessary field that some content editors would not like to view.
Fields that are only required by administrators for admin purpose - to de-clutter these fields could be hidden.
Just one thing to bear in mind that it mentions in the requirements Sitecore 6.5 & 6.6. I have not tested it in Sitecore 7. If you are using Sitecore 7, which I think you are, one could modify the source code and make it work for Sitecore 7.
Have a look and share your findings.
Happy Sitecoring!
Before digging into my explanation i will summarize my question:
How do I provide the user (editor) with a user-friendly possibility to select a datasource item for sublayouts that are preset on the standard values?
My situation is as follows:
I have a page template, with pre-defined layout on the standard values.
Let's say the layout consists of:
one placeholder "wrapper"
one sublayout "content"
This sublayout is pre-defined on my page template, but can also be placed in the placeholder using the Page Editor.
It needs to have a datasource item that defines a Title and Body value.
Now, if a user adds this sublayout to the placeholder using the Page Editor, he will get a nice interface to select or create the datasource item (see screenshot).
However, if the sublayout was pre-defined on the standard values, it will be added without datasource (I can't pre-set the data source in the standard values because it's still unknown by then).
At that point there seems to be no way to get to that nice interface for selecting or creating a datasource item.
Ideally I want to be able to add a field to my template that can hold a datasource item which the user can select/create using the nice interface. I looked at the datasource field type, which could be an alternative, but it's still not exactly what I want.
Bare in mind that the content sublayout is just an example.
I understand that in that specific case I could solve it by always adding a title/body field to the template which hold the values if there is no datasource, but for my real world problem that won't suffice.
I don't have a whole lot of experience with the Page Editor (with the new way of working with it) so I would like to get some advice on this subject.
According to what you said here:
Ideally I want to be able to add a field to my template that can hold a datasource item which the user can select/create using the nice interface. I looked at the datasource field type, which could be an alternative, but it's still not exactly what I want.
It seems you want an intuitive data source selector interface in the CMS shell similar to the Page Editor-based UI.
Quick answer: Simply put, there's nothing that does this for you in Sitecore.
Longer answer: There are still some options for you, e.g.
Define a global "dummy" data source and set that to be the data source set in in Presentation > Layout Details of the template's standard values. So every time you create a new page, it will always point to that dummy value to show something.
From here you can do a few things:
If the user must use the shell UI and not Page Editor, they can simply create another data source item for the specific page and update that page to point to it using the existing native interface in Layout Details.
Another option is to write an event handler, say for item:created or similar that when you create an item, auto-create a corresponding data source item for this specific page (whether this auto-created item be a sub-items or global item...) then programmatically set this to be the data source. A similar concept is shown in this video by Nick Wesselman: http://www.techphoria414.com/Blog/2012/May/Sitecore_Page_Editor_Unleashed
I'm working on a web application using Apache Wicket and I have three types of page that are basically a numbered list. The difference between each is how the items in the list are displayed. (i.e. one has a header line and a paragraph, another just has the paragraph). Eventually, the data will come from a database, but that is not available at the moment.
I think I can do this by creating a Page that displays a RepeatingView that gets its items from an ArrayList of Panels. I would create a different Panel for each type of list item. Then I could extend the aforementioned Page to three subclasses, one for each specific type of Panels I want. Am I on the right track, or is there a better way to do this?
I find RepeatingView to be very flexible with this sort of thing and you shouldn't require three separate pages. It only expects a component to be added to the repeater, not what kind of component. As long as you keep your Wicket IDs consistent, you can even mix components that come with their own markup (e.g. Panel/Fragment).
I also discourage you from using a List of Panels. It just makes good programming sense for the list to contain your data and then add the appropriate view container based on some flag.
So, markup like this:
<div wicket:id="repeater">
<div wicket:id="listItem" />
</div>
Works with something like:
RepeatingView rv = new RepeatingView("repeater");
for (DataObject o : dataList) {
// You can probably add to the rv directly, but this is the common usage
WebMarkupContainer c = new WebMarkupContainer(rv.newChildId());
rv.add(c);
if (shortVersion)
c.add(new ShortPanel("listItem", new Model<DataObject>(o)));
else
c.add(new LongPanel("listItem", new Model<DataObject>(o)));
}
Instead of providing a List of Panels to your page, you provide the same list of Data from the database and then add different panels based on the current view.
In the end, you have one page (with a flag for view type) and different panels (or fragments) for how your data should look according to each view type.
I don't think you'll have to subclass your Page. As far as I can see, this one doesn't change at all. All the changes are within the panels. So basically all you need to do is to provide your repeating-view with different lists of panels. You wouldn't even need to create different classes for these if the differences are as small as presenting a headline or not. Just set the headline to an empty string and set it to invisible...
Basically yes, you're on one of the right tracks, maybe not the one I'd choose but yours will work too...