I am looking at a content item with many renderings.
I need to move one of the rendering down so it show lower on the page.
I can move it in the Edit presentation settings but as soon as I click ok, the order remains unchanged.
Note, it does work sometimes but is intermittent.
I have looked in the logs and nothing seems bad apart from this:
1032 11:20:45 WARN Long running operation: renderContentEditor pipeline[id={E23237A3-1FEB-4E9A-AEB6-543807ED6CAD}]
I feel this might be a Sitecore bug.
Has anyone experienced this before?
There was a similar issue in 6.5, but I assumed it would have been addressed in an update. Basically, the issue is a result of presentation setting deltas at the item level incorrectly merging with the standard values presentation settings of the item base template.
I would suggest contacting Sitecore support for a workaround or solution. Reference case #387488 and provide detailed steps to reproduce the issue.
Related
I have a number of user-defined metrics in Google Stackdriver. Then I edit one of them using "Edit metric", edit the filter, and click Save.
When I look at a different user-defined metric via "Edit metric", my previous change seems to show up here too. Wtf?!?
Does anyone else have this problem? Am I doing something obviously wrong?
It's us, not you—this is a known issue with that piece of UI at the moment. We're working on getting it fixed and it should be addressed soon. Direct API access is unaffected and is a workaround for the immediate future.
By the way, if you use the feedback widget in the speech balloon in the top toolbar when you see issues like this, it captures a detailed report including things like browser version/platform/etc. that can help us track issues down. We don't need it in this case (this one is well in hand), but that may be a good course of action for the future.
Thanks for trying out Stackdriver, and for your patience with beta issues. =)
I've been wondering if anybody knows why the Presentation Details (stored in the Renderings field) are shared across all languages and versions by default?
I had confirmed this was the intended behaviour of 'shared' field with these links:
This SO post:
In Sitecore, when adding a field to a template, there's a checkbox called "shared". What's it for?
And this SDN resource:
http://sdn.sitecore.net/sdn5/reference/sitecore%205,-d-,3/field%20reference/field%20properties/data%20properties.aspx
The situation
As an author, I have created a new page and pushed it through workflow approval. Everything is great, and the page is published. The next day, I want to make some changes so I open up Page Editor, a new version is created, and I start adding and removing components on the page.
The problem
As soon as I hit save, the approved and published version of my page is also affected. The history of my previous layout is gone. As soon as a Site Publish is executed by somebody (or a scheduled PublishAgent executes) my page in the Web database will be updated.
Sure, the datasource of my new components that I added may not be published yet, but what if I added an existing datasource that was already approved? My removals also are immediate.
The desired goal
I'd like to be able to version these changes, and changing the field to no longer be shared seems like the right way to go. In my case, with a unilingual site, this won't impact the multilingual aspect of it.
Does anybody know why this field is shared across versions? If I unshare it, am I completely breaking the upgrade path?
I've just been "having a chat" with Sitecore support on this very issue. The concensus seems to be - paraphrasing what they said a bit - "We think it'll be fine if you change it. You should test it thoroughly, rendering deltas, page editor Work and so on".
I can add a few comments of my own; unchecking "shared" on __renderings, does appear to Work. At least at the initial glance. I've heard about this being done in solutions before and I've never heard any ill effects come from it.
And yet; whenever you mention it; you get a LOT of nervous responses and comments like "you really shouldn't be messing with Sitecore standard setup". And while a valid point indeed, I'd like to add a point of my own to this debate:
Given that, from an API perspective, there is very few things that are different when reading a field value from a "shared" field as opposed to a versioned one - I also believe there are very few potential cases where "unsharing" it would pose a problem.
Or in other words - I consider it low risk. But I've never had a real life solution running in a live environment either, with this setting changed :-)
I'm sorry, but I don't have a direct answer to your question - WHY Sitecore set it up like this, I belive to be part of Sitecore's heritage: The idea that multiple language versions of a site should be just "layered" versions of the exact same pages and therefore presentation details might as well be shared - presumably for some performance gain. I am not entirely convinced this vision still quite holds today - where editors daily "page edit up" new components on new versions, and set up special sale banners and related content weeks in advance.
I completely agree with and am thankful for the Mark Cassidy March 3 2014 answer to this. Since then, in Sitecore 8.0 they added "Versioned Layouts".
See:
https://dev.sitecore.net/en/Downloads/Sitecore%20Experience%20Platform/8%200/Sitecore%20Experience%20Platform%208%200/Release%20Notes "Versioned layouts – a different presentation set on different versions of different languages for the same item".
nice post: http://jockstothecore.com/sitecore-8-versioned-layouts-mixed-feelings/
This is the default behavior of sitecore as you mentioned in the post. Its not always good practice to change that. This topic has been dicussed earlier which might help you
Setting __Renderings field not shared in Sitecore consequences?
Here is a blog post about considerations for doing this:
Unsharing the Layout field in Sitecore - a multi-language strategy
That said, I've worked on a project where our client went in and did this themselves. It caused problems. As I recall, they unshared the __renderings field and all prior versions lost their presentation settings. Also, other languages other than the selected one also lost their settings. We had to do a DB restore and get things back and told them never to do that again. If you are considering this, read the blog post about, and do some isolated dry runs as it may expose issues you weren't aware of (e.g. impacting other languages, old versions, etc.).
I'm using sitecore 6.5 content editor and it the back and forward buttons are disabled in 6.5. I've decompiled the code and it looks like it could be related to history points?
I recently upgraded from 6.2, perhaps I am missing something in the web.config or sitecore.config, but a simple comparison using beyond compare doesn't really lead me anywhere.
Any suggestions would be awesome.
FYI this was a confirmed bug that was resolved in version 7, not sure if there is a patch for previous versions though.
I turned on my debug toolbar and was surprised to see the stock template where the panels are aligned to the right.
I upgraded to django 1.3 and re-installed most of my requirements via PIP, which is where I imagine my usual toolbar disappeared.
I had always thought it was David Cramer's fork that had the green panel bar docked at the top, which I find insanely more usable (doesn't obstruct anything), plus it had some default default panels like unique SQL counts.
Now that I've cloned both David's fork and Rob's original, I see neither have this green dock.
Am I going insane? Is this a setting I've missed, or perhaps a different fork? I would kill for the workflow I'm used to!
Update: I've looked through the commits, and indeed, there was a version in 2009 that was docked at the top, but had nowhere near the functionality that the version I'm talking about had. The exact commit that moved the toolbar to the right appears to be: https://github.com/dcramer/django-debug-toolbar/commit/565b100f9d97214043ae93c51d276951a65331e8
But nowhere can I find this awesome version below:
It also claims to be version 0.2 which I find odd too. I will keep going through each commit but any help would be appreciated.
It used to have the bar at the top. The new version has the new sidebar layout.
Update:
I tried to find out which version it was, but found this page where you can download older versions.
https://github.com/robhudson/django-debug-toolbar/downloads
Update2:
Here is the commit where he moves to the side panel 8-11-2009. Yeah a long time ago. I guess it has been a while since I upgraded as well :)
https://github.com/robhudson/django-debug-toolbar/commit/565b100f9d97214043ae93c51d276951a65331e8
I have a strange error in my Sitecore environment that I've been ignoring since I started development (since it is only a minor inconvenience), and that is the fact that in dealing with large menus near the bottom, they get clipped by the bottom of the browser. Items then should detect the bottom and build upward, I guess, but they just don't. I have gone through the Sitecore Initial Configuration for Internet Explorer document several times.
Has anyone come across this?
Thank you for your time.
Try adding the Sitecore site to your Local Intranet zone in IE, if it's not already.
(btw this is probably a better question for SuperUser, though doubt many sitecore folk monitor that stackexchange)
Please check on start up window of sitecore that Sitecore support this browser or not.