A real quick post on something that stumped me and had me scratching my head last week. A colleague mentioned that when browsing the Production site with
?sc_mode=edit appended to the URL then the site would attempt to redirect the user to
/sitecore/login page. In some cases it would cause an infinite redirect and cause the browser to throw a “redirected too many times error”.
In and of itself, it didn’t cause any security issues – the CM server was only accessible to our internal network and we had followed server hardening best practices and blocked access to the CMS interface on the CD servers (we actually just return a 404 rather than anything specific related to access denied).
We had also correctly followed the guide to configure a CD server so was pretty sure it was not related to having missed disabling a file.
So I asked on Slack if it was expected behaviour that appending
?sc_mode=edit would attempt to redirect to login page on the CD servers, I would have expected it to do nothing. Having then dug a little into the Context code, turns out there is a setting for this which we had completely overlooked.
I recently got a ping back from Eric Stafford on an old blog article of mine, the first one I had ever posted! He was working on some code and needed to inject in some custom CSS into the Experience Editor. We had several conversations on Slack, and I thought I’d post up some powerful ways in which to achieve this. Be sure to check out Eric’s posts, he’s done a fair amount of research into different ways of achieving this as well.
a.k.a “Rendering Wrappers”
tl;dr; MVC HTML Helper and custom CSS styling to add chrome highlighting around renderings in Experience Editor mode.
I presented this module at the Sitecore User Group London on 12th January 2017. You can download the slides for that lightning talk here.
A few months ago I presented Session 4 of the Unofficial Sitecore Training sessions that Akshay “Be My Friend” Sura and Mike “Blog All The Things” Reynolds have been hosting. If you’re new to Sitecore or need a refresher course then I suggest you head on over and watch the videos on the series, there’s some really useful info in there from some seasoned Sitecore developers and gurus.
Anyhow, I decided presenting stuff and virtually pointing things out is hard so I added a fairly early version of some code that we had been using and experimenting with on our current project. This would make it easier to see components in Experience Editor mode and therefore easier for the audience to follow along with what I was doing. Some people noticed this at least 🙂
tl;dr; Install the module, set the config value to match your environment, have a stylised login screen and header bar per environment.
Have you ever sat there working on some task and then suddenly someone asks you to take a look at an issue on the Production environment? So you log onto that server, resolve the issue, get distracted for a few minutes by cat videos and then get back to what you were doing. But you suddenly realise that those changes you were just making was not on your local environment, you still had the Production site open in your browser tab! Oh noes!
The problem is that all the environments all looks exactly the same… the only difference being that teeny tiny URL bar, the URL in which probably also looks very similar apart from some environment prefix.
One Sitecore Best Practices is on rendering and sublayouts is to make use of all the setting that are available to make Content Author lives more friendly, namely:
- Setting a thumbnail which is displayed when they select a component to add
- Restrict the datasource location to allow better grouping of content types and direct authors towards where datasources should be created to help keep everything organised
- Associate a template with the component so the correct datasource type is created
- Setting Compatible Renderings to allow authors to easily switch between renderings without causing errors
- Make use of Experience Editor/WebEdit Buttons to add custom funtionality
Did Vasiliy do a Friday Best Practice on this yet?
The launch of Sitecore 8.2 just a few days ago brought with it a a huuuuuge list of updates and enhancements. One of those great new features is an update in the Experience Editor to make the life your content editors much simpler and better to managing the content through workflow.
Component based design/architecture seems to have gained a lot more traction again in recent times especially with the Habitat project. But Sitecore itself has fully support component based design since version 6.4 (at least) with the numerous enhancements that were made to the Page Editor in that release to add better support for Datasources. In order to fully utilize all the analytics and personalisation features, you have to use datasources, you’ll be fighting the framework if you don’t.
Due to its page-based nature, the Page Editor/Experience Editor has also had problems giving appropriate information to the editors when dealing with heavily data-sourced pages and content items that may be used on several pages.
This leads to numerous problems:
- You don’t know where a datasource is used. Making a change on a component in one page may affect several other pages when the datasource is shared or used on multiple pages.
- You can’t be sure that a page will not be broken after publishing. When you workflow content, you don’t know what state a page is in as a whole. Although the page item itself is in the Approved/Final state of workflow, the associated content used on that page may not be. Therefore publishing a page even with the “publish related item” option would still not publish those non-final datasources.
WFFM. The marmite of Sitecore modules. It’s possibly one of the most commonly used of Sitecore modules but we all love to hate this module. Despite its rough edges, we battle on. I have to admit that I had not used this module in some time; until using it with Sitecore 8 in its MVC guise the last time was over 2 years ago in webforms (ASP.Net, not Sitecore :p).
As improved as it is working with MVC, one thing that frustrated me was creating a bunch of forms only to find that there was a gazillion copies now littered across the site. Why? Because when you add an MVC Form rendering onto the page the only options presented to you is to either create a blank a form or to duplicate an existing one.
Another quick blog post for a fairly minor bug but causes a big annoyance for the content editors.
I tend to use Rendering Parameters a fair amount, it’s a really neat way of making controls more flexible and customisable without duplicating work, making it much easier for editors. But in all versions of Sitecore 8 I have worked with (update 2 to 5) whenever you click “Edit Component Properties” the Control Properties modal opens up correctly but you also jump to the top of the page:
This is such a simple bug that it’s hardly worth a blog post, but something that has been annoying me for some time that finally this week a colleague of mine pointed out the issue. I noticed a few other people suffering from this on screencasts as well.
Well, it seems that it wasn’t so random after all and there was a consistency to when it would appear or not appear…
In a recent question that popped up on Stackoverflow, the user was trying to add some content via the Page Editor, but if the datasource was not set they were using code to create a child item under the current item and set that to the datasource. I suggested setting the
Datasource Location and
Datasource Template fields on the Rendering and just let the user handle the action via the “Select the Associated Content” dialog.
Unfortunately I couldn’t find a good blog post which covered the information I was trying to portray, or my Google skills were lacking a bit. For those seasoned Sitecore developers, this should be pretty second nature, but hopefully useful info for those new to Sitecore and finding their way around.
The following is out-of-the-box functionality, and provides a very user friendly way to add a component to a page and then associate existing or create a new item of a predefined template.