The issue is that different languages have different stop words, and word stems etc, so using the standard Examine analysers on say French content means that the results won't be as accurate as they would be using a French language specific indexer.

How do we do this? Firstly, we need to set up a specific index for each site, telling each on to start at the root node for the language. Set up the index set as you would normally, and then add the IndexParentId parameter to your declaration, like this:

<IndexSet  SetName="enSiteSearchIndexSet"  IndexPath="~/App_Data/TEMP/ExamineIndexes/enSiteSearch/"  IndexParentId="1090">

Once this is done, the index will ONLY index content beneath the parent node that you specified. You can then create an index for each site, allowing you to use different analyzers for each index if you want to.

If you prefix your searchers/indexes etc with the name of the root node, you can get that in your search code and use it to get the right searcher, so you'll never have to change the search code when adding new language sites (just add the new indexes etc to your Examine config).

I've been working on a multi-language site recently and ran into just this issue. Here's how I got round it and made a search that can be included on all of the sites, with no changes needing to be made.

First up, how can we limit the search? Handily, we can use the path variable, which stores the path of the page in the Umbraco content tree, in a format something like: -1,1060,1075,1230, where -1 denotes the content root, and the rest of the numbers are the nodes between the root and page that you're looking at.

In our user control that does the search, we can get the current node, and rather than jumping back up the tree, we can just split the path variable out and get the 2nd item in the array to get the id of the site root node, like this:

var currentPage = umbraco.NodeFactory.Node.GetCurrent();
string parentId = currentPage.Path.Split(',')[1];

Now we know the root node of the current site, how can we use it with our search? Handily, you can just add the path to your index settings file. However, the path gets stored in the index in a comma separated format, which is no good for searching, as Examine treats it as one big string, so searching for the root node on the raw path will return no results. However, if you were to replace the commas with spaces in the index, the numbers in the path would be treated like words, so you could search for your root node on it, and it would return only pages with the root node in their path.

So how to alter the index? Easy! You can plug into the Examine events to alter the index as it's being written. Basically we want to hook into ther event, get the path field, replace the commas with spaces, and then save it as a new field in the Examine index. Here's an example of the code that we used in an AppliactionBase class to hook into the event handler and make the changes:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using umbraco.BusinessLogic;
using Examine;

namespace MySite.UmbracoExtensions.EventHandlers
{
    public class CmsEvents : ApplicationBase
    {
        public CmsEvents()
        {
            //Add event to allow searching by site section
            var indexerSite = ExamineManager.Instance.IndexProviderCollection["SiteSearchIndexer"];
            indexerSite.GatheringNodeData += new EventHandler(SetSiteSearchFields);
        }

        //modifies the index field for the path variable, so that it can be searched properly
        void SetSiteSearchFields(object sender, IndexingNodeDataEventArgs e)
        {
            //grab the current data from the Fields collection
            var path = e.Fields["path"];

            //let's get rid of those commas!
            path = path.Replace(",", " ");

            //add as new field, as path seems to be a reserved word in Lucene
            e.Fields.Add("searchPath", path);
        }
    }
}

Obviously you'd need to change the "SiteSearchIndexer" part to the name of your indexer to get it to work! You'll also need to make sure that the path is included in your index (look at the default indexes in your Examine config files for an example of this).

Now all we need to do is make our Examine search look for the root id in the "searchPath" field. Here's the finished code where we get the root node, and use it in an example Examine search:

//do search
var searcher = ExamineManager.Instance.SearchProviderCollection["SiteSearchSearcher"];

var criteria = searcher.CreateSearchCriteria(UmbracoExamine.IndexTypes.Content);

Examine.SearchCriteria.IBooleanOperation filter = null;

//search on main fields
filter = criteria.GroupedOr(new string[] { "pageHeading", "pageContent", "navigationText" }, Search);

//only show results in the current path
var currentPage = umbraco.NodeFactory.Node.GetCurrent();
string parentId = currentPage.Path.Split(',')[1];

filter.And().Field("searchPath", parentId);

//don't show hidden pages
filter
    .Not()
    .Field("umbracoNaviHide", "1");

var resultsTemp = searcher.Search(filter.Compile());

And now your search should only return results for pages in the current site, not pages from ALL of the sites! Nice and easy to do, and a good example of how easy it is to extend Umbraco with its event model!

You can also use this technique to search a specific area of the site, e.g. have a dropdown to filter the search by the News area, or Events area. You could also have a single index for multiple sites, allowing for a search that spaned all the sites as well.

Those of you that have been using Umbraco a while are probably familiar with the excellentAutoFolders package, that allows you to have your content automatically sorted into date folders and alpha folders. The version that was up on the site until this morning was only compatible with the old schema.

A while back I persuaded the project owner Chris to let me contribute to the project so that I could update it to use the new schema and make it compatible with 4.5+.

I did that a while ago and we've been running it on a few sites for a few months now without issues so I've finally released it back into the wild for everyone else to use.

In addition to updating the code to work with the new schema, I also tweaked a few other things:

The content tree updates to reflect moves - the content tree on the left reloads to show the correct position of the content once it's been moved.

Problems with XML cache - there were a few minor issues introduced by some of the changes in 4.5 that caused the XML cache not to be correctly updated, these have been fixed.

Super exciting new folder provider - courtesy of Andrew Brigham, we now have a third default provider, the PropertyFolder provider. This allows you to specify a property of a document type, and have AutoFolders create folder structure based on that property. Say for example you have houses with a dropdown called "area", you can set the provider to group by the area property creating a site structure of /area/house. Example code is included in the config file that ships with 2.0.3!

The new version will ONLY work with the new schema, if you want to use AutoFolders on older sites, use version 2.0.2 instead! The DLL is built for .Net 3.5 so it should work on sites that aren't running 4.7 as well (we've tested it on 4.5, 4.5.2, 4.7 and 4.7.1).

I hope you guys like the update and that it allows you to use this excellent package on your newer sites!

:)

Head on over to Our and grab yourself a copy now!

Why? I'm guessing that most of the folks who make these statements either work for cool funky agencies that are all "web 2.0" and just do funky brochureware crap, or that they've only ever worked with fairly small companies. If you've ever worked with a large company (and I'm talking 1000's+ of staff, possibly spread worldwide here) you'll know what a laughable idea it is to try and get them all to update their browsers.

In large corporate IT, you tend to get everyone standardised on similar kit. Because of the cost of upgrading 1000's of PCs (in man hours as well as software licenses), a lot of these companies don't upgrade their software unless there's a compelling business reason to. Installing the latest version of SQL Server because it's 10x faster and can run on less hardware, saving the company X thousand a year in hostiong costs is a compelling reason for them to spend money. Tieing up their IT department upgrading everyone to IE9, plus all the training and increased support times as clueless users call tech support because the buttons are in different places, just so you can have rounded boxes and drop shadows when you browse the web is a far less convincing argument.

Another factor is that of Compliance. Big companies have to comply with all sorts of tedious regulations, especially if they work in the financial sector, which makes upgrading stuff even harder, as you have to go through innumerable audits to make sure that the new stuff is still compliant with internal policies and procedures.

Two of the largest companies I work with at the moment are pretty much all on Windows XP with IE6, with the exception of the upper echelons of management, who always seem to have the shiniest kit. It's not ideal, but it's how they operate.

As a web developer, I just have to live with this. I might not be happy about it, but if I want to work with the big boys, I have to accept that that's the way it is, and me asking them to upgrade their browsers isn't going to make it happen (no matter how much I'd like it to)!

Consequently for most clients in this situation, I go for an approach of progressive enhancement (Google it for lots of exciting resources on the subject). We make sure that the site works nicely in IE6, IE everything looks as nice as we can get it, and then we have progressive updates for users with better browsers. That way the poor schmoes at corporate HQ get a perfectly functional website that is perfectly usable, but eveyone else gets nice gradient fills and curved tab boxes!

So, next time you see someone talking about IE6 browser bugs, think before you tell them to update their browsers!

I hate it when I'm being interviewed for a tech job and someone asks you one of those stupid logic puzzles. They don't really do anything other than see whether you're any good at logic puzzles or not, and most of them are so abstract as to be pointless. You know the kind of thing, "You have a herd of Elephants, some Snakes and a Bee. How do you weigh the Elephants?".

You're interviewing me for a programming job, not a job writing cryptic teasers for the local paper! By all means ask me something programming/code related, like "you have a design with rounded corners and drop shadows and you need the resulting pages to work in IE6, what techniques would you use in the HTML/CSS?", or "you have a website that's using a high amount of RAM and CPU, how would you troubleshoot the problem?". Those are relevant, and allow me to demonstrate my problem solving skills, AND my knowledge of a relevant subject.

This whole post came up after a very amusing chat with some devs at a clients' office recently, and one of the guys was once asked something like:

"You meet a guy in Japan at a business meeting and you get his number, but not his name. You have the phone-book for the city, how do you find out his name?".

Well, for a start, the person setting the question has clearly never done business in Japan. The chances of you getting just a number from a businessman, rather than a full on business card with all the ceremony that it entails are pretty slim. Apparently "looking the number up on the internet" wasn't and acceptable answer (why not I don't know, it'd probably be the quickest way to do it), phoning up directory enquiries wasn't allowed either. He never did get told the "correct" answer in the end by the interviewer, but this sort of question entirely illustrates my point. It's not a very realistic question, and they don't want a practical answer, they want something clever and convoluted. I don't know about you lot, but back when I did the hiring, I wanted people who could demonstrate practical problem solving skills, not someone who can come up with something clever involving six weasels, an elk and a bag of porridge.

I'd be interested to hear if anyone else has had any particularly dumb/pointless interview brainteasers!

:)

I've learnt a lot as I've gone along, and thought I'd share some of the tips for writing extensions for Umbraco! Hopefully some of these will help others avoid some of the mistakes I've made, or save them hours of research.

1. Don't Customize the Core Unless You Have To

Only modify the core if you absolutely have to. Early on I extended Umbraco by modifying the core code itself rather than using the event models etc. This was great, until I had to perform an upgrade. At which point I had to re-apply my updates to the new source, rebuild and re-test. Ouch.

Using the event models and the API, you can code extensions that are easy to re-use and that should carry on working, even after an Umbraco upgrade!

2. When Coding Datatypes, Don't Rely on the HttpContext

DataTypes can be called by events that don't have an HttpContext, like the timed publisher. In these cases they'll throw a null reference error, as the HttpContext is not available. Use non context versions of functions wherever possible!

3. When Coding Publish Event Handlers, Don't Rely on the HttpContext

Publish events can occur outside of the HttpContext. If your publish event handler relies on the HttpContext, it will fail when you try and use the timed publish feature of Umbraco. The biggest culprit I've seen for this is using HttpContext.Current.Server.MapPath, which will be null when called through the timed publisher.

You can map the path using HostingEnvironment.MapPath instead. For other code that relies on HttpContext, put in null checks and default values in case there is no HttpContext, and your handlers should work on normal and timed publish!

4. When Creating New CMS Pages, Inherit From UmbracoEnsuredPage

If you're creating new pages for the back office, you want to make sure that those pages are only visisble to users who have logged in through the CMS. The easiest way to do this, is to make sure that your pages inherit from umbraco.BasePages.UmbracoEnsuredPage instead of the usual System.Web.UI.Page.

This will make your page unavailable to non-logged in users, and will also enable you to hook into your page using the Umbraco event model!

5. Don't Be Afraid To Grub Through Code

One of the biggest ways I learnt was to grub through other people's code. Want to make CMS pages that look like the Umbraco ones, but not sure how to do it? Easy, grabthe source from codeplex and have a look at how it's done! Want to know how your favourite uComponents DataType works? Go look at the source and find out. The more you look, the more you'll learn about how the core works, and the ways that you can interact with it.

Hopefully (time permitting) I'm going to start a series of step by step tutorials on how to do some common stuff with the Umbraco Event models and API, concentrating particularly on the back office! Some of the things I'm hoping to cover are creating back office pages, using Umbraco UI elements, working with DataTypes, and using the event model to interact with the back office!

I find it quite interesting, and over the years I've seen code that's made me weep in awe, and code that's made me claw my eyes out in pure horror. But one of the things I really LOATHE is sites that are massively over-engineered for what they do.

I'll take a site I looked at recently. It's a small (sub 50 page) mobile site, which is almost all just plain text, written in MVC2. The solution for the site is split into 7 projects, uses nHibernate, has all the controllers and views split into separate projects (as well as the models, data access and a couple of generic function projects), and then the admin section of the site is a web forms project!

I'm all for separation of concerns and keeping code portable, but REALLY? 7 projects for a simple site? There's quite a bit of code in there as well, most of which is to do with the separation of the concerns and things like data access, mapping for nHibernate and the like. I'm sure it all made perfect sense to the original developer, but to someone going into it fresh, my initial reaction is one of "why the hell is this simple site done like this? Making changes are going to be pretty time consuming.".

I like to think I use the right tools for the job, and for something like this, I'd probably use either Umbraco, or Perch. I don't really see the point in putting in the amount of effort that must have been involved in setting this bad boy up and testing it, when something much simpler would be far better suited to the task.

It's like the developer wanted to make life difficult for themselves and those who came after.

While it might seem like a cool idea to go crazy with all the latest dev methodologies, and to separate everything out so that you can swap out almost any aspect of the site code, in actualy reality, for a project like this, you won't ever need to.

Another example is a site I worked on a couple of years ago, which was for a car sales company. The site had no transactional functionality, just a searchable list of used cars that you could email sales reps about, and a bunch of content managed pages. It was coded in the style of an ultra complex banking app. Trying to follow the code was a full time job, and what looked like simple function calls would turn out to be extraordinarily complex. I eventually figured out how all the important stuff worked, but noted that most of the people who had worked on the site since the original developer hadn't. In most cases, they'd just written their own code to do the same thing as the overly complex code, and used that instead. Which resulted in as many as 5 different ways of doing the same thing, all of which where used on the site in different places.

It made making changes an absolute nightmare. You'd think you'd changed something, only to discover that one page on the site called something completely different that did the same thing as the function you'd just changed. A list of changes that would have taken maybe two days on any sensible site ended up taking over a week on this system due to its crazy over-engineering!

Again, for this site, I'd have used a decent CMS system, and then written extensions to do the car search part. In fact that was something that WAS done to the site eventually (not by me, it was moved to Drupal/PHP) It's now remarkably trivial to make changes to the site, especially compared to the original monstrosity.......

The moral of the story? Use the right tools for the job, please! Remember that other people may have to work on the site, and that if you use methodolgoes and technologies that make it easy for them to do so, you'll be saving both time AND money in the long run. And please, pretty please, stop using enterpise level architecture for your small/medium sites.

:P

Having bought in a decent desk mounted vice, a new soldering iron and a decent multimeter, I was locked cocked, and ready to rock. Sadly, I couldn't get Pete or Matt over, so I was instead assisted by my trusty feline companion, Suki:

To be fair, she didn't do much apart from Purr and try and sit on me when I was doing fiddly stuff, but she did sit there the whole time, so all good.

Having sat down and read through the extensive Makerbot Wiki I have to say I was pretty daunted, its easily the most complicated project I've ever undertaken. First up I had to install all the drivers/software on my laptop, and check that the Arduino board was working. That turned out to be really straightforward, it was just a case of installing some software, and plugging in the board via USB to install the drivers.

Next up I started assembling the parts I needed for the X stage of the printer (the actual print surface). There were three options, the first, a simple wooden platform, the second a simple heated platform, and the last was the all singing, all dancing Automated Build Platform, with is heated, AND has a conveyor belt for ejecting printed objects. Not wanting to pussy out, I went for the third option. Popping out all the wooden parts was pretty simple, although cleaning the burnt residue from the edges of all the parts was pretty time consuming.

Assembling the wooden frame parts is really straightforward, thanks to the clever T-Nut construction. You do it all with allen keys. Its like a really, really geeky Ikea kit :P First part of soldering was attaching wires to the motor for the converyor belt, and that was pretty straightforward too. Building the rollers for the platform proved to be slightly more tricky. If you don't get your measurements exactly right, they end up out of alignment, which is what happened to me, so I had to do some trimming and adding to the rollers until they fit correctly.

Eventually, after several hours, I ended up with something that vaguely resembled an Automated Build Platform:

Feeling bouyed by my success, I decided to make a start on the Y assembly, which proved to be even simpler than the X stage to build. Eventually I got most of the way there:

Sadly I ran into an issue with the pulleys. It turned out they didn't fit! The instructions said they might need sanding, but it turned out they were totally the wrong size:

A quick email to Makerbot support later, and it transpired that the motors had been upgraded in a recent kit upgrade, but I still had the older pulleys. They sent me out replacements, first class, the same day! Most impressed. That did however mean that I had to call it a day at that point.

You can view the full photo set on my Flikr page, here. More to come soon, once I've uploaded all of the pictures!

Not too complicated I think to myself. All three platforms are big, and popular, so there must be decent APIs and SDKs available! So I did the easy parts, set up my config files, event handlers, menu items and dialogs, all good so far. So next up, I sit down to implement the first network.

Twitter
Twitter is the big one. Its effectively a hosted service, with a basic UI, that other people interact with and pipe data to and from. Consequently, their API is fantastic. Its easy to use, extremely well documented, and has more SDKs and libraries in every conceivable language than any other system I've worked with. Consequently it took less than two hours to find a decent SDK (I used the excellent TweetSharp), work out what API calls I needed to make, set up an App in Twitter, authorise it and get it all up an running. Its a great example of a service provider going out of their way to make you want to use their API. Hell, Twitter pretty much stands around on street corners flashing its goodies at you screaming for you to use its API.

Facebook
Next up was Facebook. Another heavy hitter, these guys also have a fairly comprehensive API, lots of documentation, and loads of SDKs and toolkits. The only problem is that they change their API a fair bit, so a lot of the information on the web can be out of date (as well as some of the official documentation). This caused me a bit of pain on a few occasions where I found out I was calling deprecated API methods and so forth. On the whole though, the whole process only took a couple of hours or so longer than Twitter, and some of that was down to Facebook being fussier about setting up Apps. I used the excellent FacebookWeb SDK in the end to do all the grunt work.

LinkedIn
And finally, the new kid in town. These guys have an API, its not bad, but working with it isn't easy, especially if you use .Net. There's only one 3rd party Toolkit, which forces you to inherit from basepages (which wasn't any good for my code), and the documentation is OK, but REALLY badly laid out. In fact I'd go as far as to say it was excruciatingly painful trying to get working code for LinkedIn. As the 3rd party toolkit didn't meet my needs, I ended up rolling my own code based on oAuth and some code I found buried on the support forum. It took me about a day to get it up and running, not helped by the fact that the example in C# I found for updating statuses was out of date.

The difference between the three is quite marked. You can see why everyone and their dog does Twitter integration, it's so EASY. Even Facebook, while slightly fiddlier, doesn't present too much of a challenge for most tasks. But LinkedIn is a nightmare. Things look better if you're a Ruby or PHP  person, as better toolkits are available. But still, if you're going to release an API for your system, here are a few tips that will make us developers like you more, and should hopefully result in better takeup of your system with integrators:

• Document everything thoroughly, and for God's sake update the docs if the API changes!
• Have example code in as many of the major languages as possible. Don't have inhouse .Net/TCL/Python folks? Hire a freelancer, or sponsor someone in your dev community to do it. Developers love example code. Also, the updates thing. No one likes going through code examples to find out they don't work because the API was updated and no one updated the examples.
• Make it easy for us developers to create SDKs/Toolkits for your API. We love doing that, and most of us will share that code with others too!
• Make you API make sense. If your methods have human readable parameter names, we can figure out whats going on better than having short/obscure/gibberish ones.
• As above, but for method calls. Make sure they make sense.
• Don't make us use the API to find out the information we need to use the API. If there's a web interface for your app, give us a way of getting ids etc, don't make us write code who's sole purpose is to get the ids/whatever I need to use your API.

The only thing is, it starts off life looking like this:

(The wool isn't part of the kit, its just on my table). Quite a way to go before I can start printing out cool stuff! I've read through the rather comprehensive online Wiki for the device and reckon I've got it mostly worked out. I had to order in a few bits and pieces, I've never owned my own multimeter, and my old soldering iron was dead. Those have now arrived, so over the next few weeks, I'll be blogging about my experiences building this very cool device.

With any luck, I'll be getting some help from Matt Brailsford and Pete "Knife Meme" Duncanson along the way as well. I'll be sure to post plenty of pictures and blog posts.

And yes, one of the first things I intend to print is an Umbraco logo :P If I can get a decent model on the go, I'll also be trying to print out some medals for all of the entrants to the package competition too!