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.
Related
We upgraded the sitecore from 7.2 to 8.1. Since the upgrade the content authors are complaining that the experience editor performance is much slower than previous version. It takes long time to load and also editing experience is very slow as well.
For now I've reverted back to SHEER UI version of experience editor by updating experienceeditor.config.
I read this blog post below but option 1 and 2 states "be aware that there are significant consequences...".
http://kamsar.net/index.php/2015/02/sitecore-8-experience-editor-performance-optimization/
Has any one experience this issue? And have any recommendation for the fix?
Thanks.
Reverting to SheerUI is probably an option you could consider... we know it works faster that the SPEAK UI, so it's a quick win to help out your content editors at the moment.
However Sitecore is moving towards SPEAK, and so I'm not sure how long the SheerUI interface will still keep up with the new features of the Experience Editor.
In addition to the pre-compilation of Views, you COULD attempt Kam's optimization, but as he mentioned, there could be significant issues that come about because of it.
I would also have a look into some other possibilities for speeding it up, like:-
Use the application cache to increase the performance of loading the
Experience Editor ribbon. - (https://doc.sitecore.net/Sitecore%20Experience%20Platform/The%20editing%20tools/Improve%20the%20performance%20of%20the%20Experience%20Editor%20ribbon)
Using ContentSearch instead of Fast Query for the 'My Items' count - (http://mikael.com/2015/12/speading-up-the-sitecore-experience-editor/), or even turning off the count altogether (http://sitecoreblog.alexshyba.com/hidden_gem_of_sitecore_page_editor/). UPDATE: Sitecore now has a Support DLL for this. (https://kb.sitecore.net/en/Articles/2015/12/04/14/31/549951.aspx)
Customize or even disable the SuggestedTestsCountRequest. - (http://blog.horizontalintegration.com/2015/07/05/sitecore8-experience-editor-slow/)
Suddenly all ribbons are not coming in Sitecore 8 one of my project.
For example If I am going in publish menu I cannot see any option there.
To solve this issue, I have updated all three folders and config file "sitecore,sitecore_modules,sitecore files & web.config" but still ribbons are not coming for me.
Please assist me what can be solution for this issue.
Thanks all for your effort. I just copied fresh "Content Editor.js" in Content Manger folder and my problem solved.
I believe your ribbons are just collapsed (not expanded). To expand them back there is a little check on the right hand side of the screen. Check the screenshot for reference
I also have same problem and this issue usually coming by difference the version sitecore when you want to integrate with your solution. Try with another sitecore (sitecore,sitecore_modules,sitecore files) version that it
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 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.
Anyone else ever have the Firefox toolbar "refresh" button not work for a particular page? Works everywhere else. Firefox 3.6.15. Any clues?
EDIT: For what it's worth, I later set network.http.use-cache false, and the problem went away. No idea whether that was much more than coincidence, though.
There is not a lot of detail to go on in your question, but what will often happen is that firefox will cache certain elements of the page and not actually re-fetch them from the server. Try using the TamperData Add-On for firefox to see exactly what data is being transferred from the web server.
You can also just try a Ctrl-F5 to do a force page reload.
While I can't say that I have had that problem, most "weird" behaviors I've run into were due to extensions. You might try disabling some of the more intrusive ones. Greasemonkey perhaps?