When I remove a component in Sitecore from the Experience Editor, it is removed from the page but in Content Editor the component and its datasource still here! Does anyone have a solution for this? Thank you.
This is a bit of a tricky one as the datasource might still be referenced by other pages, or potentially by the same page in another version or language.
You could use an event handler implementation to scan the renderings on save and look for renderings that are removed (i.e. were in the original, but not the new version being saved). Then, for each one, check if they are referenced anywhere.
A sample implementation is shown in this blog: http://r-coding-sitecoreblog.blogspot.com/2013/10/cleaning-up-datasource-items.html
The other thing to consider is that your datasource might have presentation itself and may have other datasources it references. So, be sure to consider this scenario when cascading your delete from the Experience Editor.
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).
We have a Sitecore site that's using Glass.Mapper. We also have a simple two step workflow, "Draft > Ready for publish" on all items. There are global items, which are promos that can be placed on pages. Authors create promos, then create pages and place the promos on the pages.
If a page is published but a promo hasn't been published, the page returns this error:
Constructor on type 'OurSite.Sitecore.Models.IPromo' not found.
Since the scenario of authors failing to publish new promos is a real one, I would like to prevent this error from happening, so that the page just renders without the promo. Thoughts?
Another option would be to validate the datasource of components in the getRenderer pipeline. Marek has blogged about this with a solid solution:
http://www.skillcore.net/sitecore/sitecore-automated-validation-of-mvc-rendering-datasource
This also handles the scenario where components without datasource (ie. item was deleted) break the page in PageEditor.
That being said I also believe that in addition you should have a proper exception strategy as well. The link Jim Noellsch posted is a good one. I recall this one from Charlie Turano to be a solid one as well:
http://www.hhogdev.com/blog/2015/june/mvc-rendering-exception-handler.aspx
Assuming IPromo is an interface, convert it to a class model Promo. If this is an MVC solution, you could also override the OnException method to quietly suppress missing content.
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!
Currently working in SC7 where I have implemented a kind of scaffolding so that editors can add an article to a page and add sections and paragraphs under it. You get the idea, html5 stuff...
Now, the problem...
Editors are working in Page Editor:
Suppose you make a new page, and add an article. It has a title, hero image on top and an introduction. You choose to create new content and I save it in an ItemBucket called ContenStore where I store all my articles, sections, paragraphs... The SC7 way to use the search if they want to re-use any of that content.
Suppose my editor creates another new page, and he wants to re-use a section from the content store. He will find the section but when he has placed it on the page, non of the paragraphs that were on the original section show up... Of course not, since I guess the layout details are saved on the context item level and not on that section level...
Has anyone tackled this problem before? A sublayout (or rendering) should be able to remeber what layout details it has, so that if you re-use it, all the items it had originally are put in its placeholders again as well, and this recursively of course...
Any thoughts welcome...
Erwin
The problem you describe is not new to Sitecore 7. You would have the same problem in Sitecore 6, you would just have to go through the additional effort of keeping your content organized. This is a fundamental limitation of Sitecore's presentation framework.
I have worked around similar problems before by using Presentation Inversion of Control. (I should probably write an update for that since the rules engine approach no longer works)
I believe that Cognifide is doing something similar with the "Composites" in their Zen Garden, but instead of using a dummy layout they use an empty layout so any item can be opened as a page. Then they added a custom experience button which navigates to that non-page content item within the page editor. (Note that this is speculation based on a brief demo that I saw).
Thomas Eldblom also blogged years ago about what he called Composite Layouts. It's similar to PIoC, but puts the presentation settings on a special rendering type.
In short, there are ways to achieve what you want, but they all involve custom development and will require extra attention to maintain a smooth page editor experience.
I'd like to know if anyone has had experience of using rendering parameter fields in Sitecore to store content. If so, what drawbacks are there?
In some respects, this seems like an attractive idea as you can add a sublayout to a page numerous times without needing to create child items and setting each sublayout's datasource to one of these child items.... however putting content into renderings fields has a few disadvantages:
This solution is not localizable since the renderings field is shared, so no good for multi-language sites.
To edit the content (if using the content editor) you need to switch to the presentation tab, click details, select the sublayout then edit the rendering parameters which is all a bit cumbersome.
Are there any more serious consequences of adopting this approach?
There is no way to apply workflow to the fields.
There is no way to enable the fields for the page editor.
You can accomplish this just as easily by using the Page Editor and setting a Datasource Template and Datasource Location on your sublayout.
I'll reiterate something you already pointed out -- it's a shared field, so the content can't be localized.
There's no way to reuse the content stored in parameter fields.
Even if you DID do it, its hard to get the data from the parameters because they are XML-based (hint: add an Image to rendering parameters and look at what value you get back)
Overall, you are breaking the separation of content and presentation that the layout field is intended to provide. Please don't do this, one day a developer following in your footsteps will come across it and then spend all day on http://nooooooooooooooo.com/.