Sitecore: How to Detect a Sitecore Website

Introduction

This post is nothing more than to satisfy people's curiosity about websites built on the Sitecore CMS platform.  Assuming you do find yourself at the login page, hacking into the content administration area is strongly discouraged using the default login of admin/b.

Approach 1

We can always attempt the very obvious feature of Sitecore which is the default login page.  This is assuming there was no separation of content authoring and content delivery environments.  Try to browse to:

http://www.domain.com/sitecore/login

If you hit the login page then you have succeeded.  The chances of hitting this page in a production environment is probably close to zero.

Approach 2

You can attempt to modify the browser URL by appending Sitecore-specific paramters and values such as:

?sc_site=(...)
?sc_lang=(en/en-ca/fr-fr/...)
?sc_mode=(normal/edit/...)

If you are able to change languages, bring up page editor, or even hit a default dummy website, then you have succeeded.

Approach 3

You can purposely modify a working URL and see if you hit the default 404 page with a URL that looks something like this:

Approach 4

With an inspection tool, look for the cookies that are accepted by the browser. Two cookies that are used by Sitecore are:

Summary

Keep in mind that developers can choose to hide or modify any of these elements if they really go the distance to hide things from nosy inspectors so none of these are fail-proof but is a good start for most sites. 

Sitecore Upgrade Headaches: Item Buckets

I had to perform a site upgrade from Sitecore 6.6 to 7.0.  The major reason for the upgrade...Item Buckets of course.  The biggest problem created by this upgrade...also Item Buckets.  Take a closer look at the upgrade instructions from Sitecore SDN which includes this warning:




This basically means that you should not be upgrading to Sitecore 7.0 if you were too overly excited about the Item Buckets module which you downloaded in the marketplace before 7.0 came out and when it was just a cool concept.  For those of you who got ahead of yourselves by playing around with it, you are all screwed.

Since there is no way to uninstall modules in Sitecore elegantly, I guess we are all screwed and not able to upgrade to 7.0 right?  Well, just because Sitecore does not officially support it does not mean it will not work.  Sitecore just wants to protect themselves from all your complaints by saying that, no hard feelings.

The headache here is that you already have already referenced assemblies such as Sitecore.ItemBuckets.Kernel.dll whereas the new assemblies created by Sitecore for Item Buckets are named Sitecore.Buckets.dll and similar.

When you refence the old assemblies along with the new ones and you deploy, you will have both sets of assemblies in your bin.  The admin UI will look just fine when you browse around and do your content updates but once you decide to use the cool new search feature, you will see that no results get returned, even AFTER you have rebuilt the search indexes.

If we use an inspection tool such as Firebug to look at what is going on, you will see that there are ambiguous references to search methods that exist in both sets of assemblies.  The quick fix was to delete all the old assemblies except the Sitecore.ItemBucket.UI.dll assembly manually from the bin.  This did the trick.  I think the UI somehow is still stuck in limbo from the manual Item Bucket module so that's why that one assembly has to stay to make it happy.

At this point the search should work but then again we encounter another problem.  You will probably step away from your computer for a little bit and return to find that the search no longer works.  Arggghhh!!!!  Why?!!!!!

Well, apparently now there is a Search.ashx handler error being thrown.  It does not make sense because the right rail menu also calls the same handler to generate facets and it works but the main results are not populating.

This took a little trial and error, but apparently, if the session times out, then Search.ashx will fail for the main results.  An easy fix was to increase the timeout time in IIS from something like 20 minutes to something like 120 minutes and recycling the app pool.

Again, this all does not make much sense but works.  If you are stuck in the situation of a manually installed item buckets module in a 6.x environment and has to upgrade to 7.0, then give these steps a try.