Say you’ve got a single note, and it exports to my_note.html. Now you change the export file name and export again, and you’ve got my_renamed_note.html AND my_note.html in the directory – when there should only be my_renamed_note.html.
How do you handle this? Assume that it’s hundreds of files in the directory, with potentially dozens of note changes at any point…
Right now I use the bash script find . -name "*.html" -delete && find . -type d -empty -delete to delete all HTML files before exporting. But it feels inelegant, and every HTML file now ends up with a newly set created time, which isn’t right.
So, when I export, I want the file system to not have any old exported HTML files. Is there a clean way to do that?
As I think you’ve discovered, $HTMLExportFileName is generated from $Name unless you set a value. If you want to change the note title, one good idea is simply to manually set the note’s $HTMLExportFileName to the existing automatically-generated value before changing the note title. This way the $Name changes but $HTMLExportFileName continues the same.
If you’re just manually changing the $HTMLExportFileName, I’d stop and ask myself ‘why?’. Who, apart from very few of us worry about the exact phrasing/spelling of web page filenames. Don’t forget the impact on inbound links to your site. A seeming typo in a filename is a small embarrassment compared to breaking lots of links pointing at that page from elsewhere on the Web.
Anyway, so you’ve changed a few notes and now have old ones - what to do? I generally delete the local folder of exported files (i.e. sibling pages) but if your TBX is richly interlinked you need to think about the links in other notes that may now link to the wrong filename. Thus, given that Tinderbox export so quickly, I now tend to delete the content’s of the export folder (except any elements not generated by Tinderbox) and re-export. That way all the intra-site links are now correct.
If exporting locally but using elsewhere, e.g. on your web-server on a different LAN, then I generally use FTP. Depending on the speed of access, I either repeat the process - delete the contents of the root folder and upload the new files, or I synch the two sets of files so the remote set (web server) reflects the local set.
Bottom line:
for things you’re putting online for a while and which may be linked to by others, if you need to alter $Name, hard-set $HTMLExportFileName so it doesn’t change.
for local export, rather than find the odd old-named file, simply delete its siblings or delete the whole export and export the TBX afresh (it’s quicker that hunting around!).
if you’re exporting page-by-page, set your TBX up so non-export pages don’t export (by default everything does). After that re-exporting is a simple menu driven selection and a few seconds of export processing.
if exporting public-facing pages, balance embarrassment over poor HTML filename choices over Web (inbound) link breakage if you alter a URL.
Agree with @mwra’s QM caveats regarding naming and link assurance.
When developing a document + export (e.g., for importing into Word), my practice is to trash the entire export folder and recreate it before running the next File > Export. If the export folder needs subfolder(s) with images and other resources for linking or inclusion, then I keep the master subfolder somewhere and copy an instance into the recreated export folder. So its
trash old export destination folder --> recreate export destination folder --> copy subfolders (if any) into the destination folder --> **File > Export** --> rinse and repeat
If there are going to be frequent export sessions as I increment toward the final product, I will cobble together a Keyboard Maestro macro to handle the housekeeping in the file system.
FWIW, I’ve learned from unhappy experience spent debugging to always export to a freshly-made destination. Clean the worktable and jigs before building.
Amen. A further upside of this is it nudges one into a less ad hoc workflow. Getting a quite complex workflow out of only part of a Tinderbox document is very possible and once set up (‘some assembly required’**) generally just works in a push-button sense thereafter.
** this forum is a good place to ask if stuff. Some parts of initial assembly are more obvious only once you’re figured them out.