Umbraco SQl to Find Nodes using a Certain Document Type

SELECT * FROM cmsContent C
INNER JOIN cmsContentType CT ON C.contentType = CT.nodeId
INNER JOIN umbracoNode N ON C.nodeId = N.id
WHERE CT.alias = ‘yourDocumentTypeAliasHere’

–use the node path to locate nodes in Umbraco

Umbraco Export to .NET – Skips properties in Inherited Tabs

Place a property of any type in the Generic tab and it always exports, move it to a tab inherited from the parent docType and it’s excluded from the export.

Seeing this issue in v.4.7, issue occurs with our without using the autoexport2dotnet (http://our.umbraco.org/projects/developer-tools/autoexport2dotnet) – because it’s an issue in the core export logic.

This is caused by what seems like a bug in the umbraco.presentation project, in \umbraco\presentation\umbraco\dialogs\ExportCode.aspx.cs in the GenerateProperties method.

		private object GenerateProperties(DocumentType dt)
		{
			var sb = new StringBuilder();
			
			foreach (var pt in 
                dt.getVirtualTabs.Where(x => x.ContentType == dt.Id).SelectMany(x => x.GetPropertyTypes(dt.Id, true))
                .Concat(dt.PropertyTypes.Where(x => x.ContentTypeId == dt.Id /* don't limit this to generic tab! && x.TabId == 0*/)).Distinct()
                )
			{
				//...loops and writes properties here

In the above the bit to remove is the “x.TabId == 0” that I’ve commented out – this limits the properties rendered to the first tab (the generic properties).

I have only tested this quickly, but seems to work perfectly – I will update here if I find any issues – cheers!

PS. Please note that this method has changed between version 4.7.0 and 4.7.1 because of a separate issue – however for both version removing the “x.TabId == 0” solves this issue.

If you include abstractions (interfaces) in your export, you need to make the same amend to the GenerateAbstractProperties method, so remove the check for TabId == 0 and make the selection distinct.

I wrote this solution here as well: http://our.umbraco.org/forum/templating/templates-and-document-types/18730-%27Export-to-net%27-not-including-properties-on-inherited-tabs

Umbraco Examine – Indexing Large Sites – ThreadAbort Timeout Error Workaround

This relates to a problem with Umbraco Examine indexing very large Umbraco sites. The issue is being looked at by the core Examine team, however if like us you can’t wait – the below describes a workaround we used:

As part of an Umbraco 4.7 (which ended up being a 4.7.1 upgrade for other reasons) we had an issue with the UmbracoExamine indexing timing out when initially creating the internal indexes for Members and Content respectively. This initial indexing action happens on the application start as the UmbracoEventManager constructor calls EnsureIndexesExist().
The item is logged in the work item here: http://examine.codeplex.com/workitem/10324 – and the good people at the Farm have already started working on a solution.
The current solution is to split the Lucene .add files into folders with 500 in each, which improves the IO performance. Another very welcome addition is a new RebuildOnAppStart configuration setting in the ExamineSettings.config file:

<Examine RebuildOnAppStart="false">


We used this setting in conjunction with the Examine Index admin package found here: http://our.umbraco.org/projects/backoffice-extensions/examine-index-admin – which allows you to kick off the indexSets one at a time, and monitor the progress.

Some other potential issues:

  • In a large site you might get >9 batch folders in the queue folder – currently this breaks (bear in mind we’re using untested source code here). Likely this will be fixed soon – but if you still get this, you need to add a Int32.Parse to the ordering statements in the LuceneIndexer.cs file.
  • The processing does not index all the queued batch folders, again you need to look at LuceneIndexer.cs, in the ForceProcessQueueItems() you need to order the names using an Int32.Parse and then convert this sort to a list before iterating.
  • The Examine Index package may time out before generating all the .add files (in the batched folders) as this is not done asynchronously. To solve this we added this to the package file at \usercontrols\packages\umbraco\ExamineIndexAdmin.ascx.cs (note this does not have to be compiled, uses the CodeFile attribute in the aspx):

    private int _orgTimeOut;
    
            private void Page_Init(object sender, System.EventArgs e)
            {
                _orgTimeOut = Server.ScriptTimeout;
                Server.ScriptTimeout = 3600; //1 hour (seconds)
            }
    
            private void Page_PreRender(object sender, System.EventArgs e)
            {
                Server.ScriptTimeout = _orgTimeOut;
            }
    

    This is adapted from here: http://codebetter.com/petervanooijen/2006/06/15/timeout-of-an-asp-net-page/.
    I'm not sure it's a super great solution, as it will affect all requests until the pre_render event reverts - but I wanted a solution that did not require us to modify the web.config.

All in all, the above is a viable interim solution for what is likely to be a temporary problem in the Umbraco Examine project. Once these indexes have been generated, the day-to-day indexing is unaffected by the size of your content (or number of members) and works perfectly.
As discussed, it also seems that the Umbraco Examine folks at The Farm are already aware of these issues, so I'm sure they will have an updated release that fixes this (properly) very soon.

Umbraco Upgrade hangs at 35% “Upgrading Database Tables”

This is an issue that seems to apply to the install wizard for Umbraco 4.6 and 4.7, when upgrading from older versions.
At the database step you get to 35% with the status “upgrading database tables” – and nothing else happens.

This is caused by a bug in the install code – the format of the code makes it hard to spot – but below reformatted section from \umbraco\presentation\install\utills\p.aspx.cs shows the problem – the first block is incorrect and should be removed:

Howver, at the point where you see the “35% Updatings database tables…” the code has already checked that’s it’s able to connect to and upgrade your database. The Install() call (above) is a quick set of SQL statements – only takes a couple of seconds to run – and the RefreshContent() is async (will run separately in another thread), so if you have been looking at the “35 upgrading tables” for a little while it’s pretty safe to assume that this has completed without errors, and hitting F5 will then force a recheck of your database which should send you on to the next step.

I’ve also covered this issue in the Umbraco forums here: http://our.umbraco.org/forum/getting-started/installing-umbraco/17531-Upgrade-to-461-Updating-database-tables-Problem

Umbraco Database Size – Cleaning Unnecessary Versions

Lots of details on this here: http://blog.thoehler.com/?tag=Umbraco%20Database
Including a good overview of the core Umbraco Database as well.

Umbraco Preview Performance (v.4.5.2)

Recently had an issue with the Umbraco preview feature, where editors can view saved (but not published) changes in the actual site.
This adds a nice little “Preview Mode” banner top-right, but otherwise let’s you browse around the site as you please.
The way this feature works, is it copies the XML file cache (\app_data\umbraco.config) and then updates this copy with any “saved but not yet published” content nodes present in the site.
On a large site however (35MB content file) – this runs painfully slow, and with multiple editors the performance issue can affect your server(s) to the point where the normal site is no longer functional.
Looking into the issue in the Umbraco source we found that the core “GetXML” method on the UmbracoContext class, has a little “IsPreview” switch (this flag is set as a cookie called PreviewSet btw) – and the issue is that the “GetPreviewXML” function is uncached, and so will read the full XML file from disk on every single call to “GetXML”… and this has a lot of calls. Things like XSLT macros will repeatedly request the XML content, so on a complicated page you can see hundreds of calls to GetXML – meaning in our case that each page load (with the user in PreviewMode) would literally ask the server to load a 35MB text file into memory about 200 times.
The below solved the problem – but code could be tidied a lot (to mirror the core XML caching functionality).

//TP 20110317 - add a little caching to this:
private PreviewContent _previewContent;
public XmlDocument GetXml()
{
    if (InPreviewMode)
    {
		if (_previewContent == null)
		{
			_previewContent = new PreviewContent(new Guid(StateHelper.GetCookieValue("PreviewSet")));
			_previewContent.LoadPreviewset();
		}
		return _previewContent.XmlContent;
    }
    else
    {
        return content.Instance.XmlContent;
    }
}

The above will read the preview XML from disk once per page request, and then serve that from the local variable for all subsequent calls to GetXML during that page request.

Setting up Umbraco in Visual Studio

In the time I’ve worked with Umbraco I’ve seen two types of project setups (in Visual Studio) – one simply places the project on top of the actual Umbraco installation, and then excludes some folders, where as the other uses Visual Studio build events to copy your project output into a separate “clean” version of Umbraco.
This link describes the latter “copy-over” approach: http://our.umbraco.org/wiki/how-tos/getting-started-with-umbraco-what-is-next-after-you-install/setting-up-your-project-in-visual-studio and this link (amongst other things) describes the first mentioned “in-place” approach: http://www.aaron-powell.com/how-i-developer-umbraco.

On balance I prefer the “in-place” approach. The “copy-over” is nice, in that it keeps your project small, and allows you to keep the Umbraco solution completely out of Visual Studio. However, as you project grows the build time will increase either way, and what will really (really) get your goat, is the time it takes to even make little CSS or HTML changes. You make these and you have to do a full build, which will copy over all configs, binaries etc – which will in turn trigger the app pool to recycle and on a large project, you can easily end up waiting more than 30 secs for even the smallest updates.
I’ve worked around this before by configuring different build configurations in visual studio and then only copying say HTML, js and CSS for the “Frontend” build – but it still gets slow.

The “in-place” approach seems messy to start with, but actually it works very well. Once you exclude your items from Visual Studio it’s much like working with the “copy-over” solution, but you have much faster build times.

Happy Umbraco’ing whatever you go with!