The /sitecore folder – runtime

In the Sitecore SDN Forums, Michael Lumpp just asked a very interesting question: “Do I have to have the ‘sitecore’ folder on the runtime server?” (i.e. does the running website need any files in the /sitecore folder)

I’ve been working with Sitecore for quite a while now and my first though on this reply was “Of course you cannot remove the Sitecore folder, because…” – well because what? So my second though was “Dammit i’ll try it out” – and…

System.Xml.XmlException: “The root element is missing”

To be frank, I’ve not once though to remove the Sitecore folder even from some of the major solutions I’ve been on – and it makes perfect sense. There really should be no runtime specific data in the /sitecore folder – well at least not in the /sitecore/admin, /sitecore/debug, /sitecore/login, /sitecore/shell, /sitecore/testing (actually /sitecore/testing sound like it should not have been released at all), and the folders not mentioned here sound like they at least could be removed on some projects. So why does it fail?

It seems one runtime file has snuck its way into the /sitecore folder – to be more precise: sitecore/shell/Security templates.xml. Because security is such a low level part of Sitecore and affects all reading of data via the API, and since all data in Sitecore are based on templates – even security data – initializing the templates for Users, Roles must be done before all data access through the normal API can begin (a genuine catch 22). The templates for security are therefore specified in a file – Security templates.xml.

Luckily this file – along with its path – is specified in the web.config and can therefore be moved (two changes are necessary – to find them search for the path), and – hey presto – the /sitecore folder can be removed with out exceptions being thrown.

Please note that there are other links in the web.config file which must be changed, e.g. /sitecore/nolayout.aspx which is used to show a pretty error page when a layout is not present on an item. But these should be fairly simple.

Also note that this is Sitecore 5.3 only – Sitecore 6 has an entirely different security architecture and therefore none of the above is probably valid.

Happy /sitecore deleting 🙂


Configuration in Sitecore

Ever considered putting environment specific configuration in the Sitecore database? …well don’t.

In the official Mailing list module, Sitecore has, among others, placed the database connection string and we have nothing but grief from it. Consider moving from development to test to production, or in the latest example a customer wanted to have an internal test site nightly updated with the production database. Sigh!

Real Sitecore style, we’ve even looked into the possibility of hooking into the database connection of the mailing list module – but no:

  • All database access in the MailingList module goes through the internal class Sitecore.Modules.MailingList.Core.SqlHelper
  • This class is only accessible through the internal property SqlHelper SqlHelper in Sitecore.Modules.MailingList.Core.MailingList
  • SqlHelper opens a database connection in the protected (but not virtual) IDbConnection CreateConnection()
  • This function returns an SqlConnection if the Sitecore field “Database” contains the text “MSSQLSERVER” (*Sigh*), otherwise an OleDbConnection is opened
  • The sql server ConnectionString is read from public static string Sitecore.Modules.MailingList.Core.MailingListSettings.ConnectionString
  • This property reads the value from the field ConnectionString in the Sitecore database

As you can see there is no way of plugging in anywhere…