Can I set a container to be the root of my exported HTML site?

(Pat Maddox) #1

I have a lot of pages on my site, and the top-level of my TB doc has gotten unwieldy. I would like to put them in a container note called pages for organization.

The problem is that when I export them, they now go in a pages/ sub folder. This wouldn’t be so bad if I only ever used relative paths, but I generate a sitemap.txt and would like to do an RSS feed, that need absolute URLs. Now using setRoot(http://mysite.com/) I end up with URLs like http://mysite.com/pages/mypage.html which is not what I want.

Is there a way to set my pages container note as the root note for HTML export? I’d really like to clean up the top-level of my document.

(eastgate) #2

Rather than do this, consider taking the rest of your infrastructure and tucking that into a container that isn’t exported.

(Mark Anderson) #3

MB’s point is exactly the journey aTbRef went on. All the content you see online, bar things like RSS feeds, sitemap, etc., are descended from a single root level container. Only the index (home) page of content is at root level.

For simple testing, e.g. of users’ problems here, I use the root map/outline. But, for actual projects, especially where export is intended I use a root container for the primary export.

Whether using HTML or some similar mark-up (OPML, XML, etc.) it is important to understand that a note exports to the folder relevant to it’s outline location. Although, by using codes like^include()^, you can export data from one note via a different note, the latter still exports in its hierarchical place.

I think the app’s design echoes, understandably, the non-corporate web from before database-based blogging took off (i.e. when the app was originally designed). To move to a different export paradigm would essentially be a design do-over and so I believe a large engineering cost for a powerful feature set that not everyone uses.

(Pat Maddox) #4

Makes sense. Thanks guys :+1:

(eastgate) #5

I don’t think setting the export root would be that difficult: indeed, Tinderbox originally had a preference to cope with shared servers. But I think the current solution is, in general, good.