Love the updates to the .config.

I am having some issues though.

Here is my update to the .config

  <autoFolders>
    <autoFolder docType="News Item"
             folderProviderAlias="DateFolderProvider" 
             rootFolders="//node[@level = 2]"
             folderDocType="News List" 
             truncatedFolderUrl="folder-1/folder-2/newsitems"
             />
  </autoFolders>

My structure goes something like this

Content

-- Home

----Communication (Standard Template)

------Releases (news List)

------News (news List)

When I tried to create a News Item with the parent of News, here is what I got:

-News (news list)

-0001 (news list)

----01 (news list)

--------01 (news list)

-2009 (news list)

----11 (news list)

--------06 (news list)

------------- article that I entered (news Item)

So it created extra folders and also the 2009 folder was not placed in the news directory like it was supposed. Seemed to go one directory to far up.

Thanks for your work. I'm going to check out your source and see how you changed the code.

-Chad

Try changing the rootFolders to

 rootFolders="//node[@level = 2]"

RootFolders is the applicable parent folders that you can create children in. It thinks you can only create your items from level 2 so is therefore going up the tree until it find a suitable parent. You should be able to just remove this attribute and it will work too.

What's happened is that on creation autofolders couldn't determine the date, so it created the 0001/01/01 structure (showing that an error occured I suppose). OnPublish it could determine the nodes date and moved it for you.

Two solutions to this:

1) Only hook into ONLY the Publish event and not create.

2) Just create the node in the root folder until the real date can be determined.

Any preference? I'm thinking Option 2...

Any update on the 0001/01/01 folder structure? I'd vote for Option 2 aswell.

/Matt

When I modified the autofolders code, I pretty much did option 2.

First had it create as a sub-item of the root folder. Then when you published it, it would check if the item had the correct field. In my case, it was hard coded to 'displayDate'. If displayDate existed, then it would check/create the folder structure and move the item. If the item did not have displayDate, then it would check the createdDate, and move the item accordingly.

@Chris: What about using DateTime.Now if date isn't available?

Morning Guys,

Thanks for the feedback.

I've went with option 2 and released version 2.0.1. I've also included some additional examples of configuration in the config file.

I decided option 2 as it doesn't create anything that may be incorrect. It only leaves the new page in the first valid location until the custom date field is populated.

Cheers,

Chris

shameless plug... remember to vote for the package if you like it... :-)

Option 2 works much better, although I'm still running into a bug.

I had an item previously created, and then republished. It correctly created the folder structure and moved the item (option 2). So now my item was found in event_calendar -> 2009 -> 12 - > 05 -> event name. Just as a test, I changed the date on that item to a different date. When it did that, it recreated the folder structure for the new date, but inside of the 05 date. So now I have the following folder structure: event_calendar -> 2009 -> 12->05 ->2009 -> 12 -> 26 -> event name.

Besides that, it seems to be working perfectly for me. It's a huge improvement over 1.3.

-C

Immediate fix: Try restricting the rootFolders property so that it only includes your event_calendardoc type.

Proper Fix: I'll look in to this....

Chris

any thoughts on how this could be used with pdCalendar???  if i use the event property... that is unfortanutately a dataType that has a startDate, endDate and recurrence...

any help would be greatly appreciated.

Currently that can't be done.

PDCalendar stores its data as a XML-chunk. Would be nice if autofolders could be configured to use a part of that xml as date? Thoughts?

is working on a reply...