Function to return site structure with details of first child object


Is there any function already in FarCry core (7+) that I can use that will provide me with a list of items from dmNavigation along with details, even if just objectid and type, of the first child page under that navigation item (which typically will be a dmHTML object)?

I want this for a sitemap generator that I’m just starting work on. I did take a look at some of the sitemap code in the Google Site Search (GSS) plugin but it doesn’t do what I want. The main reason I want the details of the first child object for each dmNavigation item is because I want to use the last modified date of the child in the sitemap rather than the last modified date from dmNavigation. Typically the date in dmNavigation will be from when it was first created and typically is much older than the date of the child objects last modified date. When supplying the sitemap to Google, Bing etc. you typically are supplying the FURL for the dmNavigation item, along with its date, which makes the content look a lot older than it really is.

On a side question, is trawling nested_tree_objects still the best way to work out the site structure?


You might be interested in how the Google Site Search plugin does it:


Hi Blair,

Do you mean in relation to the nested_tree_objects query in that file? I already stole that piece of code :).

I modified that query to also return the objected and typename (I think those were from dmNavigation_aObjectIDs) but then hit issues trying to use dynamic table names in the FROM clause in SQL (to reflect the typenames). Also tried storing the dynamic table name in a SQL variable but hit issues with that as well. What I’m currently considering is using the NTO query (unchanged from GSS code) and then looping that to lookup the child of each dmNavigation and manipulating the query results of the NTO query to reflect the more current date/time. Seems excessive but can’t seem to find a better way. Doesn’t help that QoQ’s don’t support update statements…


You might be able to work around the typename issue by joining onto a
subquery that unions the various possible child types.